BaselineWatch
Desk
Your fleet and your work Fleetyour releases and the hardware they run onTriagewhat needs a decisionWatchlistthe products and platforms you runSaved searchesthe lists you come back to
This instance Sourceswhat is read, how often, under what termsDigestthe daily or weekly summary, and alerts
How it is drawn Appearancethe look and the colour schemeBrandingthe mark this instance wears
Owner sign-in

7.1 Back-Channel Presentation

NIST PIV and digital identity SP 800-63C-4 against SP 800-63C
All changes in this version
removed 7 Signature: Digital signature or message authentication code (MAC), including key part of 7

Title changed

Before · SP 800-63C

Back-Channel Presentation

After · SP 800-63C-4

Back-Channel Presentation

Control changed

Before · SP 800-63C

In the back-channel model, the subscriber is given an assertion reference to present to the RP, generally through the front channel. The assertion reference itself contains no information about the subscriber and SHALL be resistant to tampering and fabrication by an attacker. The RP presents the assertion reference to the IdP, usually along with authentication of the RP itself, to fetch the assertion.

Figure 7-1 Back Channel Presentation

As shown in Figure 7-1 , the back-channel presentation model consists of three steps:

1. The IdP sends an assertion reference to the subscriber through the front channel. 2. The subscriber sends the assertion reference to the RP through the front channel. 3. The RP presents the assertion reference and its RP credentials to the IdP through the back channel. The IdP validates the credentials and returns the assertion.

The assertion reference:

1. SHALL be limited to use by a single RP. 2. SHALL be single-use. 3. SHOULD be time limited with a short lifetime of seconds or minutes. 4. SHOULD be presented along with authentication of the RP.

In this model, the RP directly requests the assertion from the IdP, minimizing chances of interception and manipulation by a third party (including the subscriber themselves).

This method also allows the RP to query the IdP for additional attributes about the subscriber not included in the assertion itself, since back-channel communication can continue to occur after the initial authentication transaction has been completed without sending the user back to the IdP. This query occurs using an authorization component issued alongside the assertion, as described in Section 6 .

More network transactions are required in the back-channel method, but the information is limited to only those parties that need it. Since an RP is expecting to get an assertion only from the IdP directly, the attack surface is reduced. Consequently, it is more difficult to inject assertions directly into the RP.

The RP SHALL protect itself against injection of manufactured or captured assertion references by use of cross-site scripting protection or other accepted techniques.

Elements within the assertion SHALL be validated by the RP, including:

• Issuer verification: ensuring the assertion was issued by the IdP the RP expects it to be from.
• Signature validation: ensuring the signature of the assertion corresponds to the key related to the IdP sending the assertion.
• Time validation: ensuring the expiration and issue times are within acceptable limits of the current timestamp.
• Audience restriction: ensuring this RP is the intended recipient of the assertion.

Conveyance of the assertion reference from the IdP to the subscriber, as well as from the subscriber to the RP, SHALL be made over an authenticated protected channel. Conveyance of the assertion reference from the RP to the IdP, as well as the assertion from the IdP to the RP, SHALL be made over an authenticated protected channel.

When assertion references are presented, the IdP SHALL verify that the party presenting the assertion reference is the same party that requested the authentication. The IdP can do this by requiring the RP to authenticate itself when presenting the assertion reference to the IdP or through other similar means (see RFC 7636 for one protocol’s method of RP identification). Note that in a federation proxy described in Section 5.1.4 , the IdP audience restricts the assertion reference and assertion to the proxy, and the proxy restricts any newly-created assertion references or assertions to the downstream RP.

After · SP 800-63C-4

In the back-channel model, the subscriber is given an assertion reference to present to the RP, generally through the front channel. The assertion reference itself contains no information about the subscriber and SHALL be resistant to tampering and fabrication by an attacker. The RP presents the assertion reference to the IdP, usually along with authentication of the RP itself, to fetch the assertion.

Figure 7-1 Back Channel Presentation

As shown in Figure 7-1 , the back-channel presentation model consists of three steps:

1. The IdP sends an assertion reference to the subscriber through the front channel. 2. The subscriber sends the assertion reference to the RP through the front channel. 3. The RP presents the assertion reference and its RP credentials to the IdP through the back channel. The IdP validates the credentials and returns the assertion.

The assertion reference:

1. SHALL be limited to use by a single RP. 2. SHALL be single-use. 3. SHOULD be time limited with a short lifetime of seconds or minutes. 4. SHOULD be presented along with authentication of the RP.

In this model, the RP directly requests the assertion from the IdP, minimizing chances of interception and manipulation by a third party (including the subscriber themselves).

This method also allows the RP to query the IdP for additional attributes about the subscriber not included in the assertion itself, since back-channel communication can continue to occur after the initial authentication transaction has been completed without sending the user back to the IdP. This query occurs using an authorization component issued alongside the assertion, as described in Section 6 .

More network transactions are required in the back-channel method, but the information is limited to only those parties that need it. Since an RP is expecting to get an assertion only from the IdP directly, the attack surface is reduced. Consequently, it is more difficult to inject assertions directly into the RP.

The RP SHALL protect itself against injection of manufactured or captured assertion references by use of cross-site scripting protection or other accepted techniques.

Elements within the assertion SHALL be validated by the RP, including:

• Issuer verification: ensuring the assertion was issued by the IdP the RP expects it to be from.
• Signature validation: ensuring the signature of the assertion corresponds to the key related to the IdP sending the assertion.
• Time validation: ensuring the expiration and issue times are within acceptable limits of the current timestamp.
• Audience restriction: ensuring this RP is the intended recipient of the assertion.

Conveyance of the assertion reference from the IdP to the subscriber, as well as from the subscriber to the RP, SHALL be made over an authenticated protected channel. Conveyance of the assertion reference from the RP to the IdP, as well as the assertion from the IdP to the RP, SHALL be made over an authenticated protected channel.

When assertion references are presented, the IdP SHALL verify that the party presenting the assertion reference is the same party that requested the authentication. The IdP can do this by requiring the RP to authenticate itself when presenting the assertion reference to the IdP or through other similar means (see RFC 7636 for one protocol’s method of RP identification). Note that in a federation proxy described in Section 5.1.4 , the IdP audience restricts the assertion reference and assertion to the proxy, and the proxy restricts any newly-created assertion references or assertions to the downstream RP.