OTP-WSS-Token

John Linn, RSA Laboratories

DRAFT: 24 May 2005

OTP-WSS-Token

• Goal: support OTP-based authentication from claimants to relying parties (RPs) in web service environments

• XML-encoded <otps-wst:OTPToken> object carries OTP-based authenticator data

• Functionally analogous to OASIS Web Services Security TC's UsernameToken Profile, but tailored to support OTP authentication methods

• Can be applied to support token devices operating in multiple modes, including time-based, challenge-response, counter-based— Challenges may be client-generated or obtained from verifier through out-

of-band means

OTP-WSS-Token: Operational Context

• OTP authentication can be integrated with Web Services Security: SOAP Message Security (WSS:SMS) in different ways, such as:

— Directly, using the OTPToken type proposed in this draft

— Indirectly, using SAML message token with assertion based on OTP authentication

— At a stream level, as by using OTP to authenticate WS-SecureConversation or SASL

• This draft's approach authenticates a single SOAP request, and is particularly suited for stand-alone actions like acquiring login credentials

OTP-WSS-Token: Recent and Potential Changes

• Technical changes in 1-0d2 draft, 8 April 2005

— Namespace now "otps-wst"

— No default algorithm identifier

• Potential changes to consider

— Token identifier change from TokID (XML ID type) to WSS:SMS wsu:Id type to simplify WSS:SMS integration

— Further treatment of OTPToken placement and referencing in WSS:SMS environment (see next slide)

• To identify OTPToken(s) used for authentication

• Possibly to identify OTPToken(s) used to provide key derivation inputs?

Proposals for Referencing OTPTokens in WSS:SMS

• Recommended placement: direct descendant of <wsse:Security> header, not Embedded

— Working assumption: in the usual case, OTPTokens will be carried within the messages they authenticate, not referenced from external sources

— Can reference using OTPToken's identifier value

• Can qualify reference with ValueType of #OTPToken

• Perhaps use KeyIdentifier reference to obtain OTPToken's OTP value as input for key derivation?

— Q: Define a key derivation algorithm within the document?

OTP-WSS-Token: OTPToken Elements

• All optional except <otps-wst:OTP> which carries the value being presented for OTP-based authentication

— Use of other elements may vary for different algorithms and use cases

• <otps-wst:TokTimestamp> carries time for time-based OTP algorithms and/or acts as a replay countermeasure

• <otps-wst:TokNonce> carries a challenge, acts as a replay countermeasure, and/or enables use of multiple OTP results within a single <otps-wst:TokTimestamp> time quantum

• <otps-wst:TokState> carries additional state elements as needed— e.g., counter for counter-based OTP algorithms

• <otps-wst:TokPIN> carries user's PIN data

• <otps-wst:ServID> identifies target service for OTP authentication— Q: priority for support within token vs. externally?

• <otps-wst:ContID> provides in-band linkage to continue multi-step authentication transactions

— Q: priority for support within token vs. externally?

OTP-WSS-Token: OTPToken Attributes

• TokQual attribute group can identify user's device by user identity (TokUser) and/or serial number (Serial)

— Must provide at least one form to construct valid OTPToken

• Optional TokID attribute supports linkage to <otps-wst:OTPToken> data object from other message elements

• Optional TokAlg attribute identifies token device's OTP algorithm

— Must provide value unless unambiguous from context

• Optional TokOTPTransform attribute identifies preprocessing performed on token device output before inclusion in <otps-wst:OTP>

OTP-WSS-Token: Exception Cases

• In WSS:SMS context, can indicate authentication failures with SOAP fault and FailedAuthentication value with Fault/Detail entry— If New PIN needed, can contact separate PIN change service,

then generate new <otps-wst:OTPToken> and make a new request

— If additional OTP needed for resynchronization, can generate new <otps-wst:OTPToken> with next value and retry using <otps-wst:ContID>

— Additional cases and recovery actions can be profiled separately

OTP-WSS-Token: OTPToken Schema

<complexType name="OTPToken">

<annotation>

<documentation>

Type definition for token-based authentication

</documentation>

</annotation>

<sequence>

<element name="TokTimestamp" type="dateTime" minOccurs="0"/>

<element name="TokNonce" type="base64Binary" minOccurs="0"/>

<element name="TokState" type="base64Binary" minOccurs="0"/>

<element name="TokPIN" type="string" minOccurs="0"/>

<element name="ServID" type="string" minOccurs="0"/>

<element name="ContID" type="integer" minOccurs="0"/>

<element name="OTP" type="string"/>

</sequence>

<attributeGroup ref="otps-wst:TokQual"/>

<attribute name="TokID" type="ID" use="optional"/>

<attribute name="TokAlg" type="anyURI" use="optional"/>

<attribute name="TokOTPTransform" type="anyURI" use="optional"/>

</complexType>

OTP-WSS-Token: Example OTPToken

<otps-wst:OTPToken TokID="AnExampleToken" TokUser="J. Sample User">

<otps-wst:TokTimestamp>2005-02- 15T20:25:42Z</rsawst:TokTimestamp>

<otps-wst:TokNonce>VXUzoS1a4r7kQQ5c/Iua4LqKeq3ciFzEv/MbZhA==</rsawst:TokNonce>

<otps-wst:TokPIN>876123</rsawst:TokPIN>

<otps-wst:OTP>142857</rsawst:OTP>

</otps-wst:OTPToken>

OTP-WSS-Token: Next Steps

• Consensus and stabilization on document content

• Proceed towards contribution derived from content, likely to OASIS WSS TC?