One-Time Password (OTP) Pre-Authentication
draft-ietf-krb-wg-otp-preauth-21
The information below is for an old version of the document that is already published as an RFC.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 6560.
|
|
|---|---|---|---|
| Author | Gareth Richards | ||
| Last updated | 2015-10-14 (Latest revision 2011-11-23) | ||
| Replaces | draft-richards-otp-kerberos | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Proposed Standard | ||
| Formats | |||
| Reviews | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | Sam Hartman | ||
| IESG | IESG state | Became RFC 6560 (Proposed Standard) | |
| Action Holders |
(None)
|
||
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | Stephen Farrell | ||
| IESG note | |||
| Send notices to | (None) |
draft-ietf-krb-wg-otp-preauth-21
Network Working Group G. Richards
Internet-Draft RSA, The Security Division of
Intended status: Standards Track EMC
Expires: May 26, 2012 November 23, 2011
OTP Pre-authentication
draft-ietf-krb-wg-otp-preauth-21
Abstract
The Kerberos protocol provides a framework authenticating a client
using the exchange of pre-authentication data. This document
describes the use of this framework to carry out One Time Password
(OTP) authentication.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on May 26, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Richards Expires May 26, 2012 [Page 1]
Internet-Draft OTP Pre-authentication November 2011
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Richards Expires May 26, 2012 [Page 2]
Internet-Draft OTP Pre-authentication November 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Overall Design . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Conventions Used in this Document . . . . . . . . . . . . 5
2. Usage Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. OTP Mechanism Support . . . . . . . . . . . . . . . . . . 5
2.2. Pre-Authentication . . . . . . . . . . . . . . . . . . . . 5
2.3. PIN Change . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4. Re-Synchronization . . . . . . . . . . . . . . . . . . . . 7
3. Pre-Authentication Protocol Details . . . . . . . . . . . . . 7
3.1. Initial Client Request . . . . . . . . . . . . . . . . . . 7
3.2. KDC Challenge . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Client Response . . . . . . . . . . . . . . . . . . . . . 10
3.4. Verifying the pre-auth Data . . . . . . . . . . . . . . . 14
3.5. Confirming the Reply Key Change . . . . . . . . . . . . . 15
3.6. Reply Key Generation . . . . . . . . . . . . . . . . . . . 16
4. OTP Kerberos Message Types . . . . . . . . . . . . . . . . . . 18
4.1. PA-OTP-CHALLENGE . . . . . . . . . . . . . . . . . . . . . 18
4.2. PA-OTP-REQUEST . . . . . . . . . . . . . . . . . . . . . . 23
4.3. PA-OTP-PIN-CHANGE . . . . . . . . . . . . . . . . . . . . 26
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
6. Security Considerations . . . . . . . . . . . . . . . . . . . 28
6.1. Man-in-the-Middle . . . . . . . . . . . . . . . . . . . . 28
6.2. Reflection . . . . . . . . . . . . . . . . . . . . . . . . 29
6.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 29
6.4. Replay . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.5. Brute Force Attack . . . . . . . . . . . . . . . . . . . . 30
6.6. FAST Facilities . . . . . . . . . . . . . . . . . . . . . 31
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
8.1. Normative References . . . . . . . . . . . . . . . . . . . 32
8.2. Informative References . . . . . . . . . . . . . . . . . . 33
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 33
Appendix B. Examples of OTP Pre-Authentication Exchanges . . . . 36
B.1. Four Pass Authentication . . . . . . . . . . . . . . . . . 36
B.2. Two Pass Authentication . . . . . . . . . . . . . . . . . 38
B.3. PIN Change . . . . . . . . . . . . . . . . . . . . . . . . 40
B.4. Resynchronization . . . . . . . . . . . . . . . . . . . . 41
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 43
Richards Expires May 26, 2012 [Page 3]
Internet-Draft OTP Pre-authentication November 2011
1. Introduction
1.1. Scope
This document describes a Flexible Authentication Secure Tunneling
(FAST) [RFC6113] factor that allows One-Time Password (OTP) values to
be used in the Kerberos V5 [RFC4120] pre-authentication in a manner
that does not require use of the user's Kerberos password. The
system is designed to work with different types of OTP algorithms
such as time-based OTPs [RFC2808], counter-based tokens [RFC4226] and
challenge-response systems such as [RFC2289]. It is also designed to
work with tokens that are electronically connected to the user's
computer via means such as a USB interface.
This FAST factor provides the following facilities (as defined in
[RFC6113]): client-authentication, replacing-reply-key and KDC-
authentication. It does not provide the strengthening-reply-key
facility.
This proposal is partially based upon previous work on integrating
single-use authentication mechanisms into Kerberos [HoReNeZo04].
1.2. Overall Design
This proposal supports 4-pass and 2-pass variants. In the 4-pass
system, the client sends the KDC an initial AS-REQ and the KDC
responds with a KRB-ERROR containing padata that includes a random
nonce. The client then encrypts the nonce and returns it to the KDC
in a second AS-REQ. Finally, the KDC returns the AS-REP. In the
2-pass variant, the client encrypts a timestamp rather than a nonce
from the KDC and the encrypted data is sent to the KDC in the initial
AS-REQ. The two-pass system can be used in cases where the client
can determine in advance that OTP pre-authentication is supported by
the KDC, which OTP key should be used and the encryption parameters
required by the KDC.
In both systems, in order to create the message sent to the KDC, the
client must generate the OTP value and two keys: the classic Reply
Key used to decrypt the KDC's reply and a key to encrypt the data
sent to the KDC. In most cases, the OTP value will be used in the
key generation but in order to support algorithms where the KDC
cannot obtain the value (e.g. [RFC2289]), the system also supports
the option of including the OTP value in the request along with the
encrypted nonce. In addition, in order to support situations where
the KDC is unable to obtain the plaintext OTP value, the system also
supports the use of hashed OTP values in the key derivation.
The preauth data sent from the client to the KDC is sent within the
Richards Expires May 26, 2012 [Page 4]
Internet-Draft OTP Pre-authentication November 2011
encrypted data provided by the FAST padata type of the AS-REQ. The
KDC then obtains the OTP value, generates the same keys and verifies
the pre-authentication data by decrypting the nonce. If the
verification succeeds then it confirms knowledge of the Reply Key by
using it to encrypt data in the AS-REP.
1.3. Conventions Used in this Document
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].
This document assumes familiarity with the Kerberos pre-
authentication framework [RFC6113] and so freely uses terminology and
notation from this document.
The word padata is used as shorthand for pre-authentication data.
2. Usage Overview
2.1. OTP Mechanism Support
As described above, this document describes a generic system for
supporting different OTP mechanisms in Kerberos pre-authentication.
To ensure interoperability, all implementations of this specification
SHOULD provide a mechanism (e.g. a provider interface) to add or
remove support for a particular OTP mechanism.
2.2. Pre-Authentication
The approach uses pre-authentication data in AS-REQ, AS-REP and KRB-
ERROR messages.
In the 4-pass system, the client begins by sending an initial AS-REQ
to the KDC that may contain pre-authentication data such as the
standard Kerberos password data. The KDC will then determine, in an
implementation dependent fashion, whether OTP authentication is
required and if it is, it will respond with a KRB-ERROR message
containing a PA-OTP-CHALLENGE (see Section 4.1) in the PA-DATA.
The PA-OTP-CHALLENGE will contain a KDC generated nonce, a list of
hash algorithm identifiers and an iteration count if hashed OTP
values are used (see Section 3.6) and OPTIONAL information on how the
OTP should be generated by the client. The client will then generate
the OTP value and two keys: a Client Key to encrypt the KDC's nonce
and a Reply Key used to decrypt the KDC's reply.
Richards Expires May 26, 2012 [Page 5]
Internet-Draft OTP Pre-authentication November 2011
As described in section 5.4.1 of [RFC6113], the FAST system uses an
Armor Key to set up an encrypted tunnel for use by FAST factors. As
described in Section 3.6 of this document, the Client Key and Reply
Key will be generated from the Armor Key and the OTP value unless the
OTP algorithm does not allow the KDC to obtain the OTP value. If
hash algorithm identifiers were included in the PA-OTP-CHALLENGE then
the client will use the hash of the OTP value rather than the
plaintext value in the key generation. Both keys will have the same
encryption type as the Armor Key.
The generated Client Key will be used to encrypt the nonce received
from the KDC. The encrypted value along with optional information on
how the OTP was generated are then sent to the KDC in a PA-OTP-
REQUEST (see Section 4.2) encrypted within the armored-data of a PA-
FX-FAST-REQUEST PA-DATA element of a second AS-REQ.
In the 2-pass system, the client sends the PA-OTP-REQUEST in the
initial AS-REQ instead of sending it in response to a PA-OTP-
CHALLENGE returned by the KDC. Since no challenge is received from
the KDC, the client includes an encrypted timestamp in the request
rather than the encrypted KDC nonce.
In both cases, on receipt of a PA-OTP-REQUEST, the KDC generates the
keys in the same way as the client, and uses the generated Client Key
to verify the pre-authentication by decrypting the encrypted data
sent by the client (either nonce or timestamp). If the validation
succeeds then the KDC will authenticate itself to the client and
confirm that the Reply Key has been updated by using the generated
Reply Key in the AS-REP response.
2.3. PIN Change
Most OTP tokens involve the use of a PIN in the generation of the OTP
value. This PIN value will be combined with the value generated by
the token to produce the final OTP value that will be used in this
protocol.
If, following successful validation of a PA-OTP-REQUEST in an AS-REQ,
the KDC determines that the user's PIN has expired and needs to
change then it SHOULD respond KRB-ERROR of type KDC_ERR_PIN_EXPIRED.
It MAY include formatting information on the PIN in a PA-OTP-PIN-
CHANGE (see Section 4.3) encrypted within the armored data of the PA-
FX-FAST-REPLY PA-DATA element.
KDC_ERR_PIN_EXPIRED 96
If the PIN change is to be handled by a PIN-change service then it is
assumed that authentication to that service will succeed if the PIN
Richards Expires May 26, 2012 [Page 6]
Internet-Draft OTP Pre-authentication November 2011
has expired.
If the user's PIN has not expired but has been changed then the KDC
MAY return the new value to the client in a PA-OTP-PIN-CHANGE
encrypted within the armored data of the PA-FX-FAST-REPLY PA-DATA
element of the AS-REP. Similarly, if PIN change is not required then
the KDC MAY return a PA-OTP-PIN-CHANGE to inform the client of the
current PIN's expiration time.
2.4. Re-Synchronization
It is possible with time and event-based tokens that the OTP server
will lose synchronization with the current token state. For example,
event-based tokens may drift since the counter on the token is
incremented every time the token is used but the counter on the
server is only incremented on an authentication. Similarly, the
clocks on time-based tokens may drift.
Methods to recover from this type of situation are OTP algorithm
specific but may involve the client sending a sequence of OTP values
to allow the server to further validate the correct position in its
search window (see section 7.4 of [RFC4226] for an example).
If, when processing a PA-OTP-REQUEST, the pre-authentication
validation fails for this reason then the KDC MAY return a KRB-ERROR
message. The KRB-ERROR message MAY contain a PA-OTP-CHALLENGE in the
PA-DATA with a single otp-tokenInfo representing the token used in
the initial authentication attempt but with "nextOTP" flag set. If
this flag is set then the client SHOULD re-try the authentication
using an OTP value generated using the token in the "state" after
that used in the failed authentication attempt. For example, using
the next time interval or counter value.
3. Pre-Authentication Protocol Details
3.1. Initial Client Request
In the 4-pass mode, the client begins by sending an initial AS-REQ,
possibly containing other pre-authentication data. If the KDC
determines that OTP-based pre-authentication is required and the
request does not contain a PA-OTP-REQUEST then it will respond as
described in Section 3.2.
If the client has all the necessary information, it MAY use the
2-pass system by constructing a PA-OTP-REQUEST as described in
Section 3.3 and including it in the initial request.
Richards Expires May 26, 2012 [Page 7]
Internet-Draft OTP Pre-authentication November 2011
3.2. KDC Challenge
If the user is required to authenticate using an OTP then the KDC
SHALL respond to the initial AS-REQ with a KRB-ERROR, as described in
section 2.2 of [RFC6113], with a PA-OTP-CHALLENGE contained within
the enc-fast-rep of the armored-data of a PA-FX-FAST-REPLY encrypted
under the current Armor Key as described in [RFC6113].
If the OTP mechanism is to be carried out as an individual mechanism
then the PA-OTP-CHALLENGE SHALL be carried within the padata of the
KrbFastResponse. Alternatively, if the OTP mechanism is required as
part of an authentication set then the PA-OTP-CHALLENGE SHALL be
carried within a PA-AUTHENTICATION-SET-ELEM as described in section
5.3 of [RFC6113].
The PA-OTP-CHALLENGE SHALL contain a nonce value to be returned
encrypted in the client's PA-OTP-REQUEST. This nonce string MUST
contain a randomly chosen component at least as long as the armor key
length. (See [RFC4086] for an in-depth discussion of > randomness.)
In order to allow it to maintain any state necessary to verify the
returned nonce, the KDC SHOULD use the mechanism described in section
5.2 of [RFC6113].
The KDC MAY use the otp-service field to assist the client in
locating the OTP token to be used by identifying the purpose of the
authentication. For example, the otp-service field could assist a
user in identifying the token to be used when a user has multiple OTP
tokens that are used for different purposes. If the token is a
connected device, then these values SHOULD be an exact octet-level
match for the values present on the target token.
The KDC SHALL include a sequence of one or more otp-tokenInfo
elements containing information on the token or tokens that the user
can use for the authentication and how the OTP value is to be
generated using those tokens. If a single otp-tokenInfo element is
included then only a single token is acceptable by the KDC and any
OTP value generated by the client MUST be generated according to the
information contained within that element. If more than one otp-
tokenInfo element is included then the OTP value MUST be generated
according to the information contained within one of those elements.
The KDC MAY include the otp-vendor field in an otp-tokenInfo to
identify the vendor of the token that can be used in the
authentication request in order to assist the client in locating that
token.
If the KDC is able to obtain the OTP values for the token then the
OTP value SHOULD be used in the key generation as described in
Richards Expires May 26, 2012 [Page 8]
Internet-Draft OTP Pre-authentication November 2011
Section 3.6 and so the KDC SHOULD set the "must-encrypt-nonce" flag
in the otp-tokenInfo. If the KDC is unable to obtain the OTP values
for the token then the "must-encrypt-nonce" flag MUST NOT be set. If
the flag is not set then the OTP value will be returned by the client
in the otp-value field of the PA-OTP-REQUEST and so if returning of
OTP values in this way does not conform to KDC policy then the KDC
SHOULD NOT include the otp-tokenInfo for that token in the PA-OTP-
CHALLENGE.
If the KDC requires that hashed OTPs be used in the key generation as
described in Section 3.6 (for example, it is only able to obtain
hashed OTP values for the token) then it MUST include the supported
hash algorithms in order of preference in the supportedHashAlg of the
otp-KeyInfo and the minimum value of the iteration count in the
iterationCount element.
Since the OTP mechanism described in this document is replacing the
Reply Key, the classic shared-key system cannot be relied upon to
allow the client to verify the KDC. Therefore, as described in
section 3.4 of [RFC6113], some other mechanism must be provided to
support this. If the OTP value is used in the Reply Key generation
then the client and KDC have a shared key and KDC-authentication is
provided by the KDC using the Reply Key generated from the OTP value.
However, if the OTP value is sent in the otp-value element of the PA-
OTP-REQUEST then there is no such shared key and the OTP mechanism
does not provide KDC-authentication. Therefore, if the OTP mechanism
is not being used in an environment where KDC-authentication is being
provided by other means (e.g. by the use of host key armor) then the
KDC MUST NOT include any otp-tokenInfo elements in the PA-OTP-
CHALLENGE that do not have the "must-encrypt-nonce" flag set.
If the OTP for a token is to be generated using a server generated
challenge then the value of the challenge SHALL be included in the
otp-challenge field of the otp-tokenInfo for that token. If the
token is a connected device and the OTP is to be generated by
combining the challenge with the token's current state (e.g. time)
then the "combine" flag SHALL be set within the otp-tokenInfo
containing the challenge.
If the KDC can determine which OTP token key (the seed value on the
token used to generate the OTP) is to be used, then the otp-tokenID
field MAY be included in the otp-tokenInfo to pass that value to the
client.
The otp-algID field MAY be included in an otp-tokenInfo to identify
the algorithm that should be used in the OTP calculation for that
token. For example, it could be used when a user has been issued
with multiple tokens that support different algorithms.
Richards Expires May 26, 2012 [Page 9]
Internet-Draft OTP Pre-authentication November 2011
If the KDC can determine that an OTP token that can be used by the
user does not require the client to collect a PIN then it SHOULD set
the "do-not-collect-pin" flag in the otp-tokenInfo representing that
token. If the KDC can determine that the token requires the client
to collect a PIN then it SHOULD set the "collect-pin" flag. If the
KDC is unable to determine whether the client should collect a PIN or
not then the "collect-pin" and "do-not-collect-pin" flags MUST NOT be
set.
If the KDC requires the PIN of an OTP token to be returned to it
separately then it SHOULD set the "separate-pin-required" flag in the
otp-KeyInfo representing that token.
If the KDC requires that the OTPs generated by the token have a Luhn
check digit appended, as defined in [ISOIEC7812], then it MUST set
the "check-digit" flag. This flag only applies if the format of the
OTP is decimal and so the otp-format field, if present, MUST have the
value of "decimal".
Finally, in order to support connected tokens that can generate OTP
values of varying lengths or formats, the KDC MAY include the desired
length and format of the OTP in the otp-length and otp-format fields
of an otp-tokenInfo.
3.3. Client Response
The client response SHALL be sent to the KDC as a PA-OTP-REQUEST
included within the enc-fast-req of the armored-data within a PA-FX-
FAST-REQUEST encrypted under the current Armor Key as described in
[RFC6113].
In order to generate its response, the client MUST generate an OTP
value. If the PA-OTP-CHALLENGE contained one or more otp-tokenInfo
elements then the OTP value MUST be based on the information
contained within one of those elements.
The otp-service, otp-vendor, otp-tokenID, otp-length, otp-format and
otp-algID elements of the PA-OTP-CHALLENGE are provided by the KDC to
assist the client in locating the correct token to use but the use of
the above fields will depend on the type of token.
If the token is a disconnected device, then the values of otp-service
and otp-vendor MAY be displayed to the user in order to help the user
select the correct token and the values of otp-algID, otp-tokenID,
otp-length and otp-format MAY be ignored.
If the token is a connected device, then these values, if present,
SHOULD be used by the client to locate the correct token. When the
Richards Expires May 26, 2012 [Page 10]
Internet-Draft OTP Pre-authentication November 2011
token is connected, clients MUST support matching based on a binary
comparison of the otp-vendor and otp-service strings when comparing
the values against those present on the token. Clients MAY have
other comparisons including normalization insensitive comparisons to
try and find the right token. The values of otp-vendor and otp-
service MAY be displayed to prompt the user if the correct token is
not found.
If the "nextOTP" flag is set in the otp-tokenInfo from the PA-OTP-
CHALLENGE, then the OTP value MUST be generated from the next token
state than that used in the previous PA-OTP-REQUEST for that token.
The "nextOTP" flag MUST also be set in the new PA-OTP-REQUEST.
If the "collect-pin" flag is set then the token requires a PIN to be
collected by the client. If the "do-not-collect-pin" flag is set in
the otp-tokenInfo from the PA-OTP-CHALLENGE, then the token
represented by the otp-tokenInfo does not require a PIN to be
collected by the client as part of the OTP value. If neither of the
"collect-pin" nor "do-not-collect-pin" flags are set then PIN
requirements of the token are unspecified. If both flags are set
then client SHALL regard the request as invalid.
If the "separate-pin-required" flag is set then any PIN collected by
the client MUST be included as a UTF-8 string in the otp-pin of the
PA-OTP-REQUEST.
If the token is a connected device, then how the PIN is used to
generate the OTP value will depend on the type of device. However,
if the token is a disconnected device, then it will depend on the
"separate-pin-required" flag. If the flag is not set then the OTP
value MUST be generated by appending the PIN with the value from the
token entered by the user and, if the flag is set, then the OTP value
MUST be the value from the token.
The clients SHOULD NOT normalize the PIN value or any OTP value
collected from the user or returned by a connected token in any way.
If the "check-digit" flag is set then any OTP values SHOULD be
decimal and have a Luhn check digit appended [ISOIEC7812]. If the
token is disconnected then the Client MAY ignore this flag but if the
token is connected then the Client MUST enforce it. The Client MUST
regard the request as invalid if otp-format is present and set to any
value other than "decimal".
If an otp-challenge is present in the otp-tokenInfo selected by the
client from the PA-OTP-CHALLENGE then the OTP value for the token
MUST be generated based on a challenge if the token is capable of
accepting a challenge. The client MAY ignore the provided challenge
Richards Expires May 26, 2012 [Page 11]
Internet-Draft OTP Pre-authentication November 2011
if and only if the token is not capable of including a challenge in
the OTP calculation.
If the "combine" flag is not set in the otp-tokenInfo of the PA-OTP-
CHALLENGE then the OTP SHALL be calculated based only the challenge
and not the internal state (e.g. time or counter) of the token. If
the "combine" flag is set then the OTP SHALL be calculated using both
the internal state and the provided challenge if that value is
obtainable by the client. If the flag is set but otp-challenge is
not present then the client SHALL regard the request as invalid.
If token is a connected device then the use of the challenge will
depend on the type of device but will involve passing the challenge
and the value of the "combine" flag in a token-specific manner to the
token, along with a PIN if collected and the values of otp-length and
otp-format if specified, in order to obtain the OTP value. If the
token is disconnected then the challenge MUST be displayed to the
user and the value of the "combine" flag MAY be ignored by the
client.
If the OTP value was generated using a challenge that was not sent by
the KDC then the challenge SHALL be included in the otp-challenge of
the PA-OTP-REQUEST. If the OTP was generated by combining a
challenge (either received from the KDC or generated by the client)
with the token state then the "combine" flag SHALL be set in the PA-
OTP-REQUEST.
If the "must-encrypt-nonce" flag is set in the otp-tokenInfo then the
OTP value MUST be used to generate the Client Key and Reply Key as
described in Section 3.6 and MUST NOT be included in the otp-value
field of the PA-OTP-REQUEST. If the flag is not set then the OTP
value MUST be included in the otp-value field of the PA-OTP-REQUEST
and MUST NOT be used in the key derivation. In this case, the Client
Key and Reply Key SHALL be the same as the Armor Key as described in
Section 3.6 and so if the returning of OTP values in this way does
not conform to local policy on the client (for example, if KDC-
Authentication is required and is not being provided by other means)
then it SHOULD NOT use the token for authentication.
If the supportedHashAlg and iterationCount elements are included in
the otp-tokenInfo then the client MUST use hashed OTP values in the
generation of the Reply Key and Client Key as described in
Section 3.6. The client MUST select the first algorithm from the
list that it supports and the AlgorithmIdentifer [RFC5280] selected
MUST be placed in the hashAlg element of the PA-OTP-REQUEST.
However, if none of the algorithm identifiers conform to local policy
restrictions then the authentication attempt MUST NOT proceed using
that token. If the value of iterationCount does not conform to local
Richards Expires May 26, 2012 [Page 12]
Internet-Draft OTP Pre-authentication November 2011
policy on the client then the client MAY use a larger value but MUST
NOT use a lower value. The value of the iteration count used by the
client MUST be returned in the PA-OTP-REQUEST sent to the KDC.
If hashed OTP values are used then the nonce generated by the client
MUST be as long as the longest key length of the symmetric key types
that the it supports and MUST be chosen randomly. (See [RFC4086].)
The nonce MUST be included in the PA-OTP-REQUEST along with the hash
algorithm and iteration count used in the nonce, hashAlg and
iterationCount fields of the PA-OTP-REQUEST. These fields MUST NOT
be included if hashed OTP values were not used. It is RECOMMENDED
that the iteration count used by the client be chosen in such a way
that it is computationally infeasible/unattractive for an attacker to
brute-force search for the given OTP.
The PA-OTP-REQUEST returned by the client SHOULD include information
on the generated OTP value reported by the OTP token when available
to the client. The otp-time and otp-counter fields of the PA-OTP-
REQUEST SHOULD be used to return the time and counter values used by
the token if available to the client. The otp-format field MAY be
used to report the format of the generated OTP. This field SHOULD be
used if a token can generate OTP values in multiple formats. The
otp-algID field SHOULD be used by the client to report the algorithm
used in the OTP calculation and the otp-tokenID SHOULD be used to
report the identifier of the OTP token key used if the information is
known to the client.
If the PA-OTP-REQUEST is being sent in response to a PA-OTP-CHALLENGE
that contained an otp-vendor field in the selected otp-tokenInfo then
the otp-vendor field of the PA-OTP-REQUEST MUST be set to the same
value. If no otp-vendor field was provided by the KDC then the field
SHOULD be set to the vendor identifier of the token if known to the
client.
The generated Client Key is used by the client to encrypt data to be
included in the encData of the PA-OTP-REQUEST to allow the KDC to
authenticate the user. The key usage for this encryption is
KEY_USAGE_OTP_REQUEST.
o If the PA-OTP-REQUEST is being generated in response to a PA-OTP-
CHALLENGE returned by the KDC then the client SHALL encrypt a PA-
OTP-ENC-REQUEST containing the value of nonce from the PA-OTP-
CHALLENGE using the same encryption type as the Armor Key.
o If the PA-OTP-REQUEST is not in response to a PA-OTP-CHALLENGE
then the client SHALL encrypt a PA-ENC-TS-ENC containing the
current time as in the encrypted timestamp pre-authentication
mechanism [RFC4120].
Richards Expires May 26, 2012 [Page 13]
Internet-Draft OTP Pre-authentication November 2011
If the client is working in 2-pass mode and so is not responding to
an initial KDC challenge then the values of the iteration count and
hash algorithms cannot be obtained from that challenge. The client
SHOULD use any values obtained from a previous PA-OTP-CHALLENGE or,
if no values are available, it MAY use initial configured values.
3.4. Verifying the pre-auth Data
The KDC validates the pre-authentication data by generating the
Client Key and Reply Key in the same way as the client and using the
generated Client Key to decrypt the value of encData from the PA-OTP-
REQUEST. The generated Reply Key is used to encrypt data in the AS-
REP.
If the otp-value field is included in the PA-OTP-REQUEST then the KDC
MUST use that value unless the OTP method is required to support KDC-
authentication (see Section 3.2). If the otp-value is not included
in the PA-OTP-REQUEST then the KDC will need to generate or obtain
the OTP value.
If the otp-pin field is present in the PA-OTP-REQUEST then the PIN
value has be value provided by the client. The KDC SHOULD SASLPrep
[RFC4013] the value in lookup mode before comparison.
It should be noted that it is anticipated that, as improved string
comparison technologies are standardized, the processing done by the
KDC will change but efforts will be made to maintain as much
compatibility with SASLprep as possible.
If the otp-challenge field is present, then the OTP was calculated
using that challenge. If the "combine" flag is also set, then the
OTP was calculated using the challenge and the token's current state.
It is RECOMMENDED that the KDC acts upon the values of otp-time, otp-
counter, otp-format, otp-algID and otp-tokenID if they are present in
the PA-OTP-REQUEST. If the KDC receives a request containing these
values but cannot act upon them then they MAY be ignored.
The KDC generates the Client Key and Reply Key as described in
Section 3.6 from the OTP value using the nonce, hash algorithm and
iteration count if present in the PA-OTP-REQUEST. The KDC MUST fail
the request with KDC_ERR_INVALID_HASH_ALG if the KDC requires hashed
OTP values and the hashAlg field was not present in the PA-OTP-
REQUEST or if the value of this field does not conform to local KDC
policy. Similarly, the KDC MUST fail the request with
KDC_ERR_INVALID_ITERATION_COUNT if the value of the iterationCount
included in the PA-OTP-REQUEST does not conform to local KDC policy
or is less than that specified in the PA-OTP-CHALLENGE. In addition,
Richards Expires May 26, 2012 [Page 14]
Internet-Draft OTP Pre-authentication November 2011
the KDC MUST fail the authentication request with
KDC_ERR_PIN_REQUIRED if it requires a separate PIN to the OTP value
and an otp-pin was not included in the PA-OTP-REQUEST
KDC_ERR_INVALID_HASH_ALG 94
KDC_ERR_INVALID_ITERATION_COUNT 95
KDC_ERR_PIN_REQUIRED 97
The generated Client Key is then used to decrypt the encData from the
PA-OTP-REQUEST. If the client response was sent as a result of a PA-
OTP-CHALLENGE then the decrypted data will be a PA-OTP-ENC-REQUEST
and the client authentication MUST fail with KDC_ERR_PREAUTH_FAILED
if the nonce value from the PA-OTP-ENC-REQUEST is not the same as the
nonce value sent in the PA-OTP-CHALLENGE. If the response was not
sent as a result of a PA-OTP-CHALLENGE then the decrypted value will
be a PA-ENC-TS-ENC and the authentication process will be the same as
with classic encrypted timestamp pre-authentication [RFC4120]
The KDC MUST fail the request with KDC_ERR_ETYPE_NOSUPP if the
encryption type used by the client in the encData does not conform to
KDC policy.
If authentication fails due to the hash algorithm, iteration count or
encryption type used by the client then the KDC SHOULD return a PA-
OTP-CHALLENGE with the required values in the error response. If the
authentication fails due to the token state on the server no longer
being synchronized with the token used then the KDC MAY return a PA-
OTP-CHALLENGE with the "nextOTP" flag set as described in
Section 2.4.
If, during the authentication process, the KDC determines that the
user's PIN has been changed then it SHOULD include a PA-OTP-PIN-
CHANGE in the response as described in Section 2.3 containing the new
PIN value. The KDC MAY also include the new PIN's expiration time
and the expiration time of the OTP account within the last-req field
of the PA-OTP-PIN-CHANGE. (These fields can be used by the KDC to
handle cases where the account related to the user's OTP token has a
different expiration time to the user's Kerberos account.) If the
KDC determines that the user's PIN or OTP account are about to
expire, it MAY return a PA-OTP-PIN-CHANGE with that information.
Finally, if the KDC determines that the user's PIN has expired then
it SHOULD return a KRB-ERROR of type KDC_ERR_PIN_EXPIRED as described
in Section 2.3
3.5. Confirming the Reply Key Change
If the pre-authentication data was successfully verified, then, in
order to support mutual authentication, the KDC SHALL respond to the
Richards Expires May 26, 2012 [Page 15]
Internet-Draft OTP Pre-authentication November 2011
client's PA-OTP-REQUEST by using the generated Reply Key to encrypt
the data in the AS-REP.
The client then uses its generated Reply Key to decrypt the encrypted
data and MUST NOT continue with the authentication process if
decryption is not successful.
3.6. Reply Key Generation
In order to authenticate the user, the client and KDC need to
generate two encryption keys:
o The Client Key to be used by the client to encrypt and by the KDC
to decrypt the encData in the PA-OTP-REQUEST.
o The Reply Key to be used in the standard manner by the KDC to
encrypt data in the AS-REP.
The method used to generate the two keys will depend on the OTP
algorithm.
o If the OTP value is included in the otp-value of the PA-OTP-
REQUEST then the two keys SHALL be the same as the Armor Key
(defined in [RFC6113]).
o If the OTP value is not included in the otp-value of the PA-OTP-
REQUEST then the two keys SHALL be derived from the Armor Key and
the OTP value as described below.
If the OTP value is not included in the PA-OTP-REQUEST, then the
Reply Key and Client Key SHALL be generated using the KRB-FX-CF2
algorithm from [RFC6113] as follows:
Client Key = KRB-FX-CF2(K1, K2, O1, O2)
Reply Key = KRB-FX-CF2(K1, K2, O3, O4)
The octet string parameters, O1, O2, O3 and O4, shall be the ASCII
string "OTPComb1", "OTPComb2", "OTPComb3" and "OTPComb4" as shown
below:
{0x4f, 0x54, 0x50, 0x43, 0x6f, 0x6d, 0x62, 0x31}
{0x4f, 0x54, 0x50, 0x43, 0x6f, 0x6d, 0x62, 0x32}
{0x4f, 0x54, 0x50, 0x43, 0x6f, 0x6d, 0x62, 0x33}
{0x4f, 0x54, 0x50, 0x43, 0x6f, 0x6d, 0x62, 0x34}
The first input key, K1, SHALL be the Armor Key and so, as described
in section 5.1 of [RFC6113], the enctypes of the generated Client Key
and Reply Key will be the same as the enctype of Armor Key. The
Richards Expires May 26, 2012 [Page 16]
Internet-Draft OTP Pre-authentication November 2011
second input key, K2, shall be derived from the OTP value using
string-to-key (defined in [RFC3961]) as follows.
If the hash of the OTP value is to be used then K2 SHALL be derived
as follows:
o An initial hash value, H, is generated:
H = hash(realm|nonce|OTP)
Where:
* "|" denotes concatenation
* hash is the hash algorithm selected by the client.
* realm is the name of the server's realm as carried in the realm
field of the AS-REQ. (Not including the tag and length from
the DER encoding.)
* nonce is the value of the random nonce value generated by the
client and carried in the nonce field of the PA-OTP-REQUEST.
(Not including the tag and length from the DER encoding.)
* If the OTP format is decimal, hexadecimal or alphanumeric, then
OTP is the value of the OTP generated as described in
Section 3.3 with SASLprep [RFC4013] applied in lookup mode,
otherwise it is the unnormalized OTP value.
o The initial hash value is then hashed iterationCount-1 times to
produce a final hash value, H'. (Where iterationCount is the
value from the PA-OTP-REQUEST.)
H' = hash(hash(...(iterationCount-1 times)...(H)))
o The value of K2 is then derived from the Base64 [RFC2045] encoding
of this final hash value.
K2 = string-to-key(Base64(H')|"Krb-preAuth")
If the hash value is not used, then K2 SHALL be derived from the
base64 encoding of the OTP value.
K2 = string-to-key(Base64(OTP)|"Krb-preAuth")
The enctype used for string-to-key SHALL be that of the Armor Key and
the salt and any additional parameters for string-to-key MAY be
provided by the KDC in the PA-OTP-CHALLENGE. If the salt and string-
to-key parameters are not provided then the default values defined
for the particular enctype SHALL be used.
If the strengthen-key is present in KrbFastResponse, then it is
combined with the Reply Key to generate the final AS-REQ as described
Richards Expires May 26, 2012 [Page 17]
Internet-Draft OTP Pre-authentication November 2011
in [RFC6113]. The strengthen-key does not influence the Client Key.
4. OTP Kerberos Message Types
4.1. PA-OTP-CHALLENGE
The padata-type PA-OTP-CHALLENGE is returned by the KDC to the client
in the enc-fast-rep of a PA-FX-FAST-REPLY in the PA-DATA of a KRB-
ERROR when OTP pre-authentication is required. The corresponding
padata-value field contains the Distinguished Encoding Rules (DER)
[X.680] [X.690] encoding of a PA-OTP-CHALLENGE containing a server
generated nonce and information for the client on how to generate the
OTP.
Richards Expires May 26, 2012 [Page 18]
Internet-Draft OTP Pre-authentication November 2011
PA-OTP-CHALLENGE 141
PA-OTP-CHALLENGE ::= SEQUENCE {
nonce [0] OCTET STRING,
otp-service [1] UTF8String OPTIONAL,
otp-tokenInfo [2] SEQUENCE (SIZE(1..MAX)) OF
OTP-TOKENINFO,
salt [3] KerberosString OPTIONAL,
s2kparams [4] OCTET STRING OPTIONAL,
...
}
OTP-TOKENINFO ::= SEQUENCE {
flags [0] OTPFlags,
otp-vendor [1] UTF8String OPTIONAL,
otp-challenge [2] OCTET STRING (SIZE(1..MAX))
OPTIONAL,
otp-length [3] Int32 OPTIONAL,
otp-format [4] OTPFormat OPTIONAL,
otp-tokenID [5] OCTET STRING OPTIONAL,
otp-algID [6] AnyURI OPTIONAL,
supportedHashAlg [7] SEQUENCE OF AlgorithmIdentifier
OPTIONAL,
iterationCount [8] Int32 OPTIONAL,
...
}
OTPFormat ::= INTEGER {
decimal(0),
hexadecimal(1),
alphanumeric(2),
binary(3),
base64(4)
}
OTPFlags ::= KerberosFlags
-- reserved(0),
-- nextOTP(1),
-- combine(2),
-- collect-pin(3),
-- do-not-collect-pin(4),
-- must-encrypt-nonce (5),
-- separate-pin-required (6),
-- check-digit (7)
Richards Expires May 26, 2012 [Page 19]
Internet-Draft OTP Pre-authentication November 2011
nonce
A KDC-supplied nonce value to be encrypted by the client in the
PA-OTP-REQUEST. This nonce string MUST contain a randomly chosen
component at least as long as the armor key length.
otp-service
Use of this field is OPTIONAL, but MAY be used by the KDC to
assist the client to locate the appropriate OTP tokens to be used.
For example, this field could be used when a user has multiple OTP
tokens for different purposes.
otp-tokenInfo
This element MUST be included and it is a sequence of one or more
OTP-TOKENINFO objects containing information on the token or
tokens that the user can use for the authentication and how the
OTP value is to be generated using those tokens. If a single OTP-
TOKENINFO object is included then only a single token is
acceptable by the KDC and any OTP value generated by the client
MUST be generated according to the information contained within
that element. If more than one OTP-TOKENINFO object is included
then the OTP value MUST be generated according to the information
contained within one of those objects.
flags
If the "nextOTP" flag is set then the OTP SHALL be based on the
next token "state" rather than the one used in the previous
authentication. As an example, for a time-based token, this
means the next time slot and for an event-based token, this
could mean the next counter value. If the "nextOTP" flag is
set then there MUST only be a single otp-tokenInfo element in
the PA-OTP-CHALLENGE.
The "combine" flag controls how the challenge included in otp-
challenge shall be used. If the flag is set then OTP SHALL be
calculated using the challenge from otp-challenge and the
internal token state (e.g. time or counter). If the "combine"
flag is not set then the OTP SHALL be calculated based only on
the challenge. If the flag is set and otp-challenge is not
present then the request SHALL be regarded as invalid.
If the "do-not-collect-pin" flag is set then the token
represented by the current otp-tokenInfo does not require a PIN
to be collected as part of the OTP. If the "collect-pin" flag
is set then the token requires a PIN. If neither flag is set
then whether or not a PIN is required is unspecified. The
flags are mutually exclusive and so both flags MUST NOT be set,
or the client MUST regard the request as invalid.
Richards Expires May 26, 2012 [Page 20]
Internet-Draft OTP Pre-authentication November 2011
If the "must-encrypt-nonce" flag is set then the OTP value MUST
NOT be included in the otp-value field of the PA-OTP-REQUEST
but instead MUST be used in the generation of the Reply Key and
Client Key as described in Section 3.6.
If the "separate-pin-required" flag is set then the PIN
collected by the client SHOULD NOT be used in the generation of
the OTP value and SHOULD be returned in the otp-pin field of
the PA-OTP-REQUEST.
The "check-digit" flag controls whether or not the OTP values
generated by the token need to include a Luhn check digit
[ISOIEC7812]. If the token is disconnected then the Client MAY
ignore this flag but if this flag is set and the token is
connected then the OTP MUST be decimal with a check digit
appended.
otp-vendor
Use of this field is OPTIONAL, but MAY be used by the KDC to
identify the vendor of the OTP token to be used.
otp-challenge
The otp-challenge is used by the KDC to send a challenge value
for use in the OTP calculation. The challenge is an OPTIONAL
octet string that SHOULD be uniquely generated for each request
in which it is present. When the challenge is not present, the
OTP will be calculated on the current token state only. The
client MAY ignore a provided challenge if and only if the OTP
token the client is interacting with is not capable of
including a challenge in the OTP calculation. In this case,
KDC policies will determine whether to accept a provided OTP
value or not.
otp-length
Use of this field is OPTIONAL, but MAY be used by the KDC to
specify the desired length of the generated OTP. For example,
this field could be used when a token is capable of producing
OTP values of different lengths. If the format of the OTP is
'decimal', 'hexidecimal' or 'alphanumeric' then this value
indicates the desired length in digits/characters, if the OTP
format is 'binary' then this value indicates the desired length
in octets and if the OTP format is 'base64' then this value
indicates the desired length of the unencoded OTP value in
octets.
Richards Expires May 26, 2012 [Page 21]
Internet-Draft OTP Pre-authentication November 2011
otp-format
Use of this field is OPTIONAL, but MAY be used by the KDC to
specify the desired format of the generated OTP value. For
example, this field could be used when a token is capable of
producing OTP values of different formats.
otp-tokenID
Use of this field is OPTIONAL, but MAY be used by the KDC to
identify which token key should be used for the authentication.
For example, this field could be used when a user has been
issued multiple token keys by the same server.
otp-algID
Use of this field is OPTIONAL, but MAY be used by the KDC to
identify the algorithm to use when generating the OTP. The
value of this field MUST be a URI [RFC3986] and SHOULD be
obtained from the PSKC algorithm registry [RFC6030].
supportedHashAlg
If present then a hash of the OTP value MUST be used in the key
derivation rather than the plain text value. Each
AlgorithmIdentifier identifies a hash algorithm that is
supported by the KDC in decreasing order of preference. The
client MUST select the first algorithm from the list that it
supports. Support for SHA-256 by both the client and KDC is
REQUIRED. The AlgorithmIdentifier selected by the client MUST
be placed in the hashAlg element of the PA-OTP-REQUEST.
iterationCount
The minimum value of the iteration count to be used by the
client when hashing the OTP value. This value MUST be present
if supportedHashAlg is present and otherwise MUST NOT be
present. If the value of this element does not conform to
local policy on the client then the client MAY use a larger
value but MUST NOT use a lower value. The value of the
iteration count used by the client MUST be returned in the PA-
OTP-REQUEST sent to the KDC.
salt
The salt value to be used in string-to-key when used to calculate
the keys as described in Section 3.6.
s2kparams
Any additional parameters required by string-to-key as described
in Section 3.6.
Richards Expires May 26, 2012 [Page 22]
Internet-Draft OTP Pre-authentication November 2011
4.2. PA-OTP-REQUEST
The padata-type PA-OTP-REQUEST is sent by the client to the KDC in
the KrbFastReq padata of a PA-FX-FAST-REQUEST that is included in the
PA-DATA of an AS-REQ. The corresponding padata-value field contains
the DER encoding of a PA-OTP-REQUEST.
The message contains pre-authentication data encrypted by the client
using the generated Client Key and optional information on how the
OTP was generated. It may also, optionally, contain the generated
OTP value.
PA-OTP-REQUEST 142
PA-OTP-REQUEST ::= SEQUENCE {
flags [0] OTPFlags,
nonce [1] OCTET STRING OPTIONAL,
encData [2] EncryptedData,
-- PA-OTP-ENC-REQUEST or PA-ENC-TS-ENC
-- Key usage of KEY_USAGE_OTP_REQUEST
hashAlg [3] AlgorithmIdentifier OPTIONAL,
iterationCount [4] Int32 OPTIONAL,
otp-value [5] OCTET STRING OPTIONAL,
otp-pin [6] UTF8String OPTIONAL,
otp-challenge [7] OCTET STRING (SIZE(1..MAX)) OPTIONAL,
otp-time [8] KerberosTime OPTIONAL,
otp-counter [9] OCTET STRING OPTIONAL,
otp-format [10] OTPFormat OPTIONAL,
otp-tokenID [11] OCTET STRING OPTIONAL,
otp-algID [12] AnyURI OPTIONAL,
otp-vendor [13] UTF8String OPTIONAL,
...
}
KEY_USAGE_OTP_REQUEST 45
PA-OTP-ENC-REQUEST ::= SEQUENCE {
nonce [0] OCTET STRING,
...
}
flags
This field MUST be present.
Richards Expires May 26, 2012 [Page 23]
Internet-Draft OTP Pre-authentication November 2011
If the "nextOTP" flag is set then the OTP was calculated based on
the next token "state" rather than the current one. This flag
MUST be set if and only if it was set in a corresponding PA-OTP-
CHALLENGE.
If the "combine" flag is set then the OTP was calculated based on
a challenge and the token state.
No other OTPFlag bits are applicable and MUST be ignored by the
KDC.
nonce
This field MUST be present if a hashed OTP value was used as input
to string-to-key (see Section 3.6) and MUST NOT be present
otherwise. If present, it MUST contain the nonce value generated
by the client and used in the generation of hashed OTP values as
described in Section 3.6. This nonce string MUST be as long as
the longest key length of the symmetric key types that the client
supports and MUST be chosen randomly.
encData
This field MUST be present and MUST contain the pre-authentication
data encrypted under the Client Key with a key usage of
KEY_USAGE_OTP_REQUEST. If the PA-OTP-REQUEST is sent as a result
of a PA-OTP-CHALLENGE then this MUST contain a PA-OTP-ENC-REQUEST
with the nonce from the PA-OTP-CHALLENGE. If no challenge was
received then this MUST contain a PA-ENC-TS-ENC.
hashAlg
This field MUST be present if a hashed OTP value was used as input
to string-to-key (see Section 3.6) and MUST NOT be present
otherwise. If present, it MUST contain the AlgorithmIdentifier of
the hash algorithm used. If the PA-OTP-REQUEST is sent as a
result of a PA-OTP-CHALLENGE then the AlgorithmIdentifer MUST be
the first one supported by the client from the supportedHashAlg of
the PA-OTP-CHALLENGE.
iterationCount
This field MUST be present if a hashed OTP value was used as input
to string-to-key (see Section 3.6) and MUST NOT be present
otherwise. If present, it MUST contain the iteration count used
when hashing the OTP value. If the PA-OTP-REQUEST is sent as a
result of a PA-OTP-CHALLENGE then the value MUST NOT be less that
that specified in the PA-OTP-CHALLENGE.
Richards Expires May 26, 2012 [Page 24]
Internet-Draft OTP Pre-authentication November 2011
otp-value
The generated OTP value. This value MUST NOT be present if the
"must-encrypt-nonce" flag was set in the PA-OTP-CHALLENGE.
otp-pin
The OTP PIN value entered by the user. This value MUST NOT be
present unless the "separate-pin-required" flag was set in the PA-
OTP-CHALLENGE.
otp-challenge
Value used by the client in the OTP calculation. It MUST be sent
to the KDC if and only if the value would otherwise be unknown to
the KDC. For example, the token or client modified or generated
challenge.
otp-time
This field MAY be included by the client to carry the time value
as reported by the OTP token. Use of this element is OPTIONAL but
it MAY be used by a client to simplify the OTP calculations
carried out by the KDC. It is RECOMMENDED that the KDC act upon
this value if it is present in the request and it is capable of
using it in the generation of the OTP value.
otp-counter
This field MAY be included by the client to carry the token
counter value, as reported by the OTP token. Use of this element
is OPTIONAL but it MAY be used by a client to simplify the OTP
calculations carried out by the KDC. It is RECOMMENDED that the
KDC act upon this value if it is present in the request and it is
capable of using it in the generation of the OTP value.
otp-format
This field MAY be used by the client to send the format of the
generated OTP as reported by the OTP token. Use of this element
is OPTIONAL but it MAY be used by the client to simplify the OTP
calculations carried out by the KDC. It is RECOMMENDED that the
KDC act upon this value if it is present in the request and it is
capable of using it in the generation of the OTP value.
otp-tokenID
This field MAY be used by the client to send the identifier of the
token key used, as reported by the OTP token. Use of this field
is OPTIONAL but MAY be used by the client to simplify the
authentication process by identifying a particular token key
associated with the user. It is RECOMMENDED that the KDC act upon
this value if it is present in the request and it is capable of
using it in the generation of the OTP value.
Richards Expires May 26, 2012 [Page 25]
Internet-Draft OTP Pre-authentication November 2011
otp-algID
This field MAY be used by the client to send the identifier of the
OTP algorithm used, as reported by the OTP token. Use of this
element is OPTIONAL but it MAY be used by the client to simplify
the OTP calculations carried out by the KDC. It is RECOMMENDED
that the KDC act upon this value if it is present in the request
and it is capable of using it in the generation of the OTP value.
The value of this field MUST be a URI [RFC3986] and SHOULD be
obtained from the PSKC algorithm registry [RFC6030].
otp-vendor
If the PA-OTP-REQUEST is being sent in response to a PA-OTP-
CHALLENGE that contained an otp-vendor field in the selected otp-
tokenInfo then this field MUST be set to the same value,
otherwise, this field SHOULD be set to the vendor identifier of
the token if known to the client. It is RECOMMENDED that the KDC
act upon this value if it is present in the request and it is
capable of using it in the generation of the OTP value.
4.3. PA-OTP-PIN-CHANGE
The padata-type PA-OTP-PIN-CHANGE is returned by the KDC in the enc-
fast-rep of a PA-FX-FAST-REPLY in the AS-REP if the user must change
their PIN, if the user's PIN has been changed or to notify the user
of the PIN's expiry time.
The corresponding padata-value field contains the DER encoding of a
PA-OTP-PIN-CHANGE.
PA-OTP-PIN-CHANGE 144
PA-OTP-PIN-CHANGE ::= SEQUENCE {
flags [0] PinFlags,
pin [1] UTF8String OPTIONAL,
minLength [2] INTEGER OPTIONAL,
maxLength [3] INTEGER OPTIONAL,
last-req [4] LastReq OPTIONAL,
format [5] OTPFormat OPTIONAL,
...
}
PinFlags ::= KerberosFlags
-- reserved(0),
-- systemSetPin(1),
-- mandatory(2)
Richards Expires May 26, 2012 [Page 26]
Internet-Draft OTP Pre-authentication November 2011
flags
The "systemSetPin" flag is used to indicate the type of PIN change
that is taking place. If the flag is set then the user's PIN has
been changed for the user by the system. If the flag is not set
then the user's PIN needs to be changed by the user.
If the "systemSetPin" flag is not set and the "mandatory" flag is
set then user PIN change is required before the next
authentication using the current OTP token. If the "mandatory"
flag is not set then the user PIN change is optional. If the
"systemSetPin" flag is set then the "mandatory" flag has no
meaning and SHOULD be ignored by the client.
pin
The pin field is used to carry a new PIN value. If the
"systemSetPin" flag is set then field is used to carry the new PIN
value set for the user and MUST be present. If the "systemSetPin"
flag is not set then use of this field OPTIONAL and MAY be used to
carry a system generated PIN that MAY be used by the user when
changing the PIN.
minLength and maxLength
Use of the minLength and maxLength fields is OPTIONAL. If the
"systemSetPin" flag is not set then these fields MAY be included
to pass restrictions on the size of the user selected PIN.
last-req
Use of the last-req field (as defined in section 5.4.2 of
[RFC4120])) is OPTIONAL but MAY be included with an lr-type of 6
to carry PIN expiration information.
* If the "systemSetPin" flag is set then the expiration time MUST
be that of the new system-set PIN.
* If the "systemSetPin" flag is not set then the expiration time
MUST be that of the current PIN of the token used in the
authentication.
The element MAY also be included with an lr-type of 7 to indicate
when the OTP account will expire.
format
The format element MAY be included by the KDC to carry PIN format
restrictions on the new PIN.
* If the "systemSetPin" flag is set then the element MUST
describe the format of the new system-generated PIN.
Richards Expires May 26, 2012 [Page 27]
Internet-Draft OTP Pre-authentication November 2011
* If the "systemSetPin" flag is not set then the element MUST
describe restrictions on any new user generated PIN.
5. IANA Considerations
The OTP algorithm identifier URIs used as otp-algID values in the PA-
OTP-CHALLENGE described in Section 4.1 and the PA-OTP-REQUEST
described in Section 4.2 SHOULD be registered in the PSKC algorithm
registry [RFC6030].
The following pre-authentication types are defined in this document:
PA-OTP-CHALLENGE 141
PA-OTP-REQUEST 142
PA-OTP-PIN-CHANGE 144
These values are currently registered in registry created by
[RFC6113] but the entries will need to be updated to refer to this
document.
The following error codes and key usage values are defined in this
document:
KDC_ERR_INVALID_HASH_ALG 94
KDC_ERR_INVALID_ITERATION_COUNT 95
KDC_ERR_PIN_EXPIRED 96
KDC_ERR_PIN_REQUIRED 97
KEY_USAGE_OTP_REQUEST 45
These values are currently not managed by IANA and have been
accounted for. There is currently work in progress [LHA10] to define
IANA registries and a registration process for these values.
No other IANA actions are anticipated.
6. Security Considerations
6.1. Man-in-the-Middle
In the system described in this document, the OTP pre-authentication
protocol is tunneled within the FAST Armor channel provided by the
pre-authentication framework. As described in [AsNiNy02], tunneled
protocols are potentially vulnerable to man-in-the-middle attacks if
the outer tunnel is compromised and it is generally considered good
practice in such cases to bind the inner encryption to the outer
tunnel.
Richards Expires May 26, 2012 [Page 28]
Internet-Draft OTP Pre-authentication November 2011
In order to mitigate against such attacks, the proposed system uses
the outer Armor Key in the derivation of the inner Client and Reply
keys and so achieve crypto-binding to the outer channel.
As described in section 5.4 of [RFC6113], FAST can use an anonymous
TGT obtained using anonymous PKINIT [RFC6112] [RFC4556] as the Armor
Key. However, the current anonymous PKINIT proposal is open to man-
in-the-middle attacks since the attacker can choose a session key
such that the session key between the MITM and the real KDC is the
same as the session key between the client and the MITM.
As described in Section 3.6, if the OTP value is not being sent to
the KDC then the Armor Key is used along with the OTP value in the
generation of the Client Key and Reply Key. If the Armor Key is known
then the only entropy remaining in the key generation is provided by
the OTP value. If the OTP algorithm requires that the OTP value be
sent to the KDC then it is sent encrypted within the tunnel provided
by the FAST armor and so is exposed to the attacker if the attacker
has the Armor Key.
Therefore, unless the identity of the KDC has been verified,
anonymous PKINIT SHALL NOT be used with OTP algorithms that require
the OTP value to be sent to the KDC. In addition, the security
considerations should be carefully considered before anonymous PKINIT
is used with other algorithms such as those with short OTP values.
Careful consideration should also be made if host key armor is used
to provide the KDC-authentication facility with OTP algorithms where
the OTP value is sent within the otp-value field of the PA-OTP-
REQUEST since compromised host keys would allow an attacker to
impersonate the KDC.
6.2. Reflection
The 4-pass system described above is a challenge-response protocol
and such protocols are potentially vulnerable to reflection attacks.
No such attacks are known at this point but to help mitigate against
such attacks, the system uses different keys to encrypt the client
and server nonces.
6.3. Denial of Service
The protocol supports the use of an iteration count in the generation
of the Client and Reply keys and the client can send the number of
iterations used as part of the PA-OTP-REQUEST. This could open the
KDC up to a denial of service attack if a large value for the
iteration count was specified by the attacker. It is therefore
particularly important that, as described in Section 3.4, the KDC
Richards Expires May 26, 2012 [Page 29]
Internet-Draft OTP Pre-authentication November 2011
reject any authentication requests where the iteration count is above
a maximum value specified by local policy.
6.4. Replay
In the 4-pass version of this protocol, the client encrypts a KDC
generated nonce and so replay can be detected by the KDC. The 2-pass
version of the protocol does not involve a server nonce but the
client instead encrypts a timestamp and so is not protected from
replay in this way but will instead require some other mechanism such
as an OTP-server based system or a timestamp-based replay cache on
the KDC.
As described in section 5.2 of [RFC6113], a client can not be certain
that it will use the same KDC for all messages in a conversation.
Therefore, the client cannot assume that the PA-OTP-REQUEST will be
sent to the same KDC that issued the PA-OTP-CHALLENGE. In order to
support this, a KDC implementing this protocol requires a means of
sharing session state. However, doing this does introduce the
possibility of a replay attack where the same response is sent to
multiple KDCs.
In the case of time or event-based tokens or server-generated
challenges, protection against replay may be provided by the OTP
server being used if that server is capable of keeping track of the
last used value. This protection therefore relies upon the
assumption that the OTP server being used in this protocol is either
not redundant or involves a commit protocol to synchronize between
replicas. If this does not hold for an OTP server being used then
the system may be vulnerable to replay attack.
However, OTP servers may not be able to detect replay of OTPs
generated using only a client generated challenge and since the KDC
would not be able to detect replay in 2-pass mode, it is recommended
that the use of OTPs generated from only a client-generated challenge
(that is, not in combination with some other factor such as time)
should not be supported in 2-pass mode.
6.5. Brute Force Attack
A compromised or hostile KDC may be able to obtain the OTP value used
by the client via a brute force attack. If the OTP value is short
then the KDC could iterate over the possible OTP values until a
Client Key is generated that can decrypt the encData sent in the PA-
OTP-REQUEST.
As described in Section 3.6, an iteration count can be used in the
generation of the Client Key and the value of the iteration count can
Richards Expires May 26, 2012 [Page 30]
Internet-Draft OTP Pre-authentication November 2011
be controlled by local client policy. Use of this iteration count
can make it computationally infeasible/unattractive for an attacker
to brute-force search for the given OTP within the lifetime of that
OTP.
If PINs contain international characters, similar looking or similar
functioning characters may be mapped together. For example, the
combined and decomposed forms of accented characters will typically
be treated the same. Users who attempt to exploit artifacts of
international characters to improve the strength of their PINs may
experience false positives in the sense that PINs they intended to be
distinct are not actually distinct. This decision was made in order
to improve usability across the widest variety of input methods.
Users can choose other methods to add strength to PINs.
6.6. FAST Facilities
The secret used to generate the OTP is known only to the client and
the KDC and so successful decryption of the encrypted nonce by the
KDC authenticates the user. If the OTP value is used in the Reply
Key generation then successful decryption of the encrypted nonce by
the client proves that the expected KDC replied. The Reply Key is
replaced by either a key generated from the OTP and Armor Key or by
the Armor Key. This FAST factor therefore provides the following
facilities: client-authentication, replacing-reply-key and, depending
on the OTP algorithm, KDC-authentication.
7. Acknowledgments
Many significant contributions were made to this document by RSA
employees but special thanks go to Magnus Nystrom, John Linn, Richard
Zhang, Piers Bowness, Robert Philpott, Robert Polansky and Boris
Khoutorski.
Many valuable suggestions were also made by members of the Kerberos
Working Group but special thanks go to Larry Zhu, Jeffrey Hutzelman,
Tim Alsop, Henry Hotz, Nicolas Williams, Sam Hartman, Frank Cusak,
Simon Josefsson, Greg Hudson and Linus Nordberg.
I would also like to thank Tim Alsop and Srinivas Cheruku of
CyberSafe for many valuable review comments.
8. References
Richards Expires May 26, 2012 [Page 31]
Internet-Draft OTP Pre-authentication November 2011
8.1. Normative References
[ISOIEC7812]
ISO, "ISO/IEC 7812-1:2006 Identification cards --
Identification of issuers -- Part 1: Numbering system",
October 2006, <http://www.iso.org/iso/iso_catalogue/
catalogue_tc/catalogue_detail.htm?csnumber=39698>.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
Kerberos 5", RFC 3961, February 2005.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names
and Passwords", RFC 4013, February 2005.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005.
[RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial
Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[RFC6112] Zhu, L., Leach, P., and S. Hartman, "Anonymity Support for
Kerberos", RFC 6112, April 2011.
[RFC6113] Hartman, S. and L. Zhu, "A Generalized Framework for
Kerberos Pre-Authentication", RFC 6113, April 2011.
[X.680] ITU-T, "Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
Information technology - Abstract Syntax Notation One
Richards Expires May 26, 2012 [Page 32]
Internet-Draft OTP Pre-authentication November 2011
(ASN.1): Specification of basic notation.", July 2002.
[X.690] ITU-T, "Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
Information technology - ASN.1 encoding Rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER).", December 2002.
8.2. Informative References
[AsNiNy02]
Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle
in Tunneled Authentication Protocols", Cryptology ePrint
Archive Report 2002/163, November 2002.
[HoReNeZo04]
Horstein, K., Renard, K., Neuman, C., and G. Zorn,
"Integrating Single-use Authentication Mechanisms with
Kerberos", draft-ietf-krb-wg-kerberos-sam-03 (work in
progress), July 2004.
[LHA10] Hornquist Astrand, L., "Kerberos number registry to IANA",
draft-lha-krb-wg-some-numbers-to-iana-00 (work in
progress), March 2010.
[RFC2289] Haller, N., Metz, C., Nesser, P., and M. Straw, "A One-
Time Password System", RFC 2289, February 1998.
[RFC2808] Nystrom, M., "The SecurID(r) SASL Mechanism", RFC 2808,
April 2000.
[RFC4226] M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and
O. Ranen, "HOTP: An HMAC-Based One-Time Password
Algorithm", RFC 4226, December 2005.
[RFC6030] Hoyer, P., Pei, M., and S. Machani, "Portable Symmetric
Key Container (PSKC)", RFC 6030, October 2010.
Appendix A. ASN.1 Module
OTPKerberos
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
KerberosTime, KerberosFlags, EncryptionKey, Int32,
Richards Expires May 26, 2012 [Page 33]
Internet-Draft OTP Pre-authentication November 2011
EncryptedData, LastReq, KerberosString
FROM KerberosV5Spec2 {iso(1) identified-organization(3)
dod(6) internet(1) security(5)
kerberosV5(2) modules(4) krb5spec2(2)}
-- as defined in RFC 4120.
AlgorithmIdentifier
FROM PKIX1Explicit88 { iso (1) identified-organization (3)
dod (6) internet (1)
security (5) mechanisms (5) pkix (7)
id-mod (0) id-pkix1-explicit (18) };
-- As defined in RFC 5280.
PA-OTP-CHALLENGE ::= SEQUENCE {
nonce [0] OCTET STRING,
otp-service [1] UTF8String OPTIONAL,
otp-tokenInfo [2] SEQUENCE (SIZE(1..MAX)) OF
OTP-TOKENINFO,
salt [3] KerberosString OPTIONAL,
s2kparams [4] OCTET STRING OPTIONAL,
...
}
OTP-TOKENINFO ::= SEQUENCE {
flags [0] OTPFlags,
otp-vendor [1] UTF8String OPTIONAL,
otp-challenge [2] OCTET STRING (SIZE(1..MAX))
OPTIONAL,
otp-length [3] Int32 OPTIONAL,
otp-format [4] OTPFormat OPTIONAL,
otp-tokenID [5] OCTET STRING OPTIONAL,
otp-algID [6] AnyURI OPTIONAL,
supportedHashAlg [7] SEQUENCE OF AlgorithmIdentifier
OPTIONAL,
iterationCount [8] Int32 OPTIONAL,
...
}
OTPFormat ::= INTEGER {
decimal(0),
hexadecimal(1),
alphanumeric(2),
binary(3),
base64(4)
}
OTPFlags ::= KerberosFlags
-- reserved(0),
-- nextOTP(1),
Richards Expires May 26, 2012 [Page 34]
Internet-Draft OTP Pre-authentication November 2011
-- combine(2),
-- collect-pin(3),
-- do-not-collect-pin(4),
-- must-encrypt-nonce (5),
-- separate-pin-required (6),
-- check-digit (7)
PA-OTP-REQUEST ::= SEQUENCE {
flags [0] OTPFlags,
nonce [1] OCTET STRING OPTIONAL,
encData [2] EncryptedData,
-- PA-OTP-ENC-REQUEST or PA-ENC-TS-ENC
-- Key usage of KEY_USAGE_OTP_REQUEST
hashAlg [3] AlgorithmIdentifier OPTIONAL,
iterationCount [4] Int32 OPTIONAL,
otp-value [5] OCTET STRING OPTIONAL,
otp-pin [6] UTF8String OPTIONAL,
otp-challenge [7] OCTET STRING (SIZE(1..MAX)) OPTIONAL,
otp-time [8] KerberosTime OPTIONAL,
otp-counter [9] OCTET STRING OPTIONAL,
otp-format [10] OTPFormat OPTIONAL,
otp-tokenID [11] OCTET STRING OPTIONAL,
otp-algID [12] AnyURI OPTIONAL,
otp-vendor [13] UTF8String OPTIONAL,
...
}
PA-OTP-ENC-REQUEST ::= SEQUENCE {
nonce [0] OCTET STRING,
...
}
PA-OTP-PIN-CHANGE ::= SEQUENCE {
flags [0] PinFlags,
pin [1] UTF8String OPTIONAL,
minLength [2] INTEGER OPTIONAL,
maxLength [3] INTEGER OPTIONAL,
last-req [4] LastReq OPTIONAL,
format [5] OTPFormat OPTIONAL,
...
}
PinFlags ::= KerberosFlags
-- reserved(0),
-- systemSetPin(1),
-- mandatory(2)
Richards Expires May 26, 2012 [Page 35]
Internet-Draft OTP Pre-authentication November 2011
AnyURI ::= UTF8String
(CONSTRAINED BY {
-- MUST be a valid URI in accordance with IETF RFC 2396
})
END
Appendix B. Examples of OTP Pre-Authentication Exchanges
This section is non-normative.
B.1. Four Pass Authentication
In this mode, the client sends an initial AS-REQ to the KDC that does
not contain a PA-OTP-REQUEST and the KDC responds with a KRB-ERROR
containing a PA-OTP-CHALLENGE.
In this example, the user has been issued with a connected, time-
based token and the KDC requires hashed OTP values in the key
generation with SHA-384 as the preferred hash algorithm and a minimum
of 1024 iterations. The local policy on the client supports SHA-256
and requires 100,000 iterations of the hash of the OTP value.
The basic sequence of steps involved is as follows:
1. The client obtains the user name of the user.
2. The client sends an initial AS-REQ to the KDC that does not
contain a PA-OTP-REQUEST.
3. The KDC determines that the user identified by the AS-REQ
requires OTP authentication.
4. The KDC constructs a PA-OTP-CHALLENGE as follows:
nonce
A randomly generated value.
otp-service
A string that can be used by the client to assist the user in
locating the correct token.
otp-tokenInfo
Information about how the OTP should be generated from the
token.
Richards Expires May 26, 2012 [Page 36]
Internet-Draft OTP Pre-authentication November 2011
flags
must-encrypt-nonce and collect-pin bits set
supportedHashAlg
AlgorithmIdentifiers for SHA-384, SHA-256 and SHA-1
iterationCount
1024
5. The KDC returns a KRB-ERROR with an error code of
KDC_ERR_PREAUTH_REQUIRED and the PA-OTP-CHALLENGE in the e-data.
6. The client displays the value of otp-service and prompts the
user to connect the token.
7. The client collects a PIN from the user.
8. The client obtains the current OTP value from the token using
the PIN and records the time as reported by the token.
9. The client generates the Client Key and Reply Key as described
in Section 3.6 using SHA-256 from the list of algorithms sent by
the KDC, the iteration count of 100,000 as required by local
policy and a randomly generated nonce.
10. The client constructs a PA-OTP-REQUEST as follows:
flags
0
nonce
The randomly generated value.
encData
An EncryptedData containing a PA-OTP-ENC-REQUEST encrypted
under the Client Key with a key usage of
KEY_USAGE_OTP_REQUEST and the encryption type of the Armor
Key. The PA-OTP-ENC-REQUEST contains the nonce from the PA-
OTP-CHALLENGE.
hashAlg
SHA-256
iterationCount
100,000
Richards Expires May 26, 2012 [Page 37]
Internet-Draft OTP Pre-authentication November 2011
otp-time
The time used in the OTP calculation as reported by the OTP
token.
11. The client encrypts the PA-OTP-REQUEST within the enc-fast-req
of a PA-FX-FAST-REQUEST.
12. The client sends an AS-REQ to the KDC containing the PA-FX-FAST-
REQUEST within the padata.
13. The KDC validates the pre-authentication data in the PA-OTP-
REQUEST:
* Generates the Client Key and Reply Key from the OTP value for
the user identified in the AS-REQ, using an iteration count
of 100,000, a hash algorithm of SHA-256 and the nonce as
specified in the PA-OTP-REQUEST.
* Uses the generated Client Key to decrypt the PA-OTP-ENC-
REQUEST in the encData of the PA-OTP-REQUEST.
* Authenticates the user by comparing the nonce value from the
decrypted PA-OTP-ENC-REQUEST to that sent in the
corresponding PA-OTP-CHALLENGE.
14. The KDC constructs a TGT for the user.
15. The KDC returns an AS-REP to the client, encrypted using the
Reply Key, containing the TGT and padata with the PA-FX-FAST-
REPLY.
16. The client authenticates the KDC and verifies the Reply Key
change.
* Uses the generated Reply Key to decrypt the encrypted data in
the AS-REP.
B.2. Two Pass Authentication
In this mode, the client includes a PA-OTP-REQUEST within a PA-FX-
FAST-REQUEST pre-auth of the initial AS-REQ sent to the KDC.
In this example, the user has been issued with a hand-held token and
so none of the OTP generation parameters (otp-length etc) are
included in the PA-OTP-REQUEST. The KDC does not require hashed OTP
values in the key generation.
Richards Expires May 26, 2012 [Page 38]
Internet-Draft OTP Pre-authentication November 2011
It is assumed that the client has been configured with the following
information or has obtained it from a previous PA-OTP-CHALLENGE.
o The fact that the OTP value must not be carried in the otp-value
o The fact that hashed OTP values are not required.
The basic sequence of steps involved is as follows:
1. The client obtains the user name and OTP value from the user.
2. The client generates the Client Key and Reply Key using unhashed
OTP values as described in Section 3.6.
3. The client constructs a PA-OTP-REQUEST as follows:
flags
0
encData
An EncryptedData containing a PA-ENC-TS-ENC encrypted under
the Client Key with a key usage of KEY_USAGE_OTP_REQUEST and
an encryption type of the Armor Key. The PA-ENC-TS-ENC
contains the current client time.
4. The client encrypts the PA-OTP-REQUEST within the enc-fast-req of
a PA-FX-FAST-REQUEST.
5. The client sends an AS-REQ to the KDC containing the PA-FX-FAST-
REQUEST within the padata.
6. The KDC validates the pre-authentication data:
* Generates the Client Key and Reply Key from the unhashed OTP
value for the user identified in the AS-REQ.
* Uses the generated Client Key to decrypt the PA-ENC-TS-ENC in
the encData of the PA-OTP-REQUEST.
* Authenticates the user using the timestamp in the standard
manner.
7. The KDC constructs a TGT for the user.
8. The KDC returns an AS-REP to the client, encrypted using the
Reply Key, containing the TGT and padata with the PA-FX-FAST-
REPLY.
Richards Expires May 26, 2012 [Page 39]
Internet-Draft OTP Pre-authentication November 2011
9. The client authenticates the KDC and verifies the key change.
* Uses the generated Reply Key to decrypt the encrypted data in
the AS-REP.
B.3. PIN Change
This exchange follows from the point where the KDC receives the PA-
OTP-REQUEST from the client in the examples in Appendix B.1 and
Appendix B.2. During the validation of the pre-authentication data
(whether encrypted nonce or encrypted timestamp), the KDC determines
that the user's PIN has expired and so must be changed. The KDC
therefore includes a PA-OTP-PIN-CHANGE in the AS-REP.
In this example, the KDC does not generate PIN values for the user
but requires that the user generate a new PIN that is between 4 and 8
characters in length. The actual PIN change is handled by a PIN
change service.
The basic sequence of steps involved is as follows:
1. The client constructs and sends a PA-OTP-REQUEST to the KDC as
described in the previous examples.
2. The KDC validates the pre-authentication data and authenticates
the user as in the previous examples but determines that the
user's PIN has expired.
3. KDC constructs a ticket for a PIN change service with a one
minute lifetime.
4. KDC constructs a PA-OTP-PIN-CHANGE as follows:
flags
0
minLength
4
maxLength
8
5. KDC encrypts the PA-OTP-PIN-CHANGE within the enc-fast-rep of a
PA-FX-FAST-REPLY.
6. KDC returns a KRB-ERROR to the client of type KDC_ERR_PIN_EXPIRED
containing the ticket to the PIN change service and padata
containing the PA-FX-FAST-REPLY.
Richards Expires May 26, 2012 [Page 40]
Internet-Draft OTP Pre-authentication November 2011
7. The client uses the ticket requests a ticket for a PIN change
service and changes the user's PIN.
8. The client sends a second AS-REQ to the KDC containing a PA-OTP-
REQUEST constructed using the new PIN.
9. The KDC responds with an AS-REP containing a TGT.
B.4. Resynchronization
This exchange follows from the point where the KDC receives the PA-
OTP-REQUEST from the client. During the validation of the pre-
authentication data (whether encrypted nonce or encrypted timestamp),
the KDC determines that the local record of the token's state needs
to be re-synchronized with the token. The KDC therefore includes a
KRB-ERROR containing a PA-OTP-CHALLENGE with the "nextOTP" flag set.
The sequence of steps below follows is a variation of the four pass
examples shown in Appendix B.1 but the same process would also work
in the two-pass case.
1. The client constructs and sends a PA-OTP-REQUEST to the KDC as
described in the previous examples.
2. The KDC validates the pre-authentication data and authenticates
the user as in the previous examples but determines that user's
token requires re-synchronizing.
3. KDC constructs a PA-OTP-CHALLENGE as follows:
nonce
A randomly generated value.
otp-service
Set to a string that can be used by the client to assist the
user in locating the correct token.
otp-tokenInfo
Information about how the OTP should be generated from the
token.
flags
must-encrypt-nonce, collect-pin and nextOTP bits set
Richards Expires May 26, 2012 [Page 41]
Internet-Draft OTP Pre-authentication November 2011
supportedHashAlg
AlgorithmIdentifiers for SHA-256 and SHA-1
iterationCount
1024
4. KDC returns a KRB-ERROR with an error code of
KDC_ERR_PREAUTH_REQUIRED and the PA-OTP-CHALLENGE in the e-data.
5. The client obtains the next OTP value from the token and records
the time as reported by the token.
6. The client generates the Client Key and Reply Key as described
in Section 3.6 using SHA-256 from the list of algorithms sent by
the KDC, the iteration count of 100,000 as required by local
policy and a randomly generated nonce.
7. The client constructs a PA-OTP-REQUEST as follows:
flags
nextOTP bit set
nonce
The randomly generated value.
encData
An EncryptedData containing a PA-OTP-ENC-REQUEST encrypted
under the Client Key with a key usage of
KEY_USAGE_OTP_REQUEST and the encryption type of the Armor
Key. The PA-OTP-ENC-REQUEST contains the nonce from the PA-
OTP-CHALLENGE.
hashAlg
SHA-256
iterationCount
100,000
otp-time
The time used in the OTP calculation as reported by the OTP
token.
8. The client encrypts the PA-OTP-REQUEST within the enc-fast-req
of a PA-FX-FAST-REQUEST.
9. The client sends an AS-REQ to the KDC containing the PA-FX-FAST-
REQUEST within the padata.
Richards Expires May 26, 2012 [Page 42]
Internet-Draft OTP Pre-authentication November 2011
10. Authentication process now proceeds as with the classic
sequence.
Author's Address
Gareth Richards
RSA, The Security Division of EMC
RSA House
Western Road
Bracknell, Berkshire RG12 1RT
UK
Email: gareth.richards@rsa.com
Richards Expires May 26, 2012 [Page 43]