Network Working Group P. Hoyer
Internet-Draft ActivIdentity
Intended status: Standards Track T. Moses
Expires: January 7, 2010 Entrust
M. Pei
VeriSign
S. Machani
Diversinet
July 6, 2009
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.
Hoyer, et al. Expires January 7, 2010 [Page 1]
Internet-Draft VALID July 2009
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 . . . . . . . . . . . . . . . . . . . . . . . . . 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.2. Out-of-band challenge . . . . . . . . . . . . . . . . . . 10
3.3. Out-of-band response . . . . . . . . . . . . . . . . . . . 11
3.4. Client supplies challenge . . . . . . . . . . . . . . . . 12
3.5. End-user obtains assertions Out-of-band from server . . . 12
4. Asynchronous communication . . . . . . . . . . . . . . . . . . 14
4.1. Out-of-band challenge . . . . . . . . . . . . . . . . . . 14
4.2. Out-of-band response . . . . . . . . . . . . . . . . . . . 14
5. Authentication moving factor resync . . . . . . . . . . . . . 15
5.1. Automatic re-sync based on authentication data . . . . . . 15
5.2. Manual re-sync based on presenting moving factor values . 15
6. Policy models . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Common message contents . . . . . . . . . . . . . . . . . . . 18
7.1. Request Security Token . . . . . . . . . . . . . . . . . . 18
7.2. Request Security Token Response . . . . . . . . . . . . . 19
8. Mechanism-specific message contents . . . . . . . . . . . . . 21
9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 22
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
10.1. XML namespace registration . . . . . . . . . . . . . . . . 23
10.2. VALID Version Registry . . . . . . . . . . . . . . . . . . 23
11. Security Considerations . . . . . . . . . . . . . . . . . . . 24
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
13.1. Normative References . . . . . . . . . . . . . . . . . . . 26
13.2. Informative References . . . . . . . . . . . . . . . . . . 27
Appendix A. WSDL . . . . . . . . . . . . . . . . . . . . . . . . 28
Hoyer, et al. Expires January 7, 2010 [Page 2]
Internet-Draft VALID July 2009
Appendix B. Mechanism specific message contents . . . . . . . . . 30
B.1. Username/password . . . . . . . . . . . . . . . . . . . . 30
B.2. In band one-time-password (OTP) . . . . . . . . . . . . . 31
B.3. In band challenge/response . . . . . . . . . . . . . . . . 32
B.4. Out-of-band challenge . . . . . . . . . . . . . . . . . . 34
B.5. Out-of-band response . . . . . . . . . . . . . . . . . . . 35
B.6. Client supplies challenge . . . . . . . . . . . . . . . . 37
B.7. Challenge/response with signature . . . . . . . . . . . . 38
Appendix C. Use Cases . . . . . . . . . . . . . . . . . . . . . . 40
C.1. Validation . . . . . . . . . . . . . . . . . . . . . . . . 40
C.1.1. OTP Validation . . . . . . . . . . . . . . . . . . . . 40
C.1.2. Challenge/Response Validation - Server generated
challenge . . . . . . . . . . . . . . . . . . . . . . 40
C.1.3. Challenge/Response Validation - User generated
challenge . . . . . . . . . . . . . . . . . . . . . . 41
C.1.4. OTP Validation + Server managed PIN . . . . . . . . . 41
C.1.5. MatrixCardValidation - Server generated challenge . . 41
C.2. Synchornisation Use Cases . . . . . . . . . . . . . . . . 41
C.2.1. OTP Token Auto-Resync (NextOTP) . . . . . . . . . . . 41
C.2.2. OTP Token Manual-resync . . . . . . . . . . . . . . . 41
Appendix D. Requirements . . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43
Hoyer, et al. Expires January 7, 2010 [Page 3]
Internet-Draft VALID July 2009
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 Section 9) but MUST NOT contradict
the semantics of the parent and/or owner, respectively. By
default, if a receiver does not recognize an extension, the
Hoyer, et al. Expires January 7, 2010 [Page 4]
Internet-Draft VALID July 2009
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.
Hoyer, et al. Expires January 7, 2010 [Page 5]
Internet-Draft VALID July 2009
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.
Hoyer, et al. Expires January 7, 2010 [Page 6]
Internet-Draft VALID July 2009
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.
Hoyer, et al. Expires January 7, 2010 [Page 7]
Internet-Draft VALID July 2009
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.
Hoyer, et al. Expires January 7, 2010 [Page 8]
Internet-Draft VALID July 2009
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.
Hoyer, et al. Expires January 7, 2010 [Page 9]
Internet-Draft VALID July 2009
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).
Hoyer, et al. Expires January 7, 2010 [Page 10]
Internet-Draft VALID July 2009
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).
Hoyer, et al. Expires January 7, 2010 [Page 11]
Internet-Draft VALID July 2009
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 |
|____________|
Hoyer, et al. Expires January 7, 2010 [Page 12]
Internet-Draft VALID July 2009
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).
Hoyer, et al. Expires January 7, 2010 [Page 13]
Internet-Draft VALID July 2009
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.
Hoyer, et al. Expires January 7, 2010 [Page 14]
Internet-Draft VALID July 2009
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]). 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])
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).
Hoyer, et al. Expires January 7, 2010 [Page 15]
Internet-Draft VALID July 2009
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 |
|____________| |____________| |____________|
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.
Hoyer, et al. Expires January 7, 2010 [Page 16]
Internet-Draft VALID July 2009
_____________
| |
| 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.
Hoyer, et al. Expires January 7, 2010 [Page 17]
Internet-Draft VALID July 2009
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.
Hoyer, et al. Expires January 7, 2010 [Page 18]
Internet-Draft VALID July 2009
<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.
Hoyer, et al. Expires January 7, 2010 [Page 19]
Internet-Draft VALID July 2009
<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.
Hoyer, et al. Expires January 7, 2010 [Page 20]
Internet-Draft VALID July 2009
8. Mechanism-specific message contents
The mechanism-specific requirements for message contents are
described in the appendices. These MAY be used in any combination.
Hoyer, et al. Expires January 7, 2010 [Page 21]
Internet-Draft VALID July 2009
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.
Hoyer, et al. Expires January 7, 2010 [Page 22]
Internet-Draft VALID July 2009
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].
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.
Hoyer, et al. Expires January 7, 2010 [Page 23]
Internet-Draft VALID July 2009
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] 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.
Hoyer, et al. Expires January 7, 2010 [Page 24]
Internet-Draft VALID July 2009
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], to specify a format that can be
freely distributed to the technical community.
Hoyer, et al. Expires January 7, 2010 [Page 25]
Internet-Draft VALID July 2009
13. References
13.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.
Hoyer, et al. Expires January 7, 2010 [Page 26]
Internet-Draft VALID July 2009
[XMLENC] Eastlake, D., "XML Encryption Syntax and Processing.",
URL: http://www.w3.org/TR/xmlenc-core/,
W3C Recommendation, December 2002.
13.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.
[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.
Hoyer, et al. Expires January 7, 2010 [Page 27]
Internet-Draft VALID July 2009
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"/>
Hoyer, et al. Expires January 7, 2010 [Page 28]
Internet-Draft VALID July 2009
</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>
Hoyer, et al. Expires January 7, 2010 [Page 29]
Internet-Draft VALID July 2009
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.
Hoyer, et al. Expires January 7, 2010 [Page 30]
Internet-Draft VALID July 2009
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.
Hoyer, et al. Expires January 7, 2010 [Page 31]
Internet-Draft VALID July 2009
<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.
Hoyer, et al. Expires January 7, 2010 [Page 32]
Internet-Draft VALID July 2009
<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.
Hoyer, et al. Expires January 7, 2010 [Page 33]
Internet-Draft VALID July 2009
<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
Hoyer, et al. Expires January 7, 2010 [Page 34]
Internet-Draft VALID July 2009
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.
Hoyer, et al. Expires January 7, 2010 [Page 35]
Internet-Draft VALID July 2009
<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
Hoyer, et al. Expires January 7, 2010 [Page 36]
Internet-Draft VALID July 2009
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>
Hoyer, et al. Expires January 7, 2010 [Page 37]
Internet-Draft VALID July 2009
</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]. 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.
Hoyer, et al. Expires January 7, 2010 [Page 38]
Internet-Draft VALID July 2009
<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>
Hoyer, et al. Expires January 7, 2010 [Page 39]
Internet-Draft VALID July 2009
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
Hoyer, et al. Expires January 7, 2010 [Page 40]
Internet-Draft VALID July 2009
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..
Hoyer, et al. Expires January 7, 2010 [Page 41]
Internet-Draft VALID July 2009
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.
Hoyer, et al. Expires January 7, 2010 [Page 42]
Internet-Draft VALID July 2009
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
Hoyer, et al. Expires January 7, 2010 [Page 43]