Network Working Group G. Richards
Internet-Draft RSA, The Security Division of EMC
Intended status: Standards Track December 3, 2007
Expires: June 5, 2008
OTP Preauthentication
draft-ietf-krb-wg-otp-preauth-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 June 5, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
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.
Richards Expires June 5, 2008 [Page 1]
Internet-Draft OTP Preauthentication December 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Usage Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Pre-Authentication . . . . . . . . . . . . . . . . . . . . 4
2.2. PIN Change . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Re-Synchronization . . . . . . . . . . . . . . . . . . . . 5
3. Pre-Authentication Protocol Details . . . . . . . . . . . . . 5
3.1. Initial Client Request . . . . . . . . . . . . . . . . . . 5
3.2. KDC Challenge . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Client Response . . . . . . . . . . . . . . . . . . . . . 6
3.4. Verifying the pre-auth Data . . . . . . . . . . . . . . . 7
3.5. Confirming the Reply Key Change . . . . . . . . . . . . . 8
3.6. Reply Key Generation . . . . . . . . . . . . . . . . . . . 8
4. OTP Kerberos Message Types . . . . . . . . . . . . . . . . . . 10
4.1. PA-OTP-CHALLENGE . . . . . . . . . . . . . . . . . . . . . 10
4.2. PA-OTP-REQUEST . . . . . . . . . . . . . . . . . . . . . . 12
4.3. PA-OTP-CONFIRM . . . . . . . . . . . . . . . . . . . . . . 14
4.4. PA-OTP-PIN-CHANGE . . . . . . . . . . . . . . . . . . . . 15
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6.1. Man-in-the-Middle . . . . . . . . . . . . . . . . . . . . 15
6.2. Reflection . . . . . . . . . . . . . . . . . . . . . . . . 16
6.3. Replay . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.4. FAST Facilities . . . . . . . . . . . . . . . . . . . . . 16
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Normative References . . . . . . . . . . . . . . . . . . . 16
7.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 20
Richards Expires June 5, 2008 [Page 2]
Internet-Draft OTP Preauthentication December 2007
1. Introduction
A One-Time Password (OTP) token may be a handheld hardware device, a
hardware device connected to a personal computer through an
electronic interface such as USB or a software module resident on a
personal computer. All these devices generate one-time passwords
that may be used to authenticate a user towards some service. This
document describes a FAST [ZhHa07] factor that allows 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.
This FAST factor provides the following facilities (as defined in
[ZhHa07]): client-authentication, replacing-reply-key and KDC-
authentication. It does not provide the strengthening-reply-key
facility.
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 along with
its own random value to the KDC in a second AS-REQ. Finally, the KDC
returns the client's random value encrypted within the padata of 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. This variant can be used in cases
where the client can determine in advance that OTP pre-authentication
is supported by the KDC and which OTP key should be used.
In both systems, in order to create the message sent to the KDC, the
client must generate the OTP value and three keys: the standard Reply
Key, a key to encrypt the data sent to the KDC and a final key to
decrypt the KDC's reply. 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, 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 message from the client to the KDC is sent within the 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 returning the
client's nonce encrypted under one of the generated keys within the
encrypted part of the FAST padata of the AS-REP.
This proposal is partially based upon previous work on integrating
Richards Expires June 5, 2008 [Page 3]
Internet-Draft OTP Preauthentication December 2007
single-use authentication mechanisms into Kerberos [HoReNeZo04] and
uses the existing password-change extensions to handle PIN change as
described in [RFC3244].
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].
2. Usage Overview
2.1. Pre-Authentication
The approach uses pre-authentication data in KRB_AS_REQ, KRB_AS_REP
and KRB_ERROR messages.
In the 4-pass system, the client begins by sending an initial
KRB_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 in the PA-DATA.
The PA-OTP-CHALLENGE will contain a KDC generated nonce, an
encryption type, an optional list of hash algorithm identifiers, an
optional iteration count and optional information on how the OTP
should be generated by the client. The client will then generate the
OTP value, its own nonce and three keys: the Reply Key, a Client Key
to encrypt the KDC's nonce and a Server Key used to decrypt the KDC's
reply.
As described in Section 3.6, these keys will be generated from the
Armor Key (defined in [ZhHa07]) 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 request then the client
will use the hash of the OTP value rather than the plaintext value in
the key generation.
The generated Client Key will be used to encrypt the nonce received
from the KDC using the specified encryption type. The encrypted
value, a random nonce generated by the client along with information
on how the OTP was generated are then sent to the KDC in a PA-OTP-
REQUEST element encrypted within the armored-data of a PA-FX-FAST-
REQUEST PA-DATA element of a second KRB_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
Richards Expires June 5, 2008 [Page 4]
Internet-Draft OTP Preauthentication December 2007
the KDC, the client includes an encrypted timestamp in the request
rather than the encrypted KDC nonce.
On receipt of a PA-OTP-REQUEST, the KDC generate the same keys as the
client, allowing it to verify the pre-authentication by decrypting
the encrypted sent by the client (either nonce or timestamp). If the
validation succeeds then the KDC will confirm that the Reply Key was
updated by encrypting the client's nonce and returning the encrypted
value in a PA-OTP-CONFIRM element encrypted within the armored-data
of a PA-FX-FAST-REPLY PA-DATA element of the KRB_AS_REP.
2.2. PIN Change
If, following successful validation of a PA-OTP-REQUEST in a
KRB_AS_REQ, the KDC requires that the user changes their PIN then it
will include a PA-OTP-PIN-CHANGE element in the armored data of the
PA-FX-FAST-REPLY PA-DATA element of the KRB_AS_REP. This data can be
used to return a new PIN to the user if the KDC has updated the PIN
or to indicate to the user that they must change their PIN.
In the latter case, it is recommended that user PIN change be handled
by a PIN change service supporting the ChangePasswdData in a
KRB_AP_REQ as described in [RFC3244]. If a user PIN change is
required and such a service is used then the KDC MAY return a TGT in
the KRB_AS_REP but it is RECOMMENDED that it return an INITIAL ticket
for the PIN change service until the PIN has been changed.
2.3. Re-Synchronization
It is possible with time and event-based tokens that the client and
OTP server will lose synchronization. If, when processing a PA-OTP-
REQUEST, the pre-authentication validation fails for this reason then
the KDC SHALL return a KRB_ERROR message containing a PA-OTP-
CHALLENGE in the PA-DATA with the "nextOTP" flag set. If this flag
is set then the client MUST re-try the authentication using the OTP
for the token "state" after that used in the failed authentication
attempt.
3. Pre-Authentication Protocol Details
3.1. Initial Client Request
The client begins by sending an initial KRB_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.
Richards Expires June 5, 2008 [Page 5]
Internet-Draft OTP Preauthentication December 2007
Alternatively, if the client has all the necessary information, it
MAY construct a PA-OTP-REQUEST as described in Section 3.3 and
include it in the initial request.
3.2. KDC Challenge
If the user is required to authenticate using an OTP then the KDC
SHALL respond to the initial KRB_AS_REQ with a KRB_ERROR containing:
o An error code of KDC_ERR_PREAUTH_REQUIRED
o An e-data field containing PA-DATA with a PA-OTP-CHALLENGE.
The PA-OTP-CHALLENGE SHALL contain a random nonce value to be
returned encrypted in the client response and the enctype to be used
by the client to encrypt the nonce.
In order to support situations where the KDC can determine which OTP
key the client should use, the challenge MAY also contain information
on how the OTP value is to be generated.
In addition, in order to support cases where the KDC cannot obtain
plaintext values for the OTPs, the challenge MAY also contain a
sequence of one way hash function algorithm identifiers and an
iteration count that the client MUST use to hash the OTP value.
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 a PA-FX-FAST-REQUEST encrypted
under the current Armor Key.
In order to generate its response, the client first generates an OTP
value. The OTP value MUST be based on the parameters in the KDC
challenge if present and the response SHOULD include information on
the generated OTP value.
The client derives three keys as described in Section 3.6. In order
to support OTP algorithms where the KDC cannot obtain the OTP value,
the client MAY include the generated value in the otp-value field of
the response. However, the client MUST NOT include the OTP value in
the response unless it is allowed by the algorithm profile. If it is
included then the OTP value MUST NOT be used in the key derivation.
If the KDC challenge contains hash algorithm identifiers and the OTP
value is to be used in the key derivation then the client MUST select
one of the algorithms and MUST use the hash of the OTP value to
derive the keys as described in Section 3.6. The selected algorithm
Richards Expires June 5, 2008 [Page 6]
Internet-Draft OTP Preauthentication December 2007
identifier and the iteration count used MUST be included in the
client's response. However, if the algorithm identifiers and
iteration count do not conform to local policy restrictions then the
authentication attempt MUST NOT proceed.
The generated Client Key is used by the client to encrypt data to be
included in the encData of the response to allow the KDC to
authenticate the user.
o If the response is being generated in response to a KDC challenge
then client encrypts the value of nonce from the corresponding
challenge.
o If the response is not in response to a KDC challenge then the
client encrypts the current time as in the encrypted timestamp
pre-authentication mechanism [RFC4120].
Finally, the client generates a random value to include in the nonce
of the response. This value will then be returned encrypted by the
KDC.
3.4. Verifying the pre-auth Data
The KDC validates the pre-authentication data by generating the same
keys as the client as described in Section 3.6. The generated Client
Key is used to decrypt the value of encData from the PA-OTP-REQUEST.
If the otp-value field is not included in the response, then the KDC
SHOULD use any OTP information in the PA-OTP-REQUEST to obtain the
OTP value in order to generate the keys. If the hashAlg field is
present then the hash of the OTP value, as given by the hash
algorithm identifier, was used in the key generation rather than the
plaintext value.
The client authentication MUST fail if the KDC requires hashed OTP
values and the hashAlg field was not present or if the hash algorithm
identifier or iteration count included in the PA-OTP-REQUEST do not
conform to local KDC policy. In such situations, the KDC MAY return
a PA-OTP-CHALLENGE with the required values in the error response.
For example, this technique could be used to return required values
to the client in response to a PA-OTP-REQUEST that was not the result
of a PA-OTP-CHALLENGE.
If the client response was sent as a result of a PA-OTP-CHALLENGE
then the client authentication MUST fail if the decrypted value is
not the same as the nonce value sent in the challenge. If the
response was not sent as a result of a PA-OTP-CHALLENGE then the
decrypted value will be a PA-ENC-TIMESTAMP and the authentication
Richards Expires June 5, 2008 [Page 7]
Internet-Draft OTP Preauthentication December 2007
process will be the same as with standard encrypted timestamp pre-
authentication [RFC4120]
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
client's PA-OTP-REQUEST by including in the AS-REP, the client nonce
from PA-OTP-REQUEST encrypted under the generated Server Key.
The KDC response SHALL be sent to client as a PA-OTP-CONFIRM included
within the enc-fast-rep of a PA-FX-FAST-REPLY encrypted under the
current Armor Key.
3.6. Reply Key Generation
In order to authenticate the user, the client and KDC need to
generate three 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 Server Key to be used by the KDC to encrypt and by the client
to decrypt the encData value in the PA-OTP-CONFIRM.
o The Reply Key will be used in the standard manner by the KDC to
encrypt data in the AS-REP.
The method used to generate the three keys will depend on the OTP
algorithm.
o If the OTP value is included in the otp-value of the PA-OTP-
REQUEST then all three keys SHALL be the same as the Armor Key
(defined in [ZhHa07]).
o If the OTP value is not included in the otp-value of the PA-OTP-
REQUEST then the three keys SHALL be derived from the Armor Key
and the OTP value as described below.
If the OTP value is not included in the client response, then the
Reply Key SHALL be generated using the KRB_FX_CF2 algorithm from
[ZhHa07]
ClientKey = KRB_FX_CF2(K1, K2, O1, O2)
ServerKey = KRB_FX_CF2(K1, K2, O3, O4)
ReplyKey = KRB_FX_CF2(K1, K2, O5, O6)
The first input keys, K1, shall be the Armor Key. The second input
Richards Expires June 5, 2008 [Page 8]
Internet-Draft OTP Preauthentication December 2007
key, K2, shall be derived from the OTP value using string-to-key
(defined in [RFC3961]).
The octet string parameters, O1, O2, O3, O4, O5 and O6, shall be the
ASCII string "Combine1" to "Combine6". For example, O1 and O2 have
the following byte values:
{0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x31}
{0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x32}
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(sname|nonce|OTP)
Where:
* "|" denotes concatentation
* hash is the hash algorithm selected by the client.
* sname is the principal name of the KDC as included in the AS-
REQ.
* nonce is the random nonce value generated by the client to be
included in the PA-OTP-REQUEST.
* OTP is the 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 OTP value is binary and 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")
If the OTP value is not binary and the hash value is not used, then
K2 SHALL be derived by running the OTP value once through string-to-
key.
K2 = string-to-key(OTP||"Krb-preAuth")
Richards Expires June 5, 2008 [Page 9]
Internet-Draft OTP Preauthentication December 2007
The salt and additional parameters for string-to-key will be as
defined in section 3.1.3 of [RFC4120]. The symbol "||" denotes
string concatenation.
4. OTP Kerberos Message Types
4.1. PA-OTP-CHALLENGE
The PA_OTP_CHALLENGE padata type is sent by the KDC to the client in
the PA-DATA of a KRB_ERROR when pre-authentication using an OTP value
is required. The corresponding padata-value field contains the DER
encoding of a PA-OTP-CHALLENGE containing a server generated nonce
and information for the client on how to generate the OTP.
PA_OTP_CHALLENGE << TBA >>
PA-OTP-CHALLENGE ::= SEQUENCE {
flags OTPFlags,
nonce UInt32,
etype INTEGER,
supportedHashAlg SEQUENCE OF AlgorithmIdentifier
OPTIONAL,
iterationCount INTEGER OPTIONAL,
otp-challenge OCTET STRING (SIZE(8..MAX)) OPTIONAL,
otp-length [0] INTEGER OPTIONAL,
otp-service UTF8String OPTIONAL,
otp-keyID [1] OCTET STRING OPTIONAL,
otp-algID [2] INTEGER OPTIONAL,
...
}
OTPFlags ::= KerberosFlags
-- nextOTP (0)
flags
If the "nextOTP" flag is set then the OTP calculated SHALL be
based on the next token "state" rather than the current one. As
an example, for a time-based token, this means the next time slot.
For an event-based token, this could mean the next counter value,
if counter values are used.
nonce
A KDC-supplied nonce value to be encrypted by the client in the
PA-OTP-REQUEST.
Richards Expires June 5, 2008 [Page 10]
Internet-Draft OTP Preauthentication December 2007
etype
The encryption type to be used by the client to encrypt the nonce
in the PA-OTP-REQUEST.
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 SHA1 by both the client and KDC is REQUIRED. The
AlgorithmIdentifer selected by the client MUST be placed in the
hashAlg element of the PA-OTP-REQUEST.
iterationCount
This value contains the iteration count to use by the client when
hashing the OTP value and MUST be present if and only if
supportedHashAlg is present. The value MUST be returned in the
PA-OTP-REQUEST sent to the KDC. However, if the value of this
element does not conform to local policy on the client then
authentication MUST NOT proceed.
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 it is
present in, and SHOULD be eight octets or longer when 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
The otp-length is used by the KDC to specify the desired length of
the generated OTP.
otp-service
An identifier of the service supported by the KDC. This value can
be used by the client to locate the OTP key to use.
otp-keyID
The identifier of the OTP key to be used in the OTP calculation.
If this value is not present then the client SHOULD use other
values such as the otp-service and otp-algID to locate the
appropriate key.
Richards Expires June 5, 2008 [Page 11]
Internet-Draft OTP Preauthentication December 2007
otp-algID
The identifier of the algorithm to use when generating the OTP.
4.2. PA-OTP-REQUEST
The padata-type PA_OTP_RESPONSE 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 information on how the OTP was
generated. It may also,optionally, contain the generated OTP value.
PA_OTP_REQUEST << TBA >>
PA-OTP-REQUEST ::= SEQUENCE {
flags OTPFlags,
nonce UInt32,
encData EncryptedData,
-- PA-OTP-ENC-REQUEST or PA-ENC-TIMESTAMP
-- Key usage of KEY_USAGE_OTP_REQUEST
hashAlg AlgorithmIdentifier OPTIONAL,
iterationCount INTEGER OPTIONAL,
otp-value OCTET STRING OPTIONAL,
otp-challenge [0] OCTET STRING OPTIONAL,
otp-time KerberosTime OPTIONAL,
otp-counter [1] OCTET STRING OPTIONAL,
otp-format [2] OTPFormat OPTIONAL,
otp-keyID [3] OCTET STRING OPTIONAL,
otp-algID [4] INTEGER OPTIONAL,
...
}
KEY_USAGE_OTP_REQUEST << TBA >>
PA-OTP-ENC-REQUEST ::= SEQUENCE {
nonce OCTET STRING,
...
}
OTPFormat ::= INTEGER {
decimal(0),
hexadecimal(1),
alphanumeric(2),
binary(3)
Richards Expires June 5, 2008 [Page 12]
Internet-Draft OTP Preauthentication December 2007
}
flags
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.
nonce
A random nonce value generated by the client.
encData
If the PA-OTP-REQUEST is sent as a result of a PA-OTP_CHALLENGE
then this MUST contain the nonce from the challenge encrypted
under the Client Key. If no challenge was received then this MUST
contain a PA-ENC-TIMESTAMP encrypted under the Client Key.
hashAlg
This field MUST be present if a hash of the OTP value was used as
input to string-to-key (see Section 3.6) and 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 one of those specified in the
supportedHashAlg of the PA-OTP-CHALLENGE.
iterationCount
This field MUST be present if a hash of the OTP value was used as
input to string-to-key (see Section 3.6) and 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 be that specified in the PA-OTP-CHALLENGE.
otp-value
The generated OTP value. This value MUST NOT be present unless
allowed by the OTP algorithm profile.
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
Value used by the client to send the time used in the OTP
calculation.
Richards Expires June 5, 2008 [Page 13]
Internet-Draft OTP Preauthentication December 2007
otp-counter
The counter value used in the OTP calculation. Use of this
element is OPTIONAL but it MAY be used by a client to simplify the
OTP calculations of the KDC to contain the counter value as
reported by the OTP token.
otp-format
The format of the generated OTP.
otp-keyID
The identifier of the OTP key used.
otp-algID
The identifier of the algorithm to used to generate the OTP.
4.3. PA-OTP-CONFIRM
The padata-type PA_OTP_CONFIRM is returned by the KDC in the enc-
fast-rep of a PA-FX_FAST-REPLY in the KRB_AS_REP of the KDC. It is
used to return the client's nonce encrypted under the new Server Key
in order to confirm that the KDC has knowledge of this key.
The corresponding padata-value field contains the DER encoding of a
PA-OTP-CONFIRM.
PA_OTP_CONFIRM << TBA >>
PA-OTP-CONFIRM ::= SEQUENCE {
encData EncryptedData,
-- PA-OTP-ENC-CONFIRM
-- Key usage of KEY_USAGE_OTP_CONFIRM
...
}
KEY_USAGE_OTP_CONFIRM << TBA >>
PA-OTP-ENC-CONFIRM ::= SEQUENCE {
nonce OCTET STRING,
...
}
encData
The value of nonce from the corresponding PA-OTP-REQUEST encrypted
under the current Server Key.
Richards Expires June 5, 2008 [Page 14]
Internet-Draft OTP Preauthentication December 2007
4.4. PA-OTP-PIN-CHANGE
The padata-type PA_OTP_PIN_CHANGE is returned by the KDC in the This
pre-authentication type is returned by the KDC in the enc-fast-rep of
a PA-FX-FAST-REPLY in the KRB_AS_REP if the user must change their
PIN or if the user's PIN has been changed.
The corresponding padata-value field contains the DER encoding of a
PA-OTP-PIN-CHANGE.
PA_OTP_PIN_CHANGE << TBA >>
PA-OTP-PIN-CHANGE ::= SEQUENCE {
flags PinFlags,
pin UTF8String OPTIONAL,
minLength INTEGER OPTIONAL,
maxLength [1] INTEGER OPTIONAL,
...
}
PinFlags ::= KerberosFlags
-- systemSetPin (0)
If the "systemSetPin" flag is set then the user's PIN has been
changed and the new PIN value is contained in the pin field. The pin
field MUST therefore be present.
If the "systemSetPin" flag is not set then the user's PIN has not
been changed by the server but it MUST instead be changed by the user
using the PIN change service. Restrictions on the size of the PIN
MAY be given by the minLength and maxLength fields. If the pin field
is present then it contains a PIN value that MAY be used by the user
when changing the PIN. The KDC MAY only issue tickets for the PIN
change service until the PIN has been changed.
5. IANA Considerations
A registry may be required for the otp-AlgID values as introduced in
Section 4.1. 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
Richards Expires June 5, 2008 [Page 15]
Internet-Draft OTP Preauthentication December 2007
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.
Even though no such attacks are known at this point, the proposed
system uses the outer Armor Key in the derivation of the inner Client
and Server keys and so achieve crypto-binding to the outer channel.
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. Replay
The 2-pass version of the protocol does not involve a server nonce
and so the client instead encrypts a timestamp. To reduce the chance
of replay attacks, the KDC must check that the client time used in
such a request is later than that used in previous requests.
6.4. 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. Similarly, successful decryption of the
encrypted nonce by the client proves that the expected KDC replied.
The Reply Key is replaced by a key generated from the OTP and Armor
Key. This FAST factor therefore provides the following facilities:
client-authentication, replacing-reply-key and KDC-authentication.
7. References
7.1. Normative References
[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
Richards Expires June 5, 2008 [Page 16]
Internet-Draft OTP Preauthentication December 2007
Kerberos 5", RFC 3961, February 2005.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005.
[ZhHa07] Znu, L. and S. Hartman, "A generalized Framework for
Kerberos Pre-Authentication",
draft-ietf-krb-wg-preauth-framework-06 (work in progress),
March 2007.
7.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.
[RFC3244] Swift, M., Trostle, J., and J. Brezak, "Microsoft Windows
2000 Kerberos Change Password and Set Password Protocols",
RFC 3244, February 2002.
Appendix A. ASN.1 Module
OTPKerberos
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
KerberosTime, KerberosFlags, EncryptionKey, UInt32,
Int32, EncryptedData
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 3280.
Richards Expires June 5, 2008 [Page 17]
Internet-Draft OTP Preauthentication December 2007
PA-OTP-CHALLENGE ::= SEQUENCE {
flags OTPFlags,
nonce UInt32,
etype INTEGER,
supportedHashAlg SEQUENCE OF AlgorithmIdentifier
OPTIONAL,
iterationCount INTEGER OPTIONAL,
otp-challenge OCTET STRING (SIZE(8..MAX)) OPTIONAL,
otp-length [0] INTEGER OPTIONAL,
otp-service UTF8String OPTIONAL,
otp-keyID [1] OCTET STRING OPTIONAL,
otp-algID [2] INTEGER OPTIONAL,
...
}
OTPFlags ::= KerberosFlags
-- nextOTP (0)
PA-OTP-REQUEST ::= SEQUENCE {
flags OTPFlags,
nonce UInt32,
encData EncryptedData,
-- PA-OTP-ENC-REQUEST or PA-ENC-TIMESTAMP
-- Key usage of KEY_USAGE_OTP_REQUEST
hashAlg AlgorithmIdentifier OPTIONAL,
iterationCount INTEGER OPTIONAL,
otp-value OCTET STRING OPTIONAL,
otp-challenge [0] OCTET STRING (SIZE(8..MAX)) OPTIONAL,
otp-time KerberosTime OPTIONAL,
otp-counter [1] OCTET STRING OPTIONAL,
otp-format [2] OTPFormat OPTIONAL,
otp-keyID [3] OCTET STRING OPTIONAL,
otp-algID [4] INTEGER OPTIONAL,
...
}
PA-OTP-ENC-REQUEST ::= SEQUENCE {
nonce OCTET STRING,
...
}
OTPFormat ::= INTEGER {
decimal(0),
hexadecimal(1),
alphanumeric(2),
binary(3)
}
Richards Expires June 5, 2008 [Page 18]
Internet-Draft OTP Preauthentication December 2007
PA-OTP-CONFIRM ::= SEQUENCE {
encData EncryptedData,
-- PA-OTP-ENC-CONFIRM
-- Key usage of KEY_USAGE_OTP_CONFIRM
...
}
PA-OTP-ENC-CONFIRM ::= SEQUENCE {
nonce OCTET STRING,
...
}
PA-OTP-PIN-CHANGE ::= SEQUENCE {
flags PinFlags,
pin UTF8String OPTIONAL,
minLength INTEGER OPTIONAL,
maxLength [0] INTEGER OPTIONAL,
...
}
PinFlags ::= KerberosFlags
-- systemSetPin (0)
END
Author's Address
Gareth Richards
RSA, The Security Division of EMC
RSA House
Western Road
Bracknell, Berkshire RG12 1RT
UK
Email: grichards@rsa.com
Richards Expires June 5, 2008 [Page 19]
Internet-Draft OTP Preauthentication December 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Richards Expires June 5, 2008 [Page 20]
