Network Working Group P. Hoyer Internet-Draft ActivIdentity Intended status: Standards Track T. Moses Expires:January 7,July 31, 2010 Entrust M. Pei VeriSign S. Machani DiversinetJuly 6, 2009January 27, 2010 VALIDdraft-hoyer-valid-00draft-hoyer-valid-01 Abstract This document describes a Web-service interface standard for an authentication-data validation service that supports risk-based, multi-factor authentication.This standard enables enterprises to deploy best-of-breed solutions combining components from different vendors into the same infrastructure. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire onJanuary 7,July 31, 2010. Copyright Notice Copyright (c)20092010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of thisdocument (http://trustee.ietf.org/license-info).document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.Abstract This document describes a Web-service interface standard for an authentication-data validation service that supports risk-based, multi-factor authentication.This standard enables enterprises to deploy best-of-breed solutions combining componentsCode Components extracted fromdifferent vendors intothis document must include Simplified BSD License text as described in Section 4.e of thesame infrastructure.Trust Legal Provisions and are provided without warranty as described in the BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Namespaces . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2. Authentication-Data Validation Service Interface overview . . 7 2.1. Authentication data communication . . . . . . . . . . . . 7 2.2. Verified attributes . . . . . . . . . . . . . . . . . . . 7 2.3. Challenge/response . . . . . . . . . . . . . . . . . . . . 7 2.4. Token collections . . . . . . . . . . . . . . . . . . . . 8 3. Communication patterns . . . . . . . . . . . . . . . . . . . . 9 3.1. In-band authentication . . . . . . . . . . . . . . . . . . 9 3.1.1. In-band Challenge/Response . . . . . . . . . . . . . . 9 3.1.2. In-band 2 way Challenge/Response . . . . . . . . . . . 10 3.2. Out-of-band challenge . . . . . . . . . . . . . . . . . .1011 3.3. Out-of-band response . . . . . . . . . . . . . . . . . . .1112 3.4. Client supplies challenge . . . . . . . . . . . . . . . .1213 3.5. End-user obtains assertions Out-of-band from server . . .1213 4. Asynchronous communication . . . . . . . . . . . . . . . . . .1415 4.1. Out-of-band challenge . . . . . . . . . . . . . . . . . .1415 4.2. Out-of-band response . . . . . . . . . . . . . . . . . . .1415 5. User centric and device centric (pseudonymous) authentication models . . . . . . . . . . . . . . . . . . . . 16 5.1. User Centric authentication model . . . . . . . . . . . . 16 5.2. Device Centric authentication model . . . . . . . . . . . 16 6. Authentication moving factor resync . . . . . . . . . . . . .15 5.1.17 6.1. Automatic re-sync based on authentication data . . . . . .15 5.2.17 6.2. Manual re-sync based on presenting moving factor values .15 6.17 7. Policy models . . . . . . . . . . . . . . . . . . . . . . . .16 7.18 8. Common message contents . . . . . . . . . . . . . . . . . . .18 7.1.20 8.1. Request Security Token . . . . . . . . . . . . . . . . . .18 7.2.20 8.2. Request Security Token Response . . . . . . . . . . . . .19 8.21 9. Mechanism-specific message contents . . . . . . . . . . . . .21 9.23 10. Extensibility . . . . . . . . . . . . . . . . . . . . . . . .22 10.24 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .23 10.1.25 11.1. XML namespace registration . . . . . . . . . . . . . . . .23 10.2.25 11.2. VALID Version Registry . . . . . . . . . . . . . . . . . .23 11.25 12. Security Considerations . . . . . . . . . . . . . . . . . . .24 12.26 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .25 13.27 14. References . . . . . . . . . . . . . . . . . . . . . . . . . .26 13.1.28 14.1. Normative References . . . . . . . . . . . . . . . . . . .26 13.2.28 14.2. Informative References . . . . . . . . . . . . . . . . . .2729 Appendix A. WSDL . . . . . . . . . . . . . . . . . . . . . . . .2830 Appendix B. Mechanism specific message contents . . . . . . . . .3032 B.1. Username/password . . . . . . . . . . . . . . . . . . . .3032 B.2. In band one-time-password (OTP) . . . . . . . . . . . . .3133 B.3. In band one-time-password (OTP) token synchronization . . 35 B.4. In band challenge/response . . . . . . . . . . . . . . . .32 B.4.37 B.5. Out-of-band challenge . . . . . . . . . . . . . . . . . .34 B.5.39 B.6. Out-of-band response . . . . . . . . . . . . . . . . . . .35 B.6.40 B.7. Client supplies challenge . . . . . . . . . . . . . . . .37 B.7.42 B.8. Challenge/response with signature . . . . . . . . . . . .3843 Appendix C. Use Cases . . . . . . . . . . . . . . . . . . . . . .4045 C.1. Validation . . . . . . . . . . . . . . . . . . . . . . . .4045 C.1.1. OTP Validation . . . . . . . . . . . . . . . . . . . .4045 C.1.2. Challenge/Response Validation - Server generated challenge . . . . . . . . . . . . . . . . . . . . . .4045 C.1.3. Challenge/Response Validation - User generated challenge . . . . . . . . . . . . . . . . . . . . . .4146 C.1.4. 2-way mutual Challenge/Response Validation . . . . . . 46 C.1.5. OTP Validation + Server managed PIN . . . . . . . . .41 C.1.5.46 C.1.6. MatrixCardValidation - Server generated challenge . .4146 C.2.SynchornisationSynchronisation Use Cases . . . . . . . . . . . . . . . .4146 C.2.1. OTP TokenAuto-Resync (NextOTP) . .Resync with the Next OTPs . . . . . . . . .4147 C.2.2. OTP TokenManual-resync . . . . . .Resync with Moving Factor . . . . . . . . .4147 Appendix D. Requirements . . . . . . . . . . . . . . . . . . . .4248 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .4349 1. Introduction The Authentication-Data Validation Service Interface definition (VALID) describes a Web-service interface for a validation server. The specification reuses data definitions from [SAML], [WS-Security] and [WS-Trust] and operates over version 1.2 of [SOAP]. Upon successful validation, the validation server returns a SAML assertion containing verified attributes of the authenticated end-user or a hardware or software device under the end-user's control. Communications between the end-user and the application are not required to follow the Web-services programming model. 1.1. Key Words The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.2. Notation This specification uses the following syntax to define outlines for messages: The syntax appears as an XML instance. Characters are appended to elements and attributes to indicate cardinality: "?" (0 or 1) "*" (0 or more) "+" (1 or more) The character "|" is used to indicate a choice between alternatives. The characters "(" and ")" are used to indicate that contained items are to be treated as a group with respect to cardinality or choice. The characters "[" and "]" are used to call out references and property names. Additional child elements and/or attributes MAY be added at the indicated extension points (see Section9)10) but MUST NOT contradict the semantics of the parent and/or owner, respectively. By default, if a receiver does not recognize an extension, the receiver SHOULD ignore the extension; exceptions to this processing rule, if any, are clearly indicated below. XML namespace prefixes (see Table 1) are used to indicate the namespace of the element being defined. Elements and Attributes defined by this specification are referred to in the text of this document using XPath 1.0 expressions. Extensibility points are referred to using an extended version of this syntax: An element extensibility point is referred to using {any} in place of the element name. This indicates that any element name can be used, from any namespace other than the namespace of this specification. An attribute extensibility point is referred to using @{any} in place of the attribute name. This indicates that any attribute name can be used, from any namespace other than the namespace of this specification 1.3. Namespaces The following XML namespace prefixes are used in the specification. env: http://www.w3.org/2003/05/soap-envelope pskc: urn:ietf:params:xml:ns:keyprov:pskc saml: urn:oasis:names:tc:SAML:2.0:assertion valid: urn:ietf:params:xml:ns:valid wsp: http://www.w3.org/ns/ws-policy wss: http://docs.oasis-open.org/wss/2004/01/ oasis-200401-wss-wssecurity-secext-1.0 wst: http://docs.oasis-open.org/ws-sx/ws-trust/200512 wst14: http://docs.oasis-open.org/ws-sx/ws-trust/200802 xsd: http://www.w3.org/2001/XMLSchema 1.4. Terminology The following terms are used in this document. Application: The system component that controls access to sensitive resources by authenticated end-users. Authentication data: Information exchanged between the end-user and the validation server as part of the authentication process. For example a password, an OTP, the response to a challenge, etc. Authentication policy: The combination of authentication mechanisms required to complete successfully before access may be granted. Client : See "Application". End-user: The authentication subject. Moving factor: The factor that makes a one time password computationally unique in combination with a fixed key. For example the increasing event counter value in [HOTP]. Server: See "Validation server". Validation server: The system component that validates authentication data. 2. Authentication-Data Validation Service Interface overview The Authentication-Data Validation Service Interface allows communication of the following data elements in several different communication patterns as described in Section 3. The interface is based mainly on [WS-Trust]. The following sections apply terminologies and concepts defined in [WS-Trust]. 2.1. Authentication data communication The specific requirements for authentication data communication depend upon the specific authentication mechanism. In-band authentication data SHALL be passed in the body of <wst: RequestSecurityToken> and <wst:RequestSecurityTokenResponse> elements. 2.2. Verified attributes Upon successful validation of the authentication data, the validation server SHALL issue a SAML assertion containing verified end-user or token attributes, depending if the server is validating user identities (user centric authentication) or device/token (pseudonomous - token centric authentication) . The client MAY provide a <wsp:Policy> element indicating which attributes it requires. Required attributes SHALL be referenced using the <saml: Attribute> element, with the <saml:AttributeValue> child element omitted. The validation server MAY include the sub-set of the requested attributes whose verified values are known to it. Otherwise, the validation server SHALL include all verified attributes whose values are known to it. These attributes MUST be included in the SAML assertion. They MUST also be included in a separate <wst:Claims> element. In this way, the application may treat the assertion as opaque data, extracting any attributes it requires from the <wst: Claims> element. Attributes SHALL be expressed as <saml:Attribute> elements in accordance with the SAML V2.0 X.500/LDAP Attribute Profile. 2.3. Challenge/response Multi-step authentication mechanisms are supported as shown here. Message Direction Cardinality Request Client -> Server Exactly one Response Client <-> Server (Zero or more request-response pairs) Response Client <- Server Exactly one The protocol terminates when the validation server either includes at least one security token according to [WS-Trust] in the response or returns an <env:Body/env:Fault> element. 2.4. Token collections A set of tokens MAY be requested and issued in a single set of exchanges with the validation server using the "token collection" features of WS-Trust. 3. Communication patterns The folllowing communication patterns are supported: 3.1. In-band authentication __________ _____________ | | | | | End-user |------------------------->| Application | |__________| 1. Access application |_____________| | \ | | 2. Obtain assertion | > VALID | | _____\|/____ / | | | Validation | | server | |____________| In-band authentication The end-user accesses the application (1). The application supplies the authentication data to the validation server and receives an assertion in return (2). For in-band challenge/response authentication mechanisms, additional messages between the end-user and the validation server MUST be relayed by the application. 3.1.1. In-band Challenge/Response __________ _____________ | | | | | End-user |------------------------->| Application | |__________| 1. Access application |_____________| 4. In-band challenge /|\ \ 5. In-band response | | 2. Request assertion | > VALID 3. return challenge | | 6. obtain assertion | | _____\|/____ / | | | Validation | | server | |____________| Figure 1: In-band Challenge/Response The "in-band challenge/response" pattern is shown in Figure 1. The application invokes the validation server (2). The validation server returns a challenge (3). The application passes the challenge to the end-user (4). The end-user may or may not transform the challenge and sends the result to the validation server in-band (5). The application supplies the authentication data to the validation server and receives an assertion in return (6). 3.1.2. In-band 2 way Challenge/Response __________ _____________ | | | | | End-user |------------------------------>| Application | |__________| 1. In-band client challenge |_____________| 4. In-band server resp & challenge /|\ \ 5. In-band client response | | 2. Request assertion | > VALID 3. return server resp & | | server challenge | | 6. obtain assertion | | _____\|/____ / | | | Validation | | server | |____________| Figure 2: In-band 2 way Challenge/Response The "In-band 2 way challenge/response" pattern is shown in Figure 2. This pattern is based on the In-band Challenge/Response pattern but authenticates both the server and the client. The application receives an in-band client challenge (1). The application invokes the validation server (2). The validation server returns the response to the client challenge and a server challenge (3). The application passes the server response and server challenge to the end-user (4). The end-user may or may not transform the server challenge and after verifying the server response sends the result to the validation server in-band (5). The application supplies the authentication data to the validation server and receives an assertion in return (6). 3.2. Out-of-band challenge __________ _____________ | | | | -->| End-user |--------------------->| Application | | |__________| 1. Access |_____________| | application | \ | | | | 4. In-band | | | Response | | | 2. Request | | | assertion | >VALID | 3. Out-of-band | | | challenge 5. Obtain | | | assertion | | | | | | _____\|/____/ | | | | | Validation | -------------------------------------| server | |____________| Out-of-band challenge The "out-of-band challenge" pattern is shown in Figure 2. The application invokes the validation server (2). The validation server then contacts the end-user out-of-band with a challenge (3). The end-user may or may not transform the challenge and then passes it back to the application (4), which then passes it to the validation server and obtains an assertion in response (5). 3.3. Out-of-band response __________ _____________ | | | | ---| End-user |<-------------------->| Application | | |__________| 1. Access |_____________| | application /|\ \ | | | | 4. In-band | | | challenge 2. Request | | | assertion | | | 5. Out-of-band | | | response 3. Return | >VALID | challenge | | | | | | 6. Send | | | assertion | | | | | | _____\|/____ / | | | | | Validation | ------------------------------------>| server | |____________| Out-of-band response The "out-of-band response" pattern is shown in Figure 3. The application invokes the validation server (2). The validation server returns a challenge (3). The application passes the challenge to the end-user (4). The end-user may or may not transform the challenge and sends the result to the validation server out-of-band (5). The validation server sends the assertion to the application (6). 3.4. Client supplies challenge __________ _____________ | | | | -->| End-user |-------------------->| Application | | |__________| 2. Supply |_____________| | challenge | \ | and response | | | | | | 3. Obtain | | | assertion | | | 1. Obtain | >VALID | challenge | | | | | | | | | | | | _____\|/____ / | | | | | Validation | ------------------------------------| server | |____________| Client supplies challenge The "client supplies challenge" pattern is shown in Figure 4. The end-user obtains a challenge out-of-band (1), calculates the response and send both challenge and response to the application (2). The application then uses the challenge and response to obtain an assertion from the validation server (3). 3.5. End-user obtains assertions Out-of-band from server __________ _____________ | | | | | End-user |------------------------->| Application | |__________| 2. Access application |_____________| / | (passing assertion) |V | |A | |L | |I | ____________ |D | 1. Obtain assertion | | | ---------------------------->| Validation | \ | server | |____________| Out-of-band from server authentication The End-user obtains the assertion directly or though a proxy from the validation server (1) then passes the assertion to the Application for authentication (2). 4. Asynchronous communication The out-of-band communication patterns (Section 3.2 and Section 3.3) require asynchronous behavior, so that the application thread is not blocked while the challenge is being processed by the end-user. 4.1. Out-of-band challenge In the case of the "out-of-band challenge" pattern (Section 3.2), the validation server SHALL return an <env:Body/env:Fault> element with the value: valid:Pending The validation server, upon sending this value, and the application, upon receiving it, SHALL terminate the current session. Once the application receives the response from the end-user, it SHALL initiate a new session with the validation server. 4.2. Out-of-band response In the case of the "out-of-band response" pattern (Section 3.3), the validation server SHALL return an <env:Body/env:Fault> element with the value: valid:Pending The validation server, upon sending this value, and the application, upon receiving it, SHALL terminate the current session. Both parties MUST maintain the <wst:RequestSecurityToken/@Context> attribute as metadata associated with the initial session. In the subsequent session, they MUST use this <wst:RequestSecurityToken/@ Context> attribute value to correlate the challenge and response. 5. User centric and device centric (pseudonymous) authentication models There are two authentication models supported by this specification: 5.1. User Centric authentication model In this model the mapping between a specific user and the devices that belong to the specific user is known and managed by the validation server. This means that the authentication request will contain explicit user information in form of a UserId 5.2. Device Centric authentication model In this model the validation server does not have any knowledge to whom a specific device belongs. The user-device mapping will be at the appllication or service provider. This means that the authentication request MUST NOT contain uer information and that it MUST contain information to uniquely identify the device by using the <DeviceInfo> element as defined in [PSKC]. 6. Authentication moving factor resync Some authentication schemes gradually lose synchronization between client and server. In order to compensate for this, the server must accept authentication data values within a range, or window of the moving factor (e.g. the event counter used in event based one time password algorithms, see [HOTP]). When an authentication moving factor drifts to the edge of, or beyond, the server's window for a particular end-user, the server has to adjust its window. This process is known as resyncing. Resyncing erodes assurance in the authentication event. So, following a resync event, the validation server commonly requests a second authentication data value, which effectively restores the level of assurance provided by the authentication. The following two approaches to resyncing exist:5.1.6.1. Automatic re-sync based on authentication data In this approach, the resynchronisation is based only on the authentication data. In this apporach the server searches through an extended window of the moving factor(s) to see if it can match the presented authentication data. In this apporach two OTPs MUST be transmitted so that the server MUST try to match the first OTP with the extended window and also MUST match the second OTP with a normal window.5.2.6.2. Manual re-sync based on presenting moving factor values In this approach to resynchronisation, the server is given the exact value of the moving factor (e.g. the event counter value in [HOTP]) together with the OTP. The server MUST only set the moving factor(s) to the received value if the OTP matches successfully (given the new moving factor values).6.7. Policy models Authentication policy defines the requirements for accessing a resource in terms of mechanisms and their strengths, expressible in disjunctive normal form (that is a disjunction ("OR") of conjunctions ("AND"s)). This approach supports risk-based multi-factor authentication. Two policy models are supported. In the first model (see figuer below), the application is responsible for invoking the right combination of validation servers in order to satisfy the authentication policy. _____________ | | | Application | |_____________| | \ _____________|______________ | | | | > VALID | | | | ______|_____ _____|______ _____|______ / | | | | | | | Validation | | Validation | | Validation | | server | | server | | server | |____________| |____________| |____________| Policy aware application In the second model (see figure below), the authentication policy is managed through a choreography component, which appears to the application as a validation server and to the validation server as an application. _____________ | | | Application | |_____________| | \ | | | >VALID | | ______|_______ / | | | Choreography | |______________| | \ ______________|______________ | | | | >VALID | | | | _____|______ _____|______ _____|______/ | | | | | | | Validation | | Validation | | Validation | | server | | server | | server | |____________| |____________| |____________| Policy aware application In either model, the application MAY supply information about the resource to which access is requested in a <wsp:AppliesTo> element. The validation server MAY restrict the resources to which the application SHALL limit access by including a <wsp:AppliesTo> element in its response. This is not intended as an access-control solution; it is intended only to enforce an appropriate level of authentication assurance, based on the sensitivity of the resource, where the sensitivity is not uniform across all the resources accessible by the application.7.8. Common message contents This section describes the mechanism-independent requirements for message contents.7.1.8.1. Request Security Token The message-independent requirements for "request security token" messages are shown in this example: <wst:RequestSecurityToken Context=" ... "> <wst:TokenType> http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0 </wst:TokenType> <wst:RequestType> http://www.docs.oasis-open.org/ws-sx/ws-trust/200512/Issue </wst:RequestType> <wsp:AppliesTo> ... </wsp:AppliesTo> ? <wsp:Policy> ? <saml:Attribute> + </wsp:Policy> <wst:Lifetime> ... </wst:Lifetime> ? </wst:RequestSecurityToken> <wst:TokenType> - MANDATORY The client SHALL set the value 'http:// docs.oasis-open.org/wss/ oasis-wss-saml-token-profile-1.1#SAMLV2.0'. If the server detects a different value it MAY return a fault. <wst:RequestType> - MANDATORY The client SHALL set the value 'http://www.docs.oasis-open.org/ws-sx/ws-trust/200512/Issue' If the server detects a different value it SHALL return a fault. <wsp:AppliesTo> - OPTIONAL If present, the client MUST set the value to a URI identifying the resource, or class of resource, to which access is requested. If the validation server is policy-aware, it SHOULD use this value to select the applicable authentication policy. Otherwise, it MUST ignore it. <wsp:Policy/saml:Attribute> - OPTIONAL If present, this element MUST identify a verified end-user attribute requested from the validation server. Even if the validation server cannot provide all the requested attributes, it SHOULD proceed with the validation process. <wst:Lifetime> - OPTIONAL The client MAY specify the lifetime of the requested assertion using this element. The server MUST verify that the requested lifetime conforms with its own policy for assertion lifetimes. <wst:RequestSecurityToken/@Context> - MANDATORY This attribute MUST be set by the client. It is an opaque value to the server. The server MUST use the value as the<wst: RequestSecurityToken/@Context><wst:RequestSecurityToken/@ Context> value in the response.7.2.8.2. Request Security Token Response The common requirements for the final "request security token response" message are shown in this example: <wst:RequestSecurityTokenResponse Context=" ... "> <wst:RequestedSecurityToken> ... </wst:RequestedSecurityToken> <wst:Claims Dialect="..."> <saml:Attribute/> + </wst:Claims> ? <wsp:AppliesTo> ... </wsp:AppliesTo> ? <wsp:Policy> ? <wsp:RequiredElement> + </wsp:Policy> </wst:RequestSecurityTokenResponse> If the authentication data failed to validate, then the server MUST include the <env:Body/env:Fault> element containing the value wst: FailedAuthentication. In this case, it SHALL NOT include any other elements. If the authentication data failed to validate due to missing authentication data, then the server MUST include the <env:Body/ env:Fault> element containing the value valid: MissingAuthenticationData.In this case, it SHALL NOTThe server can optionally includeany other elements.elements indicating which authentication data is missing. <wst:RequestedSecurityToken> - OPTIONAL - Zero or more If validation is complete and successful, then the server SHALL include a SAML assertion containing verified end-user attributes. Otherwise this element SHALL be omitted. The server SHOULD set the assertion lifetime in accordance with the lifetime specified in the request, or its own policy, whichever is more restrictive. <wst:RequestType> - MANDATORY The client SHALL set the value 'http://www.docs.oasis-open.org/ws-sx/ws-trust/200512/Issue' If the server detects a different value it SHALL return a fault. <wst:Claims> - OPTIONAL If present, the server SHALL populate this element with verified end-user attributes. <wst:Claims/@Dialect> - OPTIONAL The server SHALL set the value "urn:oasis:names:tc:SAML:2.0". The client MAY reject responses containing a different value. <wpt:AppliesTo> - OPTIONAL If the authentication assurance level achieved is suitable only for a sub-set of resources, the validation server MUST set a value that identifies that sub- set.The client SHOULD restrict access to resources falling within the sub-set defined by this element. <wst:RequestSecurityToken/@Context> - MANDATORY The server MUST include the @Context value from the request. The client SHOULD load the context identified by the value.8.9. Mechanism-specific message contents The mechanism-specific requirements for message contents are described in the appendices. These MAY be used in any combination.9.10. Extensibility This section lists a few common extension points provided by VALID: New VALID Version: Whenever it is necessary to define a new version of this document then a new version number has to be allocated to refer to the new specification version. The rules for extensibililty are defined in Section10. 10.11. 11. IANA Considerations10.1.11.1. XML namespace registration This section registers a new XML namespace, "urn:ietf:params:xml:ns:valid", per the guidelines in [RFC3688]. URI: urn:ietf:params:xml:ns:valid Registrant Contact: Philip Hoyer (phoyer@actividentity.com). XML: BEGIN <?xml version="1.0"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="content-type" content="text/html;charset=iso-8859-1"/> <title>VALID Namespace</title> </head> <body> <h1>Namespace for VALID</h1> <h2>urn:ietf:params:xml:ns:valid</h2> <p>See <a href="[URL of published RFC]">RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this specification.]</a>.</p> </body> </html> END10.2.11.2. VALID Version Registry IANA is requested to create a registry for VALID version numbers. The registry has the following structure: VALID Version | Specification +---------------------------+---------------- | 1.0 | [This document] Standards action is required to define new versions of VALID. It is not envisioned to depreciate, delete, or modify existing VALID versions.11.12. Security Considerations The validation server SHOULD authenticate the client and limit access to the validation service only to authorized clients. This MAY be achieved by object level security (e.g xml signatures as defined in [XMLDSIG] applied to the <env:Header> and <env:Body> elements), transport layer security (e.g. [TLS]) or network layer security (e.g. isolated network segment). The application MAY authenticate the validation server. This MAY be achieved by object level security (e.g. xml signatures as defined in [XMLDSIG] applied to the <env:Header> and <env:Body> elements or assertion), transport layer security (e.g. TLS) or network layer security (e.g. isolated network segment). The chosen authentication mechanism MUST ensure freshness of the exchanges in order to detect replay attacks. Privacy of the authentication data and end-user attributes MAY also require protection.12.13. Acknowledgements The authors of this draft would like to thank the following people for their feedback: Siddharth Bajaj, David M'Raihi, Mike Davis and Peter Tapling. This work is based on earlier work by the members of OATH (Initiative for Open AuTHentication), see [OATH], to specify a format that can be freely distributed to the technical community.13.14. References13.1.14.1. Normative References [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005. [SAML] Cantor, S., Kemp, J., Philpott, R., and E. Maler, "WS- Trust 1.4", URL: http://docs.oasis-open.org/security/saml/ v2.0/saml-core-2.0-os.pdf, OASIS Standard Specification, March 2005. [SOAP] Gudgin, M., "Simple Object Access Protocol 1.2", URL: http://www.w3.org/TR/soap12-part1/, W3C Recommendation, April 2007. [WS-Security] Nadalin, A., Kaler, C., Monzillo, R., and P. Hallam-Baker, "Web Services Security: SOAP Message Security 1.1", URL: http://www.oasis-open.org/committees/download.php/16790/ wss-v1.1-spec-os-SOAPMessageSecurity.pdf, OASIS Standard Specification, Feb 2006. [WS-Trust] Nadalin, A., Goodner, M., Gudgin, M., Barbir, A., and H. Granqvist, "WS-Trust 1.4", URL: http:// docs.oasis-open.org/ws-sx/ws-trust/v1.4/ws-trust.html, OASIS Standard Specification, Feb 2009. [WSS_UsernameTokenProfile] Nadalin, A., Kaler, C., Monzillo, R., and P. Hallam-Baker, "Web Services Security UsernameToken Profile 1.1", URL: http://docs.oasis-open.org/wss/v1.1/ wss-v1.1-spec-os-UsernameTokenProfile.pdf, OASIS Standard Specification, Feb 2006. [XMLDSIG] Eastlake, D., "XML-Signature Syntax and Processing", URL: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/, W3C Recommendation, February 2002. [XMLENC] Eastlake, D., "XML Encryption Syntax and Processing.", URL: http://www.w3.org/TR/xmlenc-core/, W3C Recommendation, December 2002.13.2.14.2. Informative References [HOTP] MRaihi, D., Bellare, M., Hoornaert, F., Naccache, D., and O. Ranen, "HOTP: An HMAC-Based One Time Password Algorithm", RFC 4226, December 2005. [OATH] "Initiative for Open AuTHentication", URL: http://www.openauthentication.org. [OCRA] MRaihi, D., Rydell, J., Naccache, D., Machani, S., and S. Bhajaj, "OCRA: OATH Challenge-Response Algorithms", URL: http://docs.oasis-open.org/security/saml/v2.0/ saml-core-2.0-os.pdf, IETF Standard draft, January 2008. [PSKC] Hoyer, P., Pei, M., and S. Machani, "Portable Symmetric Key Container (PSKC)", URL: http://tools.ietf.org/html/ draft-ietf-keyprov-pskc-05, IETF Standard draft, January 2010. [RFC2396] Berners-Lee, T., Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", BCP 26, RFC 2396, August 1998. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [XMLNS] "Namespaces in XML", W3C Recommendation , URL: http://www.w3.org/TR/1999/REC-xml-names-19990114, January 1999. Appendix A. WSDL The validation server WSDL is shown here. <?xml version="1.0" encoding="utf-8"?> <definitions targetNamespace="urn:ietf:params:xml:ns:valid" xmlns:valid="urn:ietf:params:xml:ns:valid" xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:wss="http://docs.oasis-open.org/wss/2004/01/ oasis-200401-wss-wssecurity-secext-1.0" xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512" xmlns:wst14="http://docs.oasis-open.org/ws-sx/ws-trust/200802" xmlns:wsp="http://www.w3.org/ns/ws-policy" xmlns="http://schemas.xmlsoap.org/wsdl/"> <types> <xsd:schema xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:SOAP="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:valid="urn:ietf:params:xml:ns:valid" xmlns:wss="http://docs.oasis-open.org/wss/2004/01/ oasis-200401-wss-wssecurity-secext-1.0" xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512" xmlns:wst14="http://docs.oasis-open.org/ws-sx/ws-trust/200802" xmlns:wsp="http://www.w3.org/ns/ws-policy" xmlns:WSDL="http://schemas.xmlsoap.org/wsdl/" targetNamespace="urn:ietf:params:xml:ns:valid" elementFormDefault="unqualified" attributeFormDefault="unqualified"> <xsd:element name="RequestSecurityToken"ref="wst:RequestSecurityTokenType"/>type="wst:RequestSecurityTokenType"/> <xsd:element name="RequestSecurityTokenResponse"ref="wst:RequestSecurityTokenResponseType"/>type="wst:RequestSecurityTokenResponseType"/> <xsd:element name="OTP" type="xsd:string"/> <xsd:elementname="KeyId"name="NextOTP" type="xsd:string"/> <xsd:element name="SyncCounter" type="xsd:integer"/> <xsd:element name="SyncTime" type="xsd:integer"/> <xsd:element name="KeyId" type="pskc:string"/> <xsd:element name="DeviceInfo" type="pskc:DeviceInfo"/> </xsd:schema> </types> <message name="RequestSecurityToken"> <part name="request"type="valid:RequestSecurityTokenType"/>element="valid:RequestSecurityToken"/> </message> <message name="RequestSecurityTokenResponse"> <part name="response"type="valid:RequestSecurityTokenResponseType"/>element="valid:RequestSecurityTokenResponse"/> </message> <portType name="RequestSecurityToken"> <operation name="RequestSecurityTokenStart"> <input message="RequestSecurityToken"/> <output message="RequestSecurityTokenResponse"/> </operation> <operation name="RequestSecurityTokenContinue"> <input message="RequestSecurityTokenResponse"/> <output message="RequestSecurityTokenResponse"/> </operation> </portType> <bindingname="RequestSecurityTokenBinding">name="RequestSecurityTokenBinding" type="valid:RequestSecurityToken"> <SOAP:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="RequestSecurityTokenStart"> <SOAP:operation style="rpc"/> <input> <SOAP:body use="literal" namespace="urn:ietf:params:xml:ns:valid"/> </input> <output> <SOAP:body use="literal" namespace="urn:ietf:params:xml:ns:valid"/> </output> </operation> <operation name="RequestSecurityTokenContinue"> <SOAP:operation style="rpc"/> <input> <SOAP:body use="literal" namespace="urn:ietf:params:xml:ns:valid"/> </input> <output> <SOAP:body use="literal" namespace="urn:ietf:params:xml:ns:valid"/> </output> </operation> </binding> <service name="RequestSecurityToken"> <port name="RequestSecurityTokenStart" binding="RequestSecurityTokenBinding"> <SOAP:address location="http://localhost:8080/RequestSecurityTokenService"/> </port> <port name="RequestSecurityTokenContinue" binding="RequestSecurityTokenBinding"> <SOAP:address location="http://localhost:8080/RequestSecurityTokenService"/> </port> </service> </definitions> Appendix B. Mechanism specific message contents The follwing subsections describe the mechanism specific message contents for each considered mechanism: B.1. Username/password This section describes the mechanism-specific message contents username/password transferred in-band. There are no semantics implied by the order of the elements. The username and password transmission uses the web services security Username Token Profile [WSS_UsernameTokenProfile]. There are two steps to the protocol. Step 1 - Client sends "request security token" message containing authentication data to the validation server. <wst:RequestSecurityToken Context="..."> <wst:TokenType> http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0 </wst:TokenType> <wst:RequestType> http://www.docs.oasis-open.org/ws-sx/ws-trust/200512/Issue </wst:RequestType> <wsp:AppliesTo> ... </wsp:AppliesTo> ? <wsp:Policy> ? <saml:Attribute> + </wsp:Policy> <wst:Lifetime> ... </wst:Lifetime> ? <wss:UsernameToken> <wss:Username> ... </wss:Username> ? <wss:Password Type="...">Password</wss:Password> </wss:UsernameToken> </wst:RequestSecurityToken> <wst:RequestSecuityToken/wss:UsernameToken/wss:Username> If present, the client MUST set the value to the claimed username. The server MUST load the corresponding end-user record. Either the <wss: Username> element or the <valid:KeyId> element or both MUST be present. <wst:RequestSecuityToken/wss:UsernameToken/wss:Password> The client MUST set the value to password entered by the end user. The server MUST validate the password. The server MUST confirm that all the supplied authentication data are valid for a single end-user. Step 2 - Validation server sends "request security token response" message containing the authentication result to the client. <wst:RequestSecurityTokenResponse Context="..."> <wst:RequestedSecurityToken> <saml:Assertion> ... </saml:Assertion> </wst:RequestedSecurityToken> <wst:Claims> ... </wst:Claims> </wst:RequestSecurityTokenResponse> B.2. In band one-time-password (OTP) This section describes the mechanism-specific message contents for both time-based and event-based OTP protocols in which the OTP is transferred in-band. There are no semantics implied by the order of the elements. There are two steps to the protocol. Step 1 - Client sends "request security token" message containing authentication data to the validation server. <wst:RequestSecurityToken Context="..."> <wst:TokenType> http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0 </wst:TokenType> <wst:RequestType> http://www.docs.oasis-open.org/ws-sx/ws-trust/200512/Issue </wst:RequestType> <wsp:AppliesTo> ... </wsp:AppliesTo> ? <wsp:Policy> ? <saml:Attribute> + </wsp:Policy> <wst:Lifetime> ... </wst:Lifetime> ? <wss:UsernameToken> <wss:Username> ... </wss:Username> ? <valid:KeyId> ... </valid:KeyId> ? <pskc:DeviceInfo> ...</pskc:DeviceInfo> ? <valid:OTP> ... </valid:OTP> </wss:UsernameToken> </wst:RequestSecurityToken> <wst:RequestSecuityToken/wss:UsernameToken/wss:Username> If present, the client MUST set the value to the claimed username. The server MUST load the corresponding end-user record. Either the <wss: Username> element or the <valid:KeyId> element or both MUST be present. <wst:RequestSecuityToken/wss:UsernameToken/valid:KeyId> If present, the client MUST set the value to the KeyId of the key used for OTPtoken identifier.computations. The server MUST load the correspondingtokenkey record.. <wst:RequestSecuityToken/wss:UsernameToken/pskc:DeviceInfo> If present, the client MUST set the subelement values of pskc: DeviceInfo as defined in [PSKC] to value that uniuquely identify the device used for OTP computations. The server MUST load the corresponding device record.. <wst:RequestSecuityToken/wss:Security/valid:OTP> The client MUST set the value to the OTP value. The server MUST validate the OTP. The server MUST confirm that all the supplied authentication data are valid for a single end-user. Step 2 - Validation server sends "request security token response" message containing the authentication result to the client. <wst:RequestSecurityTokenResponse Context="..."> <wst:RequestedSecurityToken> <saml:Assertion> ... </saml:Assertion> </wst:RequestedSecurityToken> <wst:Claims> ... </wst:Claims> </wst:RequestSecurityTokenResponse> The following authentication data are defined by this specification. Name: valid:OTP Type: xsd:string Description: The output value of an end-user OTP token Name: valid:KeyId Type: xsd:string Description: The globally-unique identifier for key used in the OTPtokencomputation Name: pskc:DeviceInfo Type: pskc:DeviceInfo Description: A extensible element to uniquely identify devices used in OTP computations as defined in [PSKC]. B.3. In band one-time-password (OTP) token synchronization This section describes the mechanism-specific message contents for both time-based, event-based and time-event based OTP algorithms in which resynchronization data is sent in-band. Synchronization can happen either by sending two subsequqnt OTPs from the device or by sending only one OTP and the exact values of one or multiple moving factors (e.g.Counter, TIme, etc) used in the OTP algorithm. There are two steps to the protocol. Step 1 - Client sends "request security token" message containing synchronization data to the validation server. <wst:RequestSecurityToken Context="..."> <wst:TokenType> http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0 </wst:TokenType> <wst:RequestType> urn:ietf:params:xml:ns:valid#synchronization </wst:RequestType> <wsp:AppliesTo> ... </wsp:AppliesTo> ? <wsp:Policy> ? <saml:Attribute> + </wsp:Policy> <wst:Lifetime> ... </wst:Lifetime> ? <wss:UsernameToken> <wss:Username> ... </wss:Username> ? <valid:KeyId> ... </valid:KeyId> ? <pskc:DeviceInfo> ...</pskc:DeviceInfo> ? <valid:OTP> ... </valid:OTP> <valid:NextOTP> ... </valid:NextOTP>? <valid:SyncCounter> ... </valid:SyncCounter>? <valid:SyncTimer> ... </valid:SyncTime>? </wss:UsernameToken> </wst:RequestSecurityToken> <wst:RequestSecuityToken/wss:UsernameToken/wss:Username> If present, the client MUST set the value to the claimed username. The server MUST load the corresponding end-user record. Either the <wss: Username> element or the <valid:KeyId> element or both MUST be present. <wst:RequestSecuityToken/wss:UsernameToken/valid:KeyId> If present, the client MUST set the value to the KeyId of the key used for OTP computations. The server MUST load the corresponding key record.. <wst:RequestSecuityToken/wss:UsernameToken/pskc:DeviceInfo> If present, the client MUST set the subelement values of pskc: DeviceInfo as defined in [PSKC] to value that uniuquely identify the device used for OTP computations. The server MUST load the corresponding device record.. <wst:RequestSecuityToken/wss:Security/valid:OTP> The client MUST set the value to the OTP value. The server MUST validate the OTP within an extended synchronization window. <wst:RequestSecuityToken/wss:Security/valid:NextOTP> If present, the client MUST set this value to the next OTP value obtained from the OTP device. The server MUST validate this OTP within a normal validation window upon successful validation of the first OTP. <wst:RequestSecuityToken/wss:Security/valid:SyncCounter> If present, the client MUST set the value to the current OTP Counter moving factor from the claimed device. The server MUST validate that the given OTP corresponds to the given value in <valid:SyncCounter> and then set the Counter moving factor value to its own record for the claimed token. <wst:RequestSecuityToken/wss:Security/valid:SyncTime> If present, the client MUST set the value to the current OTP Time moving factor from the claimed device. The server MUST validate that the given OTP corresponds to the given value in <valid:SyncTime> and then set the Time moving factor value to its own record for the claimed token. The server MUST confirm that all the supplied synchronization data are valid and adjust its token record with the validated client data. Step 2 - Validation server sends "request security token response" message containing the synchronization result to the client. <wst:RequestSecurityTokenResponse Context="..."> <wst:RequestedSecurityToken> <saml:Assertion> ... </saml:Assertion> </wst:RequestedSecurityToken> <wst:Claims> ... </wst:Claims> </wst:RequestSecurityTokenResponse> The following synchronization data are defined by this specification. Name: valid:OTP Type: xsd:string Description: The output value of an end-user OTP token Name: valid:NextOTP Type: xsd:string Description: The output value of an end-user OTP token for the next consecutive OTP Name: valid:MovingFactor Type: xsd:integer Description: The current OTP moving factor in a client token. It is the event counter for an event based token, for example, HOTP. Name: valid:KeyId Type: xsd:string Description: The globally-unique identifier for the OTP token B.4. In band challenge/response This appendix describes the mechanism-specific message contents for challenge/response authentication mechanisms in which both the challenge and response are transferred in-band. Mechanisms of this type include: knowledge-based schemes, matrix card schemes and cryptographic token schemes. There are no semantics implied by the order of the elements. There are four steps to the protocol. Step 1 - Client sends "request security token" message containingthe claimed identity to the validation server. <wst:RequestSecurityToken Context="..."> <wst:TokenType> http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0 </wst:TokenType> <wst:RequestType> http://www.docs.oasis-open.org/ws-sx/ws-trust/200512/Issue </wst:RequestType> <wsp:AppliesTo> ... </wsp:AppliesTo> ? <wsp:Policy> ? <saml:Attribute> + </wsp:Policy> <wst:Lifetime> ... </wst:Lifetime> ? <wss:UsernameToken> <wss:Username> ... </wss:Username> ? <valid:KeyId> ... </valid:KeyId> ? <pskc:DeviceInfo> ...</pskc:DeviceInfo> ? </wss:UsernameToken> </wst:RequestSecurityToken> Step 2 - Validation server sends "request security token response" message containing the challenge to the client. <wst:RequestSecurityTokenResponse Context="..."> <wst14:InteractiveChallenge> ... </wst14:InteractiveChallenge> </wst:RequestSecurityTokenResponse> <wst:RequestSecurityTokenResponse/wst14:InteractiveChallenge> The server MUST set the contents to the value of the challenge. Step 3 - Client sends "request security token response" message containing the response to the server. <wst:RequestSecurityTokenResponse Context="..."> <wst14:InteractiveChallengeResponse> ... </wst14:InteractiveChallengeResponse> </wst:RequestSecurityTokenResponse> <wst:RequestSecurityTokenReponse/wst14:InteractiveChallengeResponse> The client MUST set the value to the transformed challenge. The server MUST validate the transformed challenge. Step 4 - Server sends "request security token response" message containing the authentication result to the client. <wst:RequestSecurityTokenResponse Context="..."> <wst:RequestedSecurityToken> <saml:Assertion> ... </saml:Assertion> </wst:RequestedSecurityToken> <wst:Claims> ... </wst:Claims> </wst:RequestSecurityTokenResponse>B.4.B.5. Out-of-band challenge This appendix describes the mechanism-specific message contents for challenge/response mechanisms in which the challenge is passed to the end-user out-of-band. Such mechanisms involve a separate communication channel, such as voice telephone, email or SMS. There are no semantics implied by the order of the elements. There are four steps to the protocol. Step 1 - Client sends "request security token" message containing claimed identity to the server. <wst:RequestSecurityToken Context="..."> <wst:TokenType> http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0 </wst:TokenType> <wst:RequestType> http://www.docs.oasis-open.org/ws-sx/ws-trust/200512/Issue </wst:RequestType> <wsp:AppliesTo> ... </wsp:AppliesTo> ? <wsp:Policy> ? <saml:Attribute> + </wsp:Policy> <wst:Lifetime> ... </wst:Lifetime> ? <wss:UsernameToken> <wss:Username> ... </wss:Username> <valid:KeyId> ... </valid:KeyId> ? </wss:UsernameToken> </wst:RequestSecurityToken> Step 2 - (Optional, in the asynchronous case) Server sends "pending" to the client. <env:Body/env:Fault> valid:Pending </env:Body/env:Fault> Both the client and server close the session. Step 3 - Once the client receives the response, it sends the "request security token response" message to the server.. <wst:RequestSecurityTokenResponse Context="..."> <wst14:InteractiveChallengeResponse> ... </wst14:InteractiveChallengeResponse> </wst:RequestSecurityTokenResponse> Step 4 - Server sends "request security token response" message containing the authentication result to the client. <wst:RequestSecurityTokenResponse Context="..."> <wst:RequestedSecurityToken> <saml:Assertion> ... </saml:Assertion> </wst:RequestedSecurityToken> <wst:Claims> ... </wst:Claims> </wst:RequestSecurityTokenResponse> The <wst:RequestSecurityTokenResponse/@Context> attribute value MUST be the same as that used in steps 1, 2 and 3.B.5.B.6. Out-of-band response This appendix describes the mechanism-specific message contents for challenge/response mechanisms in which the response is returned to the validation server out-of-band. Such mechanisms involve a separate communication channel, such as voice telephone, email or SMS. There are no semantics implied by the order of the elements. There are four steps to the protocol. Step 1 - Client sends "request security token" message containing the claimed identity to the server. <wst:RequestSecurityToken Context="..."> <wst:TokenType> http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0 </wst:TokenType> <wst:RequestType> http://www.docs.oasis-open.org/ws-sx/ws-trust/200512/Issue </wst:RequestType> <wsp:AppliesTo> ... </wsp:AppliesTo> ? <wsp:Policy> ? <saml:Attribute> + </wsp:Policy> <wst:Lifetime> ... </wst:Lifetime> ? <wss:UsernameToken> <wss:Username> ... </wss:Username> <valid:KeyId> ... </valid:KeyId> ? <pskc:DeviceInfo> ...</pskc:DeviceInfo> ? </wss:UsernameToken> </wst:RequestSecurityToken> Step 2 - Server sends "request security token response" message containing the challenge to the client. <wst:RequestSecurityTokenResponse Context="..."> <wst14:InteractiveChallenge> ... </wst14:InteractiveChallenge> </wst:RequestSecurityTokenResponse> Step 3 - (Optional - in the asynchronous case) Client sends "pending" to the server. <env:Body/env:Fault> valid:Pending </env:Body/env:Fault> Both the client and server close the session. Step 4 - Server sends "request security token response" message containing the authentication result to the client at the registered call-back interface. <wst:RequestSecurityTokenResponse Context="..."> <wst:RequestedSecurityToken> <saml:Assertion> ... </saml:Assertion> </wst:RequestedSecurityToken> <wst:Claims> ... </wst:Claims> </wst:RequestSecurityTokenResponse> The <wst:RequestSecurityTokenResponse/@Context> attribute value MUST be the same as that used in steps 1, 2 and 3.B.6.B.7. Client supplies challenge This appendix describes the mechanism-specific message contents for challenge/response mechanisms in which the client supplies the challenge. There are no semantics implied by the order of the elements. There are two steps to the protocol. Step 1 - Client sends "request security token" message to the validation server, passing both the challenge and the response. <wst:RequestSecurityToken Context="..."> <wst:TokenType> http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0 </wst:TokenType> <wst:RequestType> http://www.docs.oasis-open.org/ws-sx/ws-trust/200512/Issue </wst:RequestType> <wsp:AppliesTo> ... </wsp:AppliesTo> ? <wsp:Policy> ? <saml:Attribute> + </wsp:Policy> <wst:Lifetime> ... </wst:Lifetime> ? <wst14:InteractiveChallenge> ... </ wst14:InteractiveChallenge> <wst14:InteractiveChallengeResponse> ... </ wst14:InteractiveChallengeResponse> </wst:RequestSecurityToken> <wst14:InteractiveChallenge> The challenge. This may have been obtained from the validation server by means of another interface; one not specified here. <wst14:InteractiveChallengeResponse> The client MUST set the value to the transformed challenge. The server MUST validate the transformed challenge. Step 2 - Validation server returns "request security token response" message containing the assertion and claims to the client. <wst:RequestSecurityTokenResponse Context="..."> <wst:RequestedSecurityToken> <saml:Assertion> ... </saml:Assertion> </wst:RequestedSecurityToken> <wst:Claims> ... </wst:Claims> </wst:RequestSecurityTokenResponse>B.7.B.8. Challenge/response with signature This appendix describes the mechanism-specific message contents for challenge/response authentication mechanisms in which both the challenge and response are transferred in-band additionally to other parameters that are used in a signature (such as the simmetric signature in [OCRA]. There are no semantics implied by the order of the elements. There are four steps to the protocol. Step 1 - Client sends "request security token" message containingthe claimed identity to the validation server. <wst:RequestSecurityToken Context="..."> <wst:TokenType> http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0 </wst:TokenType> <wst:RequestType> http://www.docs.oasis-open.org/ws-sx/ws-trust/200512/Issue </wst:RequestType> <wsp:AppliesTo> ... </wsp:AppliesTo> ? <wsp:Policy> ? <saml:Attribute> + </wsp:Policy> <wst:Lifetime> ... </wst:Lifetime> ? <wss:UsernameToken> <wss:Username> ... </wss:Username> ? <valid:KeyId> ... </valid:KeyId> ? <pskc:DeviceInfo> ...</pskc:DeviceInfo> ? </wss:UsernameToken> </wst:RequestSecurityToken> Step 2 - Validation server sends "request security token response" message containing the set of challenges to the client. <wst:RequestSecurityTokenResponse Context="..."> <wst14:InteractiveChallenge> + ... </wst14:InteractiveChallenge> </wst:RequestSecurityTokenResponse> <wst:RequestSecurityTokenResponse/wst14:InteractiveChallenge> The server MUST set the contents to the value of the challenge(s). Step 3 - Client sends "request security token response" message containing the response(s) to the server. <wst:RequestSecurityTokenResponse Context="..."> <wst14:InteractiveChallengeResponse> + ... </wst14:InteractiveChallengeResponse> </wst:RequestSecurityTokenResponse> <wst:RequestSecurityTokenReponse/wst14:InteractiveChallengeResponse> The client MUST set the value to the parameters of the signature (e.g. amount is set to '10000'). The server MUST validate the transformed challenge. Step 4 - Server sends "request security token response" message containing the authentication result to the client. <wst:RequestSecurityTokenResponse Context="..."> <wst:RequestedSecurityToken> <saml:Assertion> ... </saml:Assertion> </wst:RequestedSecurityToken> <wst:Claims> ... </wst:Claims> </wst:RequestSecurityTokenResponse> Appendix C. Use Cases This section describes a comprehensive list of use cases that inspired the development of this specification. These requirements were used to derive the primary requirement that drove the design. These requirements are covered in the next section. These use cases also help in understanding the applicability of this specification to real world situations. C.1. Validation C.1.1. OTP Validation An application needs to validate an OTP obtained from an end-user, before providing the end-user with access to the requested resource(s). The validation request may pass through several SOAP intermediaries. If this is the case, the application message needs to specify the ultimate validation server endpoint via SOAP addressing means, e.g., by using SOAP actors, to avoid the OTP being evaluated several times. The response may include additional instructions to the token, for example that it needs to be resynchronized. This information must be defined inside a SOAP message. Valid credentials that can be passed in the valildation request: o Username, PIN + OTP o Username, OTP o TokenId + OTP o Array of TokenId + OTP C.1.2. Challenge/Response Validation - Server generated challenge An application needs to be able to use a token implementing the OCRA challenge/response algorithm for identifying the end user. The application requests from the validation server the challenge to be presented to the token (with the end-user keying the challenge into the token by means of a PINPad) or the challenge presented to the API of the connected token The application then uses the protocol to verify the response from the token C.1.3. Challenge/Response Validation - User generated challenge An application needs to be able to use a token implementing the OCRA challenge/response algorithm for identifying the end user. The application generates the challenge to be presented to the token (with the end-user keying the challenge into the token by means of a PINPad) or the challenge presented to the API of the connected token The application then uses the protocol to verify the challenge and the response from the token. C.1.4. 2-way mutual Challenge/Response Validation An application needs to be able to use a token implementing the OCRA 2 way challenge/response algorithm for identifying the end user and the user will identify the validation server. A connected token generates a client challenge and trasnmits it to the appllication, the application will accept the challenge and send it to the validation server, which will then return a server-response to the client challenge and a server challenge. The connected token will verify the server response and after successfully validating the server response sends uses the server-challenge to generate a client- response which is sent to the appliaction. The application then uses the protocol to verify the the response from the connected client. C.1.5. OTP Validation + Server managed PIN An application needs to be able to use a token implementing the TOTP algorithm as one factor and a server managed PIN as a second factor, for indetifying the end user. The verification of both factors should occur within one message request/response pair of the protocol.C.1.5.C.1.6. MatrixCardValidation - Server generated challenge An application needs to be able to use MatrixCard challenge/response algorithm for identifying the end user. The application will request from the validation server the challenge to be presented to the user via the user interface and the user response entered into a webform The application will then use the protocol to verify the response from the token C.2.SynchornisationSynchronisation Use Cases This section describes the use cases relating to synchronisation of the token and the server. C.2.1. OTP TokenAuto-Resync (NextOTP)Resync with the Next OTPs An application needs to validate anOTP. TheOTP but the OTP could not be validated because the OTP moving factor is out-of-sync between the token and the server. The validation server detects that the given OTP corresponds to a future moving factor that falls in an acceptable re-sync window. The application decides that a re-sync is necessary. Itusesasks the next generated OTP from the tokeninto re-sync theprotocoltoken. The validation server adjusts its record of the token's moving factor tore- syncthetokenone that corresponds to the given OTP upon successful validation. Two consecutive OTPs could also be directly used for a validation server to re-sync a token, where the server tries to match the first OTP with an extended synchronization window and then match the second OTP with a normal authentication window. C.2.2. OTP TokenManual-resyncResync with Moving Factor An application needs to validate anOTP. TheOTP but the OTP could not be validated because the OTP moving factor is out-of-sync between the token and the server. The validation server detects that the given OTP corresponds to a future moving factor that falls in an acceptable re-sync window. The application decides that a re-sync is necessary. It uses values that can be read by the user of the token (e.g. event counter value, time interval counter value) to re-sync the token together with the next generated OTP of thetoken..token. Appendix D. Requirements This section outlines the most relevant requirements that are the basis of this work. Several of the requirements were derived from use cases described above. R1: The protocol must support authentication of request originator. R2: The protocol must support management data flows (e.g., related to token synchronization) R3: The protocol needs to support the following algorithms * HOTP * OCRA * TOTP * Proprietary OTP * Proprietary Challenge/Response * Matrix cards * SMS OTP * PKI based challenge/response R4: The protocol must be XML/Web Services based. R5: The protocol must support SOAP intermediaries. Authors' Addresses Philip Hoyer ActivIdentity, Inc. 117 Waterloo Road London, SE1 8UL UK Phone: +44 (0) 20 7744 6455 Email: phoyer@actividentity.com Tim Moses Entrust, Inc. 1000 Innovation Drive Ottawa, Ontario K2K 3E7 Canada Phone: +1 (613) 270-3400 Email: tim.mosesi@entrust.com Mingliang Pei VeriSign, Inc. 487 E. Middlefield Road Mountain View, CA 94043 USA Phone: +1 650 426 5173 Email: mpei@verisign.com Salah Machani Diversinet, Inc. 2225 Sheppard Avenue East Suite 1801 Toronto, Ontario M2J 5C2 Canada Phone: +1 416 756 2324 Ext. 321 Email: smachani@diversinet.com