One document matched: draft-ietf-krb-wg-otp-preauth-00.txt
Network Working Group G. Richards
Internet-Draft RSA, The Security Division of EMC
Intended status: Standards Track October 5, 2007
Expires: April 7, 2008
OTP Preauthentication
draft-ietf-krb-wg-otp-preauth-00
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 April 7, 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 April 7, 2008 [Page 1]
Internet-Draft OTP Preauthentication October 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Usage Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Pre-Authentication . . . . . . . . . . . . . . . . . . . . 4
2.2. PIN Change . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Re-Synchronization . . . . . . . . . . . . . . . . . . . . 5
3. Pre-Authentication Protocol Details . . . . . . . . . . . . . 5
3.1. Initial Client Request . . . . . . . . . . . . . . . . . . 5
3.2. KDC Challenge . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Client Response . . . . . . . . . . . . . . . . . . . . . 5
3.4. Verifying the pre-auth Data . . . . . . . . . . . . . . . 6
3.5. Confirming the Reply Key Change . . . . . . . . . . . . . 7
3.6. Reply Key Generation . . . . . . . . . . . . . . . . . . . 7
4. OTP Kerberos Message Types . . . . . . . . . . . . . . . . . . 8
4.1. PA-OTP-CHALLENGE . . . . . . . . . . . . . . . . . . . . . 8
4.2. PA-OTP-REQUEST . . . . . . . . . . . . . . . . . . . . . . 10
4.3. PA-OTP-CONFIRM . . . . . . . . . . . . . . . . . . . . . . 11
4.4. PA-OTP-PIN-CHANGE . . . . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6.1. Active attacks . . . . . . . . . . . . . . . . . . . . . . 13
6.1.1. Man-in-the-Middle . . . . . . . . . . . . . . . . . . 13
6.1.2. Reflection . . . . . . . . . . . . . . . . . . . . . . 13
6.1.3. Replay . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1.4. Passive attacks . . . . . . . . . . . . . . . . . . . 13
6.2. FAST Facilities . . . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17
Richards Expires April 7, 2008 [Page 2]
Internet-Draft OTP Preauthentication October 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.
This FAST factor provides the following facilities: 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
response , the KDC sends with a challenge containing random nonce and
details on how the OTP is to be generated as pre-auth data within a
KRB-ERROR. The client generates the OTP value, the Reply Key and a
Client and Server key and uses the Client Key to encrypt the nonce
value. This encrypted value is then sent to the KDC along with a
client generated nonce and information on the generated OTP as pre-
authentication data encrypted within the armored data of a PA-FX-
FAST-REQUEST contained within a second AS-REQ. The KDC then
generates the same keys, verifies the pre-authentication data by
decrypting the nonce and confirms knowledge of the Reply Key by
sending a response to the client containing the client's nonce
encrypted using the Server Key encrypted within the armored data of a
PA-FX-FAST-RESPONSE contained within an AS-REP.
In the 2-pass variant, the client generates the OTP and keys as in
the 4-pass system but includes the PA-FX-FAST-REQUEST in the initial
AS-REQ sent to the KDC. This system 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.
Depending on OTP algorithm used, the OTP value is either used in the
generation of the Reply Key or is sent to the KDC along with the
encrypted nonce.
This proposal is partially based upon previous work on integrating
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].
Richards Expires April 7, 2008 [Page 3]
Internet-Draft OTP Preauthentication October 2007
<< This is an early draft of this document and so is liable to change
significantly. >>
2. Usage Overview
2.1. Pre-Authentication
The approach uses pre-authentication data in KRB_AS_REQ, KRB_AS_REP
and KRB_ERROR messages. 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 and
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 key to encrypt KDC's nonce and a key to
decrypt the KDC's reply. As described in Section 3.6, these keys
will be generated from the Anchor Key and depending on the type of
OTP, from the OTP value.
The encrypted KDC nonce and the client nonce 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.
The KDC then uses this information to generate the same keys as the
client, allowing it to verify the pre-authentication by decrypting
the encrypted nonce sent by the client. 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, user PIN change shall be handled by a PIN change
service supporting the ChangePasswdData in a KRB_AP_REQ as described
Richards Expires April 7, 2008 [Page 4]
Internet-Draft OTP Preauthentication October 2007
in [RFC3244]. If such a user PIN change is required then the KDC
SHALL return a TGT in the KRB_AS_REP but it is RECOMMENDED that it
only issues tickets 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 loose 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. The setting of
this flag will cause the client to re-try the authentication using
the OTP for the next token "state".
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.
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. It MAY also contain
information on how the OTP value is to be generated.
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 Anchor Key.
Richards Expires April 7, 2008 [Page 5]
Internet-Draft OTP Preauthentication October 2007
In order to generate its response, the client 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.
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.
The client MUST generate three keys as described in Section 3.6. 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
SHALL use any OTP information in the PA-OTP-REQUEST to obtain the OTP
value in order to generate the to generate the keys.
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
process will be the same as with standard encrypted timestamp pre-
authentication [RFC4120]
Richards Expires April 7, 2008 [Page 6]
Internet-Draft OTP Preauthentication October 2007
3.5. Confirming the Reply Key Change
In order to support mutual authentication, the KDC SHALL respond to
the clients PA-OTP-REQUEST by including in the AS-REP, the client
nonce from PA-OTP-REQUEST encrypted under the 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 Anchor 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 Anchor Key.
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 Anchor 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 Anchor Key, AK. The second
input key, K2, shall be derived from the OTP value using string-to-
key or random-to-key (both defined in [RFC3961]).
Richards Expires April 7, 2008 [Page 7]
Internet-Draft OTP Preauthentication October 2007
o If the OTP value is binary, then K2 SHALL be derived by running
the OTP value once through random-to-key.
K2 = random-to-key(OTP||"Krb-preAuth")
o If the OTP value is not binary, then K2 SHALL be derived by
running the OTP value once through string-to-key.
K2 = string-to-key(OTP||"Krb-preAuth")
The salt and additional parameters for string-to-key will be as
defined in section 3.1.3 of [RFC4120].
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}
4. OTP Kerberos Message Types
4.1. PA-OTP-CHALLENGE
The padata type pa-otp-challenge sent by the KDC to the client in the
PA-DATA 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,
otp-challenge OCTET STRING OPTIONAL,
otp-length INTEGER OPTIONAL,
otp-service UTF8String OPTIONAL,
otp-keyID [0] OCTET STRING OPTIONAL,
otp-algID [1] INTEGER OPTIONAL,
...
}
OTPFlags ::= KerberosFlags
-- nextOTP (0)
Richards Expires April 7, 2008 [Page 8]
Internet-Draft OTP Preauthentication October 2007
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.
etype
The encryption type to be used by the client to encrypt the nonce
in the PA-OTP-REQUEST.
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 information such as the shared
secret value and 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.
otp-algID
The identifier of the algorithm to use when generating the OTP.
<<TBD: Should a checksum be added to allow the client to verify the
challenge?>>
Richards Expires April 7, 2008 [Page 9]
Internet-Draft OTP Preauthentication October 2007
4.2. PA-OTP-REQUEST
The padata-type pa-otp-response sent by the client to the KDC in the
KrbFastReq padata of a PA-FX-FAST-REQUEST 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-response << TBA >>
PA-OTP-REQUEST ::= SEQUENCE {
flags OTPFlags,
nonce UInt32,
encData EncryptedData,
-- PA-OTP-ENC-REQUEST or PA-ENC-TIMESTAMP
-- Key usage of << TBD >>
otp-value OCTET STRING OPTIONAL,
otp-challenge [0] OCTET STRING OPTIONAL,
otp-time KerberosTime OPTIONAL,
otp-counter [1] OCTET STRING OPTIONAL,
otp-format OTPFormat OPTIONAL,
otp-keyID [2] OCTET STRING OPTIONAL,
otp-algID [3] INTEGER OPTIONAL,
...
}
PA-OTP-ENC-REQUEST ::= SEQUENCE {
nonce OCTET STRING,
...
}
OTPFormat ::= INTEGER {
decimal(0),
hexadecimal(1),
alphanumeric(2),
binary(3)
}
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.
Richards Expires April 7, 2008 [Page 10]
Internet-Draft OTP Preauthentication October 2007
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.
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.
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
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 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.
Richards Expires April 7, 2008 [Page 11]
Internet-Draft OTP Preauthentication October 2007
pa-otp-confirm << TBA >>
PA-OTP-CONFIRM ::= SEQUENCE {
encData EncryptedData,
-- PA-OTP-ENC-CONFIRM
-- Key usage of << TBD >>
...
}
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.
4.4. PA-OTP-PIN-CHANGE
This pre-authentication type 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.
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.
Richards Expires April 7, 2008 [Page 12]
Internet-Draft OTP Preauthentication October 2007
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. Active attacks
6.1.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.
Even though no such attacks are known at this point, the proposed
system uses the outer, Anchor, Key in the derivation of the inner
Client and Server keys and so achieve crypto-binding to the outer
channel.
6.1.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.1.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.1.4. Passive attacks
<< TBD >>
6.2. 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
Richards Expires April 7, 2008 [Page 13]
Internet-Draft OTP Preauthentication October 2007
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
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3244] Swift, M., Trostle, J., and J. Brezak, "Microsoft Windows
2000 Kerberos Change Password and Set Password Protocols",
RFC 3244, February 2002.
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
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-kerb-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.
Appendix A. ASN.1 Module
OTPKerberos
DEFINITIONS IMPLICIT TAGS ::=
Richards Expires April 7, 2008 [Page 14]
Internet-Draft OTP Preauthentication October 2007
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.
PA-OTP-CHALLENGE ::= SEQUENCE {
flags OTPFlags,
nonce UInt32,
etype INTEGER,
otp-challenge OCTET STRING OPTIONAL,
otp-length INTEGER OPTIONAL,
otp-service UTF8String OPTIONAL,
otp-keyID [0] OCTET STRING OPTIONAL,
otp-algID [1] 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 << TBD >>
otp-value OCTET STRING OPTIONAL,
otp-challenge [0] OCTET STRING OPTIONAL,
otp-time KerberosTime OPTIONAL,
otp-counter [1] OCTET STRING OPTIONAL,
otp-format OTPFormat OPTIONAL,
otp-keyID [2] OCTET STRING OPTIONAL,
otp-algID [3] INTEGER OPTIONAL,
...
}
PA-OTP-ENC-REQUEST ::= SEQUENCE {
nonce OCTET STRING,
...
}
OTPFormat ::= INTEGER {
decimal(0),
Richards Expires April 7, 2008 [Page 15]
Internet-Draft OTP Preauthentication October 2007
hexadecimal(1),
alphanumeric(2),
binary(3)
}
PA-OTP-CONFIRM ::= SEQUENCE {
encData EncryptedData,
-- PA-OTP-ENC-CONFIRM
-- Key usage of << TBD >>
...
}
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 April 7, 2008 [Page 16]
Internet-Draft OTP Preauthentication October 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 April 7, 2008 [Page 17]
| PAFTECH AB 2003-2026 | 2026-04-23 13:06:58 |