VALID
draft-hoyer-valid-00

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 on January 7, 2010.

Copyright Notice

Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). 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 components from different vendors into the same infrastructure.

Table of Contents

1.  Introduction
    1.1.  Key Words
    1.2.  Notation
    1.3.  Namespaces
    1.4.  Terminology
2.  Authentication-Data Validation Service Interface overview
    2.1.  Authentication data communication
    2.2.  Verified attributes
    2.3.  Challenge/response
    2.4.  Token collections
3.  Communication patterns
    3.1.  In-band authentication
    3.2.  Out-of-band challenge
    3.3.  Out-of-band response
    3.4.  Client supplies challenge
    3.5.  End-user obtains assertions Out-of-band from server
4.  Asynchronous communication
    4.1.  Out-of-band challenge
    4.2.  Out-of-band response
5.  Authentication moving factor resync
    5.1.  Automatic re-sync based on authentication data
    5.2.  Manual re-sync based on presenting moving factor values
6.  Policy models
7.  Common message contents
    7.1.  Request Security Token
    7.2.  Request Security Token Response
8.  Mechanism-specific message contents
9.  Extensibility
10.  IANA Considerations
    10.1.  XML namespace registration
    10.2.  VALID Version Registry
11.  Security Considerations
12.  Acknowledgements
13.  References
    13.1.  Normative References
    13.2.  Informative References
Appendix A.  WSDL
Appendix B.  Mechanism specific message contents
    B.1.  Username/password
    B.2.  In band one-time-password (OTP)
    B.3.  In band challenge/response
    B.4.  Out-of-band challenge
    B.5.  Out-of-band response
    B.6.  Client supplies challenge
    B.7.  Challenge/response with signature
Appendix C.  Use Cases
    C.1.  Validation
        C.1.1.  OTP Validation
        C.1.2.  Challenge/Response Validation – Server generated challenge
        C.1.3.  Challenge/Response Validation – User generated challenge
        C.1.4.  OTP Validation + Server managed PIN
        C.1.5.  MatrixCardValidation – Server generated challenge
    C.2.  Synchornisation Use Cases
        C.2.1.  OTP Token Auto-Resync (NextOTP)
        C.2.2.  OTP Token Manual-resync
Appendix D.  Requirements
§  Authors' Addresses

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] (Cantor, S., Kemp, J., Philpott, R., and E. Maler, “WS-Trust 1.4,” March 2005.), [WS‑Security] (Nadalin, A., Kaler, C., Monzillo, R., and P. Hallam-Baker, “Web Services Security: SOAP Message Security 1.1,” Feb 2006.) and [WS‑Trust] (Nadalin, A., Goodner, M., Gudgin, M., Barbir, A., and H. Granqvist, “WS-Trust 1.4,” Feb 2009.) and operates over version 1.2 of [SOAP] (Gudgin, M., “Simple Object Access Protocol 1.2,” April 2007.). 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] (, “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

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 Section 9 (Extensibility)) 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
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] (MRaihi, D., Bellare, M., Hoornaert, F., Naccache, D., and O. Ranen, “HOTP: An HMAC-Based One Time Password Algorithm,” December 2005.).

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 (Communication patterns). The interface is based mainly on [WS‑Trust] (Nadalin, A., Goodner, M., Gudgin, M., Barbir, A., and H. Granqvist, “WS-Trust 1.4,” Feb 2009.). The following sections apply terminologies and concepts defined in [WS‑Trust] (Nadalin, A., Goodner, M., Gudgin, M., Barbir, A., and H. Granqvist, “WS-Trust 1.4,” Feb 2009.).

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] (Nadalin, A., Goodner, M., Gudgin, M., Barbir, A., and H. Granqvist, “WS-Trust 1.4,” Feb 2009.) 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   |
                                      |____________|

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.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   |
                                      |____________|

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   |
                                      |____________|

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   |
                                     |____________|

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   |
                                      |____________|

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 (Out-of-band challenge) and Section 3.3 (Out-of-band response)) 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 (Out-of-band challenge)), 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 (Out-of-band response)), 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.  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] (MRaihi, D., Bellare, M., Hoornaert, F., Naccache, D., and O. Ranen, “HOTP: An HMAC-Based One Time Password Algorithm,” December 2005.)). 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.  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.  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] (MRaihi, D., Bellare, M., Hoornaert, F., Naccache, D., and O. Ranen, “HOTP: An HMAC-Based One Time Password Algorithm,” December 2005.)) 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.  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   |
|____________| |____________| |____________|

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   |
|____________| |____________| |____________|

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.  Common message contents

This section describes the mechanism-independent requirements for message contents.

7.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. The server MUST use the value as the <wst:RequestSecurityToken/@Context> value in the response.

7.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 NOT include any other elements.

<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.  Mechanism-specific message contents

The mechanism-specific requirements for message contents are described in the appendices. These MAY be used in any combination.

9.  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 Section 10 (IANA Considerations).

10.  IANA Considerations

10.1.  XML namespace registration

This section registers a new XML namespace, "urn:ietf:params:xml:ns:valid", per the guidelines in [RFC3688] (Mealling, M., “The IETF XML Registry,” January 2004.).

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>
END

10.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.  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] (Eastlake, D., “XML-Signature Syntax and Processing,” February 2002.) 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] (Eastlake, D., “XML-Signature Syntax and Processing,” February 2002.) 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.  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] (, “Initiative for Open AuTHentication,” .), to specify a format that can be freely distributed to the technical community.

13.  References

13.1. Normative References

13.2. Informative References

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: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"/>
   <xsd:element name="RequestSecurityTokenResponse"
   ref="wst:RequestSecurityTokenResponseType"/>
   <xsd:element name="OTP" type="xsd:string"/>
   <xsd:element name="KeyId" type="xsd:string"/>
  </xsd:schema>
 </types>
 <message name="RequestSecurityToken">
  <part name="request" type="valid:RequestSecurityTokenType"/>
 </message>
 <message name="RequestSecurityTokenResponse">
  <part name="response" type="valid:RequestSecurityTokenResponseType"/>
 </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>
 <binding name="RequestSecurityTokenBinding">
  <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] (Nadalin, A., Kaler, C., Monzillo, R., and P. Hallam-Baker, “Web Services Security UsernameToken Profile 1.1,” Feb 2006.).

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> ?
        <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 OTP token identifier. The server MUST load the corresponding token 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 the OTP token

B.3.  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> ?
    </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.  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.  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> ?
    </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.  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.  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] (MRaihi, D., Rydell, J., Naccache, D., Machani, S., and S. Bhajaj, “OCRA: OATH Challenge-Response Algorithms,” January 2008.). 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> ?
    </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:

• Username, PIN + OTP
• Username, OTP
• TokenId + OTP
• 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.  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.  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.  Synchornisation Use Cases

This section describes the use cases relating to synchronisation of the token and the server.

C.2.1.  OTP Token Auto-Resync (NextOTP)

An application needs to validate an OTP. The OTP could not be validated and the application decides that a re-sync is necessary. It uses the next generated OTP from the token in the protocol to re-sync the token

C.2.2.  OTP Token Manual-resync

An application needs to validate an OTP. The OTP could not be validated and 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 the 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

R4:

The protocol must be XML/Web Services based.

R5:

The protocol must support SOAP intermediaries.

Authors' Addresses