Skip to content

Commit

Permalink
Merge pull request usnistgov#657 from lachellel/patch-1
Browse files Browse the repository at this point in the history
Update of 83C - Section 5.1.2 for clarity. Sorry @lachellel for taking so long.  I didn't realize this PR was out there.  Next time mention me. Or call me :)
  • Loading branch information
Paul Grassi authored Apr 27, 2017
2 parents 3127764 + e990253 commit bf22e28
Showing 1 changed file with 9 additions and 8 deletions.
17 changes: 9 additions & 8 deletions sp800-63c/sec5_assertions.md
Original file line number Diff line number Diff line change
Expand Up @@ -43,16 +43,17 @@ A bearer assertion can be presented by any party as proof of the bearer's identi
Note that mere possession of a bearer assertion or reference is not always enough to impersonate a subscriber. For example, if an assertion is presented in the back-channel federation model (described in [Section 6.1](#sec6-1)), additional controls MAY be placed on the transaction (such as identification of the RP and assertion injection protections) that help to further protect the RP from fraudulent activity.

#### 5.1.2. Holder-of-Key Assertions
A holder-of-key assertion contains a reference to a key possessed by and representing the subscriber. The key referenced in a holder-of-key represents the subscriber, not any other party in the system including the browser, IdP, or RP. Note that the reference to the key is asserted (and signed) by the issuer of the assertion.

A holder-of-key assertion contains a reference to a key possessed by and representing the subscriber, and the subscriber SHALL prove possession of that key in addition to presentation of the assertion itself. The key MAY be a symmetric key or a public key that corresponds to a private key. An assertion containing a reference to a key held by the subscriber for which key possession has not been proven SHALL be considered a bearer assertion by the RP.
In proving possession of the subscriber's secret, the claimant also proves with a certain degree of assurance that they are the rightful subject of the assertion. It is more difficult for an attacker to use a stolen holder-of-key assertion issued to a subscriber, since the attacker would need to steal the referenced key material as well.

The key referenced in a holder-of-key represents the subscriber, not any other party in the system including the browser, IdP, or RP. This key MAY be distinct from any key used by the subscriber to authenticate to the IdP.

In proving possession of the subscriber's secret, the claimant also proves with a certain degree of assurance that they are the rightful subject of the assertion. It is more difficult for an attacker to use a stolen holder-of-key assertion issued to a subscriber, since the attacker would need to steal the referenced key material as well.

Note that the reference to the key is asserted (and signed) by the issuer of the assertion; reference to a given key SHALL be trusted at the same level as all other information within the assertion.

The assertion SHALL NOT include an unencrypted private or symmetric key to be used with holder-of-key presentation. The RP MAY verify the claimant's possession of the key in conjunction with the IdP, for example, by requesting that the IdP verify a signature or MAC calculated by the claimant in response to a cryptographic challenge.
- The key MAY be distinct from any key used by the subscriber to authenticate to the IdP.
- The key MAY be a symmetric key or a public key that corresponds to a private key.
- The subscriber SHALL prove possession of that key in addition to presentation of the assertion itself.
- An assertion containing a reference to a key held by the subscriber for which key possession has not been proven SHALL be considered a bearer assertion by the RP.
- Reference to a given key SHALL be trusted at the same level as all other information within the assertion.
- The assertion SHALL NOT include an unencrypted private or symmetric key to be used with holder-of-key presentation.
- The RP MAY verify the claimant's possession of the key in conjunction with the IdP, for example, by requesting that the IdP verify a signature or MAC calculated by the claimant in response to a cryptographic challenge.

### 5.2. Assertion Protection

Expand Down

0 comments on commit bf22e28

Please sign in to comment.