OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-sx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Issue 153: Generalized Interactive Challenge for WS-Trust


Issue 153

 

From: Marc Goodner [mailto:mgoodner@microsoft.com]
Sent: Tuesday, November 13, 2007 4:16 PM
To: ws-sx@lists.oasis-open.org
Subject: [ws-sx] New Issue: Generalized Interactive Challenge for WS-Trust

 

PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON THREAD UNTIL THE ISSUE IS ASSIGNED A NUMBER.  
The issues coordinators will notify the list when that has occurred.
 
Title: Generalized Interactive Challenge for WS-Trust 
Protocol: Trust
Artifact:  spec 
Type: design

Description:

The security token services (STS) framework defined by WS-Trust allows for a simple request and response for security tokens as well as an extension mechanism to enable exchanges for negotiation and challenges. The WS-Trust specification defines a “signature challenge” construct as a specific type of exchange that makes use of the above extension mechanism for general exchanges.

There are many scenarios where an STS may require further interactions with the requestor prior to returning a security token, beyond the authentication requirements expressed in its security policy and satisfied by the security tokens bound to the initial RST request through SOAP security header. Following are examples of exchanges where an STS may further challenge the requestor for additional interactive input, to supplement authentication information submitted in the original request in the SOAP security header, before issuing the requested token.

·         Prompt the user for an additional shared secret such as a PIN.

·         Prompt the user for second-factor authentication data such as “one time password” (OTP) taken from an OTP device or module.

·         Prompt the user for answers to text-based secret questions (e.g., mother’s maiden name, date of birth) as either text inputs or multiple-choice inputs.

·         Prompt the user for answers to image-based challenges as either text inputs or multiple-choice inputs.

The challenge may be selectively issued by the STS only for particular users or for token requests for particular target scopes. The specific user or target scope can only be identified after the initial request is received.

In all such cases, however, the supplemental authentication information required by the STS does not cause a reset of the security policy of the STS. Specifically, the additional information requested by the STS in the form of challenge and response exchanges is carried entirely within the RST/RSTR message bodies and does not affect the authentication information carried inside the SOAP security headers in any way. The security token content in the SOAP security headers remains unchanged across the user interaction challenge/response exchanges.

This proposal defines a “user interaction challenge” construct, as a strongly typed mechanism, for issuing interactive challenges and receiving corresponding responses within the WS-Trust framework inside the bodies of RST/RSTR messages. The proposed mechanism easily fits into the general exchanges mechanism already defined in WS-Trust.

 

Proposal:

Add the following section to section 8, Negotiation and Challenge Extensions after section 8.2. Existing sections 8.3 through 8.6 increment accordingly. To be consistent with the existing section the examples for interactive challenges should be added as section 8.8 after the existing section 8.6 (renumbered to 8.7) on signature challenge examples. Remaining existing sections 8.7 through 8.9 increment accordingly.

Also, add a new property to SecurityPolicy 1.3 in the Trust 1.3 assertion and a new nested assertion to control the setting of that property.

All new elements, attributes, URIs are to be defined under the Trust 1.4 namespace, represented here with the wst14 namespace prefix and the placeholder URI http://docs.oasis-open.org/ws-sx/ws-trust/yyyymm. New assertions for SecurityPolicy 1.3 are defined under sp13 namespace prefix and the placeholder URI http://docs.oasis-open.org/ws-sx/ws-securitypolicy/yyyymm.

WS-SecurityPolicy change for Trust 1.3 assertion

[Interactive Challenge]

This boolean property indicates whether interactive challenges are supported. A value of 'true' indicates that a wst14:InteractiveChallenge element is supported inside of an RSTR sent by the server to the client. A value of 'false' indicates that wst14:InteractiveChallenge is not supported. A challenge issued by the server may increase the number of messages exchanged by the client and service in order to accommodate the wst14:InteractiveChallengeResponse element sent by the client to the server in response to the wst14:InteractiveChallenge element. There is an optimization in which a client MAY send the wst14:InteractiveChallengeResponse element in an initial RST to the server. A final RSTR containing the issued token will follow subsequent to the server receiving the wst14:InteractiveChallengeResponse element. This property has a default value of 'false'.

/sp:Trust13/wsp:Policy/sp13:MustSupportInteractiveChallenge

This optional element is a policy assertion indicates that the [Interactive Challenge] property is set to 'true'.

8.3 User Interaction Challenge

User interaction challenge requests are issued by including the <InteractiveChallenge> element. The response is returned in a <InteractiveChallengeResponse> element. Both the challenge and response elements are specified within the <wst:RequestSecurityTokenResponse> element. In some instances, the requestor may issue a challenge to the recipient or provide a response to an anticipated challenge from the recipient in the initial request. Consequently, these elements are also allowed within a <wst:RequestSecurityToken> element. The challenge/response exchange between client and server MAY be iterated over multiple legs before a final response is issued. Note that the xml:lang attribute may be used where allowed via attribute extensibility to specify a language of localized elements and attributes using the language codes specified in [RFC 3066].

8.3.1 Challenge Format

The syntax of the user interaction challenge element is as follows:

 

<wst14:InteractiveChallenge xmlns:wst14="..." ...>

  <wst14:Title ...> xs:string </wst14:Title> ?

  <wst14:TextChallenge RefId="xs:anyURI" Label="xs:string"? MaxLen="xs:int"? HideText="xs:boolean"? ...>

    <wst14:Image MimeType="xs:string"> xs:base64Binary </wst14:Image> ?

  </wst14:TextChallenge> *

  <wst14:ChoiceChallenge RefId="xs:anyURI" Label="xs:string"? ExactlyOne="xs:boolean"? ...>

    <wst14:Choice RefId="xs:anyURI" Label="xs:string"? ...>

      <wst14:Image MimeType="xs:string"> xs:base64Binary </wst14:Image> ?

    </wst14:Choice> +

  </wst14:ChoiceChallenge> *

  < wst14:ContextData RefId="xs:anyURI"> xs:any </wst14:ContextData> *

  ...

</wst14:InteractiveChallenge>

 

The following describes the attributes and elements listed in the schema outlined above:

.../wst14:InteractiveChallenge

A container element for a challenge that requires interactive user input.

.../wst14:InteractiveChallenge/wst14:Title

An optional element that specifies an overall title text to be displayed to the user (e.g. a title describing the purpose or nature of the challenge). How the preferred language of the requestor is communicated to the STS is left up to implementations.

.../wst14:InteractiveChallenge/wst14:TextChallenge

An optional element that specifies a challenge that requires textual input from the user.

.../wst14:InteractiveChallenge/wst14:TextChallenge/@RefId

A required attribute that specifies a reference identifier for this challenge element which is used to correlate the corresponding element in the response to the challenge.

.../wst14:InteractiveChallenge/wst14:TextChallenge/@MaxLen

An optional attribute that specifies the maximum length of the text string that is sent as the response to this text challenge. This value serves as a hint for the user interface software at the requestor which manifests the end-user experience for this challenge.

.../wst14:InteractiveChallenge/wst14:TextChallenge/@HideText

An optional attribute that specifies that the response to this text challenge MUST receive treatment as hidden text in any user interface. For example, the text entry may be displayed as a series of asterisks in the user interface. This attribute serves as a hint for the user interface software at the requestor which manifests the end-user experience for this challenge.

.../wst14:InteractiveChallenge/wst14:TextChallenge/@Label

An optional attribute that specifies a label for the text challenge item (e.g. a label for a text entry field) which will be shown to the user. How the preferred language of the requestor is communicated to the STS is left up to implementations.

.../wst14:InteractiveChallenge/wst14:TextChallenge/Image

An optional element that contains a base64 encoded inline image specific to the text challenge item to be shown to the user (e.g. an image that the user must see to respond successfully to the challenge).

.../wst14:InteractiveChallenge/wst14:TextChallenge/Image/@MimeType

A required attribute that specifies a MIME type (e.g., image/gif, image/jpg) indicating the format of the image.

.../wst14:InteractiveChallenge/wst14:ChoiceChallenge

An optional element that specifies a challenge that requires a choice among multiple items by the user.

.../wst14:InteractiveChallenge/wst14:ChoiceChallenge/@RefId

A required attribute that specifies a reference identifier for this challenge element which is used to correlate the corresponding element in the response to the challenge.

.../wst14:InteractiveChallenge/wst14:ChoiceChallenge/@Label

An optional attribute that specifies a title label for the choice challenge item (e.g., a text header describing the list of choices as a whole) which will be shown to the user. How the preferred language of the requestor is communicated to the STS is left up to implementations.

.../wst14:InteractiveChallenge/wst14:ChoiceChallenge/@ExactlyOne

An optional attribute that specifies if exactly once choice must be selected by the user from among the child element choices. The absence of this attribute implies the value “false” which means multiple choices can be selected.

.../wst14:InteractiveChallenge/wst14:ChoiceChallenge/wst14:Choice

A required element that specifies a single choice item within the choice challenge.

.../wst14:InteractiveChallenge/wst14:ChoiceChallenge/wst14:Choice/@RefId

A required attribute that specifies a reference identifier for this specific choice item which is used to correlate the corresponding element in the response to the challenge.

.../wst14:InteractiveChallenge/wst14:ChoiceChallenge/wst14:Choice/@Label

An optional attribute that specifies a text label for the choice item (e.g., text describing the individual choice) which will be shown to the user. How the preferred language of the requestor is communicated to the STS is left up to implementations.

.../wst14:InteractiveChallenge/wst14:ChoiceChallenge/wst14:Choice/wst14:Image

An optional element that contains a base64 encoded inline image specific to the choice item to be shown to the user (e.g. an image that the user must see to respond successfully to the challenge).

.../wst14:InteractiveChallenge/wst14:ChoiceChallenge/wst14:Choice/wst14:Image/@MimeType

A required attribute that specifies a MIME type (e.g., image/gif, image/jpg) indicating the format of the image.

.../wst14:InteractiveChallenge/wst14:ContextData

An optional element that specifies a value that MUST be reflected back in the response to the challenge (e.g., cookie). The element may contain any value. The actual content is opaque to the requestor; it is not required to understand its structure or semantics. This can be used by an STS, for instance, to store information between the challenge/response exchanges that would otherwise be lost if the STS were to remain stateless.

.../wst14:InteractiveChallenge/wst14:ContextData/@RefId

A required attribute that specifies a reference identifier for this context element which is used to correlate the corresponding element in the response to the challenge.

.../wst14:InteractiveChallenge/{any}

This is an extensibility mechanism to allow additional elements to be specified.

.../wst14:InteractiveChallenge/@{any}

This is an extensibility mechanism to allow additional attributes to be specified.

The syntax of the user interaction challenge response element is as follows:

 

<wst14:InteractiveChallengeResponse xmlns:wst14="..." ...>

  <wst14:TextChallengeResponse RefId="xs:anyURI" ...>

    xs:string

  </wst14:TextChallengeResponse> *

  <wst14:ChoiceChallengeResponse RefId="xs:anyURI"> *

    <wst14:ChoiceSelected RefId="xs:anyURI" /> *

  </wst14:ChoiceChallengeResponse>

  <wst14:ContextData RefId="xs:anyURI"> xs:any </wst14:ContextData> *

  ...

</wst14:InteractiveChallengeResponse>

 

The following describes the attributes and elements listed in the schema outlined above:

.../wst14:InteractiveChallengeResponse

A container element for the response to a challenge that requires interactive user input.

.../wst14:InteractiveChallengeResponse/wst14:TextChallengeResponse

This element value contains the user input as the response to the original text challenge issued.

.../wst14:InteractiveChallengeResponse/wst14:TextChallengeResponse/@RefId

A required attribute that specifies the identifier for the text challenge element in the original challenge which can be used for correlation.

.../wst14:InteractiveChallengeResponse/wst14:ChoiceChallengeResponse

A container element for the response to a choice challenge.

.../wst14:InteractiveChallengeResponse/wst14:ChoiceChallengeResponse/@RefId

A required attribute that specifies the reference identifier for the choice challenge element in the original challenge which can be used for correlation.

.../wst14:InteractiveChallengeResponse/wst14:ChoiceChallengeResponse/wst14:ChoiceSelected

A required element that specifies a choice item selected by the user from the choice challenge.

.../wst14:InteractiveChallengeResponse/wst14:ChoiceChallengeResponse/wst14:ChoiceSelected/@RefId

A required attribute that specifies the reference identifier for the choice item in the original choice challenge which can be used for correlation.

.../wst14:InteractiveChallengeResponse/wst14:ContextData

An optional element that carries a context data item from the original challenge that is simply reflected back.

.../wst14:InteractiveChallengeResponse/wst14:ContextData/@RefId

A required attribute that specifies the reference identifier for the context data element in the original challenge which can be used for correlation.

.../wst14:InteractiveChallengeResponse/{any}

This is an extensibility mechanism to allow additional elements to be specified.

.../wst14:InteractiveChallengeResponse/@{any}

This is an extensibility mechanism to allow additional attributes to be specified.

In order to prevent certain types of attacks, such as man-in-the-middle or replay of response, the challenge SHOULD be bound to the response. For example, an STS may use the <ContextData> element in the challenge to include a digest of any relevant replay protection data and verify that the same data is reflected back by the requestor.

8.3.2 PIN and OTP Challenges

Two commonly used challenges, usually as forms of second authentication factors, that require user interaction are:

  • a challenge for a secret PIN,
  • a challenge for a one-time-password (OTP).

This challenge may be issued by an STS using the “text challenge” format within a user interaction challenge specified in the section above. A requestor responds to the challenge with the PIN/OTP value along with the corresponding @RefId attribute value for the text challenge which is used by the STS to correlate the response to the original challenge. This pattern of exchange requires that the requestor must receive the challenge first and thus learn the @RefId attribute value to include in the response.

There are cases where a requestor may know a priori that the STS challenges for a single PIN/OTP and, as an optimization, provide the response to the anticipated challenge in the initial request. The following distinguished URIs are defined for use as the value of the @RefId attribute of a <TextChallengeResponse> element to represent PIN and OTP responses using the optimization pattern.

http://docs.oasis-open.org/ws-sx/ws-trust/yyyymm/challenge/PIN

http://docs.oasis-open.org/ws-sx/ws-trust/yyyymm/challenge/OTP

An STS may choose not to support the optimization pattern above for PIN/OTP response. In some cases, an OTP challenge from the STS may include a dynamic random value that the requestor must feed into the OTP generating module before an OTP response is computed. In such cases, the optimized response pattern may not be usable.

8.8 Challenge Examples

8.8.1 Text and choice challenge

Here is an example of a user interaction challenge using both text and choice challenges. In this example, a user requests a custom token using a username/password for authentication. The STS uses the challenge mechanism to challenge the user for additional information in the form of a secret question (i.e., Mother’s maiden name) and an age group choice. The challenge additionally includes one contextual data item that needs to be reflected back in the response. The user interactively provides the requested data and, once validated, the STS issues the requested token. All messages are sent over a protected transport using SSLv3.

The requestor sends the initial request that includes the username/password for authentication as follows.

<S11:Envelope ...>

  <S11:Header>

    ...

    <wsse:Security>

      <wsse:UsernameToken>

        <wsse:Username>Zoe</wsse:Username>

        <wsse:Password Type="http://...#PasswordText">ILoveDogs</wsse:Password>

      </wsse:UsernameToken>

    </wsse:Security>

  </S11:Header>

  <S11:Body>

    <wst:RequestSecurityToken>

      <wst:TokenType>http://example.org/customToken</wst:TokenType>

      <wst:RequestType>...</wst:RequestType>

    </wst:RequestSecurityToken>

  </S11:Body>

</S11:Envelope>

The STS issues a challenge for additional information using the user interaction challenge mechanism as follows.

<S11:Envelope ...>

  <S11:Header>

    ...

  </S11:Header>

  <S11:Body>

    <wst:RequestSecurityTokenResponse>

      <wst14:InteractiveChallenge xmlns:wst14="..." >

        <wst14:Title>

          Please answer the following additional questions to login.

        </wst14:Title>

        <wst14:TextChallenge RefId=http://.../ref#text1

              Label="Mother’s Maiden Name" MaxLen=80 />

        <wst14:ChoiceChallenge RefId="http://.../ref#choiceGroupA"

              Label="Your Age Group:" ExactlyOne="true">

          <wst14:Choice RefId="http://.../ref#choice1" Label="18-30" />

          <wst14:Choice RefId="http://.../ref#choice2" Label="31-40" />

          <wst14:Choice RefId="http://.../ref#choice3" Label="41-50" />

          <wst14:Choice RefId="http://.../ref#choice4" Label="50+" />

        </wst14:ChoiceChallenge>

        <wst14:ContextData RefId="http://.../ref#cookie1"> ... </wst14:ContextData>

      </wst14:InteractiveChallenge>

    </wst:RequestSecurityTokenResponse>

  </S11:Body>

</S11:Envelope>

The requestor receives the challenge, provides the necessary user experience for soliciting the required inputs, and sends a response to the challenge back to the STS as follows.

<S11:Envelope ...>

  <S11:Header>

    ...

  </S11:Header>

  <S11:Body>

    <wst:RequestSecurityTokenResponse>

      <wst14:InteractiveChallengeResponse xmlns:wst14="..." >

        <wst14:TextChallengeResponse RefId="http://.../ref#text1">

          Goldstein

        </wst14:TextChallengeResponse>

        <wst14:ChoiceChallengeResponse RefId="http://.../ref#choiceGroupA">

          <wst14:ChoiceSelected RefId="http://.../ref#choice3" />

        </wst14:ChoiceChallengeResponse>

        <wst14:ContextData RefId="http://.../ref#cookie1"> ... </wst14:ContextData>

      </wst14:InteractiveChallengeResponse>

    </wst:RequestSecurityTokenResponse>

  </S11:Body>

</S11:Envelope>

The STS validates the response containing the inputs from the user, and issues the requested token as follows.

<S11:Envelope ...>

  <S11:Header>

    ...

  </S11:Header>

  <S11:Body>

   <wst:RequestSecurityTokenResponseCollection>    <wst:RequestSecurityTokenResponse>

      <wst:RequestedSecurityToken>

        <xyz:CustomToken xmlns:xyz="...">

          ...

        </xyz:CustomToken>

      </wst:RequestedSecurityToken>

      <wst:RequestedProofToken>

        ...

      </wst:RequestedProofToken>

    </wst:RequestSecurityTokenResponse>

  </wst:RequestSecurityTokenResponseCollection>

  </S11:Body>

</S11:Envelope>

8.8.2 PIN challenge

Here is an example of a user interaction challenge using a text challenge for a secret PIN. In this example, a user requests a custom token using a username/password for authentication. The STS uses the text challenge mechanism for an additional PIN. The user interactively provides the PIN and, once validated, the STS issues the requested token. All messages are sent over a protected transport using SSLv3.

The requestor sends the initial request that includes the username/password for authentication as follows.

<S11:Envelope ...>

  <S11:Header>

    ...

    <wsse:Security>

      <wsse:UsernameToken>

        <wsse:Username>Zoe</wsse:Username>

        <wsse:Password Type="http://...#PasswordText">ILoveDogs</wsse:Password>

      </wsse:UsernameToken>

    </wsse:Security>

  </S11:Header>

  <S11:Body>

    <wst:RequestSecurityToken>

      <wst:TokenType>http://example.org/customToken</wst:TokenType>

      <wst:RequestType>...</wst:RequestType>

    </wst:RequestSecurityToken>

  </S11:Body>

</S11:Envelope>

The STS issues a challenge for a secret PIN using the text challenge mechanism as follows.

<S11:Envelope ...>

  <S11:Header>

    ...

  </S11:Header>

  <S11:Body>

    <wst:RequestSecurityTokenResponse>

      <wst14:InteractiveChallenge xmlns:wst14="..." >

        <wst14:TextChallenge

            RefId="http://docs.oasis-open.org/ws-sx/ws-trust/yyyymm/challenge/PIN"

              Label="Please enter your PIN" />

        </wst14:TextChallenge>    

      </wst14:InteractiveChallenge>

    </wst:RequestSecurityTokenResponse>

  </S11:Body>

</S11:Envelope>

The requestor receives the challenge, provides the necessary user experience for soliciting the PIN, and sends a response to the challenge back to the STS as follows.

<S11:Envelope ...>

  <S11:Header>

    ...

  </S11:Header>

  <S11:Body>

    <wst:RequestSecurityTokenResponse>

      <wst14:InteractiveChallengeResponse xmlns:wst14="..." >

        <wst14:TextChallengeResponse

            RefId="http://docs.oasis-open.org/ws-sx/ws-trust/yyyymm/challenge/PIN">

          9988

        </wst14:TextChallengeResponse>

      </wst14:InteractiveChallengeResponse>

    </wst:RequestSecurityTokenResponse>

  </S11:Body>

</S11:Envelope>

The STS validates the PIN response, and issues the requested token as follows.

<S11:Envelope ...>

  <S11:Header>

    ...

  </S11:Header>

  <S11:Body>

   <wst:RequestSecurityTokenResponseCollection>

    <wst:RequestSecurityTokenResponse>

      <wst:RequestedSecurityToken>

        <xyz:CustomToken xmlns:xyz="...">

          ...

        </xyz:CustomToken>

      </wst:RequestedSecurityToken>

      <wst:RequestedProofToken>

        ...

      </wst:RequestedProofToken>

    </wst:RequestSecurityTokenResponse>

   </wst:RequestSecurityTokenResponseCollection>

  </S11:Body>

</S11:Envelope>

8.8.3 PIN challenge with optimized response

The following example illustrates using the optimized PIN response pattern for the same exact challenge as in the previous section. This reduces the number of message exchanges to two instead of four. All messages are sent over a protected transport using SSLv3.

The requestor sends the initial request that includes the username/password for authentication as well as the response to the anticipated PIN challenge as follows.

<S11:Envelope ...>

  <S11:Header>

    ...

    <wsse:Security>

      <wsse:UsernameToken>

        <wsse:Username>Zoe</wsse:Username>

        <wsse:Password Type="http://...#PasswordText">ILoveDogs</wsse:Password>

      </wsse:UsernameToken>

    </wsse:Security>

  </S11:Header>

  <S11:Body>

    <wst:RequestSecurityToken>

      <wst:TokenType>http://example.org/customToken</wst:TokenType>

      <wst:RequestType>...</wst:RequestType>

      <wst14:InteractiveChallengeResponse xmlns:wst14="..." >

        <wst14:TextChallengeResponse

            RefId="http://docs.oasis-open.org/ws-sx/ws-trust/yyyymm/challenge/PIN">

          9988

        </wst14:TextChallengeResponse>

      </wst14:InteractiveChallengeResponse>

    </wst:RequestSecurityToken>

  </S11:Body>

</S11:Envelope>

The STS validates the authentication credential as well as the optimized PIN response, and issues the requested token as follows.

<S11:Envelope ...>

  <S11:Header>

    ...

  </S11:Header>

  <S11:Body>

   <wst:RequestSecurityTokenResponseCollection>

    <wst:RequestSecurityTokenResponse>

      <wst:RequestedSecurityToken>

        <xyz:CustomToken xmlns:xyz="...">

          ...

        </xyz:CustomToken>

      </wst:RequestedSecurityToken>

      <wst:RequestedProofToken>

        ...

      </wst:RequestedProofToken>

    </wst:RequestSecurityTokenResponse>

   </wst:RequestSecurityTokenResponseCollection>

  </S11:Body>

</S11:Envelope>

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]