draft-ietf-kitten-pkinit-freshness-06.txt   draft-ietf-kitten-pkinit-freshness-07.txt 
Kitten Working Group M. Short, Ed. Kitten Working Group M. Short, Ed.
Internet-Draft S. Moore Internet-Draft S. Moore
Intended status: Standards Track P. Miller Intended status: Standards Track P. Miller
Expires: October 10, 2016 Microsoft Corporation Expires: November 24, 2016 Microsoft Corporation
April 8, 2016 May 23, 2016
Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)
Freshness Extension Freshness Extension
draft-ietf-kitten-pkinit-freshness-06 draft-ietf-kitten-pkinit-freshness-07
Abstract Abstract
This document describes how to further extend the Public Key This document describes how to further extend the Public Key
Cryptography for Initial Authentication in Kerberos (PKINIT) Cryptography for Initial Authentication in Kerberos (PKINIT)
extension [RFC4556] to exchange an opaque data blob that a KDC can extension [RFC4556] to exchange an opaque data blob that a KDC can
validate to ensure that the client is currently in possession of the validate to ensure that the client is currently in possession of the
private key during a PKINIT AS exchange. private key during a PKINIT AS exchange.
Status of This Memo Status of This Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 10, 2016. This Internet-Draft will expire on November 24, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 51 skipping to change at page 3, line 51
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Message Exchanges 2. Message Exchanges
The following summarizes the message flow with extensions to The following summarizes the message flow with extensions to
[RFC4120] and [RFC4556] required to support a KDC-provided freshness [RFC4120] and [RFC4556] required to support a KDC-provided freshness
token during the initial request for a ticket: token during the initial request for a ticket:
1. The client generates a KRB_AS_REQ as specified in Section 2.9.3 1. The client generates a KRB_AS_REQ as specified in Section 2.9.3
[RFC4120] that contains no PA_PK_AS_REQ and includes a freshness of [RFC4120] that contains no PA_PK_AS_REQ and includes a
token request. freshness token request.
2. The KDC generates a KRB_ERROR as specified in Section 3.1.3 of 2. The KDC generates a KRB_ERROR as specified in Section 3.1.3 of
[RFC4120] providing a freshness token. [RFC4120] providing a freshness token.
3. The client receives the error as specified in Section 3.1.4 of 3. The client receives the error as specified in Section 3.1.4 of
[RFC4120], extracts the freshness token, and includes it as part [RFC4120], extracts the freshness token, and includes it as part
of the KRB_AS_REQ as specified in [RFC4120] and [RFC4556]. of the KRB_AS_REQ as specified in [RFC4120] and [RFC4556].
4. The KDC receives and validates the KRB_AS_REQ as specified in 4. The KDC receives and validates the KRB_AS_REQ as specified in
Section 3.2.2 [RFC4556], then additionally validates the Section 3.2.2 of [RFC4556], then additionally validates the
freshness token. freshness token.
5. The KDC and client continue as specified in [RFC4120] and 5. The KDC and client continue as specified in [RFC4120] and
[RFC4556]. [RFC4556].
2.1. Generation of KRB_AS_REQ Message 2.1. Generation of KRB_AS_REQ Message
The client indicates support of freshness tokens by adding a padata The client indicates support of freshness tokens by adding a padata
element with padata-type PA_AS_FRESHNESS and padata-value of an empty element with padata-type PA_AS_FRESHNESS and padata-value of an empty
octet string. octet string.
skipping to change at page 4, line 39 skipping to change at page 4, line 39
with padata-type PA_AS_FRESHNESS and padata-value of the freshness with padata-type PA_AS_FRESHNESS and padata-value of the freshness
token to the METHOD-DATA object. token to the METHOD-DATA object.
2.3. Generation of KRB_AS_REQ Message 2.3. Generation of KRB_AS_REQ Message
After the client receives the KRB-ERROR message containing a After the client receives the KRB-ERROR message containing a
freshness token, it extracts the PA_AS_FRESHNESS padata-value field freshness token, it extracts the PA_AS_FRESHNESS padata-value field
of the PA-DATA structure as an opaque data blob. The PA_AS_FRESHNESS of the PA-DATA structure as an opaque data blob. The PA_AS_FRESHNESS
padata-value field of the PA-DATA structure SHALL then be added as an padata-value field of the PA-DATA structure SHALL then be added as an
opaque blob in the freshnessToken field when the client generates the opaque blob in the freshnessToken field when the client generates the
PKAuthenticator for the PA_PK_AS_REQ message. This ensures that the PKAuthenticator specified in Section 4 for the PA_PK_AS_REQ message.
freshness token value will be included in the signed data portion of This ensures that the freshness token value will be included in the
the KRB_AS_REQ value. signed data portion of the KRB_AS_REQ value.
2.4. Receipt of KRB_AS_REQ Message 2.4. Receipt of KRB_AS_REQ Message
If the realm requires freshness and the PA_PK_AS_REQ message does not If the realm requires freshness and the PA_PK_AS_REQ message does not
contain the freshness token, the KDC MUST return a KRB_ERROR contain the freshness token, the KDC MUST return a KRB_ERROR
[RFC4120] message with the error-code KDC_ERR_PREAUTH_FAILED [RFC4120] message with the error-code KDC_ERR_PREAUTH_FAILED
[RFC4120] with a padata element with padata-type PA_AS_FRESHNESS and [RFC4120] with a padata element with padata-type PA_AS_FRESHNESS and
padata-value of the freshness token to the METHOD-DATA object. padata-value of the freshness token to the METHOD-DATA object.
When the PA_PK_AS_REQ message contains a freshness token, after When the PA_PK_AS_REQ message contains a freshness token, after
skipping to change at page 5, line 26 skipping to change at page 5, line 26
includes a freshness token, it SHOULD retry using the new freshness includes a freshness token, it SHOULD retry using the new freshness
token. token.
3. PreAuthentication Data Types 3. PreAuthentication Data Types
The following are the new PreAuthentication data types: The following are the new PreAuthentication data types:
+----------------------+-------------------+ +----------------------+-------------------+
| Padata and Data Type | Padata-type Value | | Padata and Data Type | Padata-type Value |
+----------------------+-------------------+ +----------------------+-------------------+
| PA_AS_FRESHNESS | TBD | | PA_AS_FRESHNESS | 150 |
+----------------------+-------------------+ +----------------------+-------------------+
4. Extended PKAuthenticator 4. Extended PKAuthenticator
The PKAuthenticator structure specified in Section 3.2.1 [RFC4556] is The PKAuthenticator structure specified in Section 3.2.1 of [RFC4556]
extended to include a new freshnessToken as follows: is extended to include a new freshnessToken as follows:
PKAuthenticator ::= SEQUENCE { PKAuthenticator ::= SEQUENCE {
cusec [0] INTEGER (0..999999), cusec [0] INTEGER (0..999999),
ctime [1] KerberosTime, ctime [1] KerberosTime,
-- cusec and ctime are used as in [RFC4120], for -- cusec and ctime are used as in [RFC4120], for
-- replay prevention. -- replay prevention.
nonce [2] INTEGER (0..4294967295), nonce [2] INTEGER (0..4294967295),
-- Chosen randomly; this nonce does not need to -- Chosen randomly; this nonce does not need to
-- match with the nonce in the KDC-REQ-BODY. -- match with the nonce in the KDC-REQ-BODY.
paChecksum [3] OCTET STRING OPTIONAL, paChecksum [3] OCTET STRING OPTIONAL,
skipping to change at page 6, line 45 skipping to change at page 6, line 45
6. IANA Considerations 6. IANA Considerations
IANA is requested to assign numbers for PA_AS_FRESHNESS listed in the IANA is requested to assign numbers for PA_AS_FRESHNESS listed in the
Kerberos Parameters registry Pre-authentication and Typed Data as Kerberos Parameters registry Pre-authentication and Typed Data as
follows: follows:
+------+-----------------+------------+ +------+-----------------+------------+
| Type | Value | Reference | | Type | Value | Reference |
+------+-----------------+------------+ +------+-----------------+------------+
| TBD | PA_AS_FRESHNESS | [This RFC] | | 150 | PA_AS_FRESHNESS | [This RFC] |
+------+-----------------+------------+ +------+-----------------+------------+
7. Security Considerations 7. Security Considerations
The freshness token SHOULD include signing, encrypting or sealing The freshness token SHOULD include signing, encrypting or sealing
data from the KDC to determine authenticity and prevent tampering. data from the KDC to determine authenticity and prevent tampering.
Freshness tokens serve to guarantee that the client had the key when Freshness tokens serve to guarantee that the client had the key when
constructing the AS-REQ. They are not required to be single use constructing the AS-REQ. They are not required to be single use
tokens or bound to specific AS exchanges. Part of the reason the tokens or bound to specific AS exchanges. Part of the reason the
token is opaque is to allow KDC implementers the freedom to add token is opaque is to allow KDC implementers the freedom to add
additional functionality as long as the "freshness" guarantee additional functionality as long as the "freshness" guarantee
remains. remains.
8. Interoperability Considerations 8. Interoperability Considerations
Since the client treats the KDC provided data blob as opaque, Since the client treats the KDC-provided data blob as opaque,
changing the contents will not impact existing clients. Thus changing the contents will not impact existing clients. Thus
extensions to the freshness token do not impact client extensions to the freshness token do not impact client
interoperability. interoperability.
Clients SHOULD NOT reuse freshness tokens across multiple exchanges. Clients SHOULD NOT reuse freshness tokens across multiple exchanges.
There is no guarantee that a KDC will allow a once-valid token to be There is no guarantee that a KDC will allow a once-valid token to be
used again. Thus clients that do not retry with a new freshness used again. Thus clients that do not retry with a new freshness
token may not be compatible with KDCs depending on how they choose to token may not be compatible with KDCs, depending on how they choose
implement "freshness" validation. to implement freshness validation.
Since upgrading clients takes time, implementers may consider Since upgrading clients takes time, implementers may consider
allowing both freshness-token based exchanges as well as "legacy" allowing both freshness-token based exchanges and "legacy" exchanges
exchanges without use of freshness tokens. However, until freshness without use of freshness tokens. However, until freshness tokens are
tokens are required by the realm, existing risks of pre-generated required by the realm, the existing risks of pre-generated
PKAuthenticators will remain. PKAuthenticators will remain.
9. Normative References 9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
 End of changes. 12 change blocks. 
20 lines changed or deleted 20 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/