draft-ietf-kitten-iakerb-02.txt   draft-ietf-kitten-iakerb-03.txt 
NETWORK WORKING GROUP B. Kaduk, Ed. NETWORK WORKING GROUP B. Kaduk, Ed.
Internet-Draft MIT KIT Internet-Draft Akamai
Updates: 4120,4121 (if approved) J. Schaad, Ed. Updates: 4120,4121 (if approved) J. Schaad, Ed.
Intended status: Standards Track Soaring Hawk Consulting Intended status: Standards Track Soaring Hawk Consulting
Expires: April 13, 2015 L. Zhu Expires: October 1, 2017 L. Zhu
Microsoft Corporation Microsoft Corporation
J. Altman J. Altman
Secure Endpoints Secure Endpoints
October 10, 2014 March 30, 2017
Initial and Pass Through Authentication Using Kerberos V5 and the GSS- Initial and Pass Through Authentication Using Kerberos V5 and the GSS-
API (IAKERB) API (IAKERB)
draft-ietf-kitten-iakerb-02 draft-ietf-kitten-iakerb-03
Abstract Abstract
This document defines extensions to the Kerberos protocol and the This document defines extensions to the Kerberos protocol and the
GSS-API Kerberos mechanism that enable a GSS-API Kerberos client to GSS-API Kerberos mechanism that enable a GSS-API Kerberos client to
exchange messages with the KDC by using the GSS-API acceptor as a exchange messages with the KDC by using the GSS-API acceptor as a
proxy, encapsulating the Kerberos messages inside GSS-API tokens. proxy, encapsulating the Kerberos messages inside GSS-API tokens.
With these extensions a client can obtain Kerberos tickets for With these extensions a client can obtain Kerberos tickets for
services where the KDC is not accessible to the client, but is services where the KDC is not accessible to the client, but is
accessible to the application server. accessible to the application server.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 April 13, 2015. This Internet-Draft will expire on October 1, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2017 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 47 skipping to change at page 2, line 47
work if the client does not have access to the KDC. For example, in work if the client does not have access to the KDC. For example, in
remote access scenarios, the client must initially authenticate to an remote access scenarios, the client must initially authenticate to an
access point in order to gain full access to the network. Here the access point in order to gain full access to the network. Here the
client may be unable to directly contact the KDC either because it client may be unable to directly contact the KDC either because it
does not have an IP address, or the access point packet filter does does not have an IP address, or the access point packet filter does
not allow the client to send packets to the Internet before it not allow the client to send packets to the Internet before it
authenticates to the access point. The Initial and Pass Through authenticates to the access point. The Initial and Pass Through
Authentication Using Kerberos (IAKERB) mechanism allows for the use Authentication Using Kerberos (IAKERB) mechanism allows for the use
of Kerberos in such scenarios where the client is unable to directly of Kerberos in such scenarios where the client is unable to directly
contact the KDC, by using the service to pass messages between the contact the KDC, by using the service to pass messages between the
client and the KDC. This allows the client to obtain tickts from the client and the KDC. This allows the client to obtain tickets from
KDC and present them to the service, as in normal Kerberos operation. the KDC and present them to the service, as in normal Kerberos
operation.
Recent advancements in extending Kerberos permit Kerberos Recent advancements in extending Kerberos permit Kerberos
authentication to complete with the assistance of a proxy. The authentication to complete with the assistance of a proxy. The
Kerberos [RFC4120] pre-authentication framework [RFC6113] prevents Kerberos [RFC4120] pre-authentication framework [RFC6113] prevents
the exposure of weak client keys over the open network. The Kerberos the exposure of weak client keys over the open network. The Kerberos
support of anonymity [RFC6112] provides for privacy and further support of anonymity [RFC6112] provides for privacy and further
complicates traffic analysis. The kdc-referrals option defined in complicates traffic analysis. The kdc-referrals option defined in
[RFC6113] may reduce the number of messages exchanged while obtaining [RFC6113] may reduce the number of messages exchanged while obtaining
a ticket to exactly two even in cross-realm authentications. a ticket to exactly two even in cross-realm authentications.
skipping to change at page 4, line 39 skipping to change at page 4, line 40
Token TOK_ID Value in Hex Token TOK_ID Value in Hex
-------------------------------------- --------------------------------------
IAKERB_PROXY 05 01 IAKERB_PROXY 05 01
The content of the IAKERB_PROXY message is defined as an IAKERB- The content of the IAKERB_PROXY message is defined as an IAKERB-
HEADER structure immediately followed by a Kerberos message, which is HEADER structure immediately followed by a Kerberos message, which is
optional. The Kerberos message can be an AS-REQ, an AS-REP, a TGS- optional. The Kerberos message can be an AS-REQ, an AS-REP, a TGS-
REQ, a TGS-REP, or a KRB-ERROR as defined in [RFC4120]. REQ, a TGS-REP, or a KRB-ERROR as defined in [RFC4120].
IAKERB-HEADER ::= SEQUENCE { IAKERB-HEADER ::= SEQUENCE {
-- Yes, the tags start at 1, not 0, which would be -- Note that the tag numbers start at 1, not 0, which would
-- more conventional for Kerberos. -- be more conventional for Kerberos.
target-realm [1] UTF8String, target-realm [1] UTF8String,
-- The name of the target realm. -- The name of the target realm.
cookie [2] OCTET STRING OPTIONAL, cookie [2] OCTET STRING OPTIONAL,
-- Opaque data, if sent by the server, -- Opaque data, if sent by the server,
-- MUST be copied by the client verbatim into -- MUST be copied by the client verbatim into
-- the next IAKRB_PROXY message. -- the next IAKRB_PROXY message.
... ...
} }
The IAKERB-HEADER structure and all the Kerberos messages MUST be The IAKERB-HEADER structure and all the Kerberos messages MUST be
encoded using Abstract Syntax Notation One (ASN.1) Distinguished encoded using Abstract Syntax Notation One (ASN.1) Distinguished
Encoding Rules (DER) [CCITT.X680.2002] [CCITT.X690.2002]. Encoding Rules (DER) [CCITT.X680.2002] [CCITT.X690.2002].
The client fills out the IAKERB-HEADER structure as follows: the The client fills out the IAKERB-HEADER structure as follows: the
target-realm contains the realm name the ticket request is addressed target-realm contains the realm name the ticket request is addressed
to. In the initial message from the client, the cookie field is to. In the initial message from the client, the cookie field is
absent. The client MAY send a completely empty IAKERB_PROXY message absent. The client MAY send a completely empty IAKERB_PROXY message
(consisting solely of the octets 05 01 and an IAKERB_HEADER with (consisting solely of the octets 05 01 and an IAKERB_HEADER with
skipping to change at page 7, line 25 skipping to change at page 7, line 25
Kerberos acceptor, it always has an associated Kerberos realm. Kerberos acceptor, it always has an associated Kerberos realm.
4. Finish Message 4. Finish Message
For implementations conforming to this specification, the For implementations conforming to this specification, the
authenticator subkey in the AP-REQ MUST alway be present, and the authenticator subkey in the AP-REQ MUST alway be present, and the
Exts field in the GSS-API authenticator [RFC6542] MUST contain an Exts field in the GSS-API authenticator [RFC6542] MUST contain an
extension of type GSS_EXTS_FINISHED with extension data containing extension of type GSS_EXTS_FINISHED with extension data containing
the ASN.1 DER encoding of the structure KRB-FINISHED. the ASN.1 DER encoding of the structure KRB-FINISHED.
GSS_EXTS_FINISHED 2 GSS_EXTS_FINISHED 2
--- Data type for the IAKERB checksum. --- Data type for the IAKERB checksum.
KRB-FINISHED ::= { KRB-FINISHED ::= {
-- Yes, the tags start at 1, not 0, which would be -- Note that the tag numbers start at 1, not 0, which would be
-- more conventional for Kerberos. -- more conventional for Kerberos.
gss-mic [1] Checksum, gss-mic [1] Checksum,
-- Contains the checksum [RFC3961] of the GSS-API tokens -- Contains the checksum [RFC3961] of the GSS-API tokens
-- exchanged between the initiator and the acceptor, -- exchanged between the initiator and the acceptor,
-- and prior to the containing AP_REQ GSS-API token. -- and prior to the containing AP_REQ GSS-API token.
-- The checksum is performed over the GSS-API tokens -- The checksum is performed over the GSS-API tokens
-- exactly as they were transmitted and received, -- exactly as they were transmitted and received,
-- in the order that the tokens were sent. -- in the order that the tokens were sent.
... ...
} }
The gss-mic field in the KRB-FINISHED structure contains a Kerberos The gss-mic field in the KRB-FINISHED structure contains a Kerberos
checksum [RFC3961] of all the preceding context tokens of this GSS- checksum [RFC3961] of all the preceding context tokens of this GSS-
API context (including the generic token framing of the GSSAPI-Token API context (including the generic token framing of the GSSAPI-Token
type from [RFC4121]), concatenated in chronological order (note that type from [RFC4121]), concatenated in chronological order (note that
GSS-API context token exchanges are synchronous). The checksum type GSS-API context token exchanges are synchronous). The checksum type
is the required checksum type of the enctype of the subkey in the is the required checksum type of the enctype of the subkey in the
authenticator, the protocol key for the checksum operation is the authenticator, the protocol key for the checksum operation is the
authenticator subkey, and the key usage number is KEY_USAGE_FINISHED. authenticator subkey, and the key usage number is KEY_USAGE_FINISHED.
skipping to change at page 10, line 46 skipping to change at page 10, line 46
X.680, July 2002. X.680, July 2002.
[CCITT.X690.2002] [CCITT.X690.2002]
International Telephone and Telegraph Consultative International Telephone and Telegraph Consultative
Committee, "ASN.1 encoding rules: Specification of basic Committee, "ASN.1 encoding rules: Specification of basic
encoding Rules (BER), Canonical encoding rules (CER) and encoding Rules (BER), Canonical encoding rules (CER) and
Distinguished encoding rules (DER)", CCITT Recommendation Distinguished encoding rules (DER)", CCITT Recommendation
X.690, July 2002. X.690, July 2002.
[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, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2743] Linn, J., "Generic Security Service Application Program [RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000. Interface Version 2, Update 1", RFC 2743,
DOI 10.17487/RFC2743, January 2000,
<http://www.rfc-editor.org/info/rfc2743>.
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
Kerberos 5", RFC 3961, February 2005. Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February
2005, <http://www.rfc-editor.org/info/rfc3961>.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120, Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005. DOI 10.17487/RFC4120, July 2005,
<http://www.rfc-editor.org/info/rfc4120>.
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
Version 5 Generic Security Service Application Program Version 5 Generic Security Service Application Program
Interface (GSS-API) Mechanism: Version 2", RFC 4121, July Interface (GSS-API) Mechanism: Version 2", RFC 4121,
2005. DOI 10.17487/RFC4121, July 2005,
<http://www.rfc-editor.org/info/rfc4121>.
[RFC6542] Emery, S., "Kerberos Version 5 Generic Security Service [RFC6542] Emery, S., "Kerberos Version 5 Generic Security Service
Application Program Interface (GSS-API) Channel Binding Application Program Interface (GSS-API) Channel Binding
Hash Agility", RFC 6542, March 2012. Hash Agility", RFC 6542, DOI 10.17487/RFC6542, March 2012,
<http://www.rfc-editor.org/info/rfc6542>.
10.2. Informative references 10.2. Informative references
[RFC6112] Zhu, L., Leach, P., and S. Hartman, "Anonymity Support for [RFC6112] Zhu, L., Leach, P., and S. Hartman, "Anonymity Support for
Kerberos", RFC 6112, April 2011. Kerberos", RFC 6112, DOI 10.17487/RFC6112, April 2011,
<http://www.rfc-editor.org/info/rfc6112>.
[RFC6113] Hartman, S. and L. Zhu, "A Generalized Framework for [RFC6113] Hartman, S. and L. Zhu, "A Generalized Framework for
Kerberos Pre-Authentication", RFC 6113, April 2011. Kerberos Pre-Authentication", RFC 6113,
DOI 10.17487/RFC6113, April 2011,
<http://www.rfc-editor.org/info/rfc6113>.
[RFC6806] Hartman, S., Raeburn, K., and L. Zhu, "Kerberos Principal [RFC6806] Hartman, S., Ed., Raeburn, K., and L. Zhu, "Kerberos
Name Canonicalization and Cross-Realm Referrals", RFC Principal Name Canonicalization and Cross-Realm
6806, November 2012. Referrals", RFC 6806, DOI 10.17487/RFC6806, November 2012,
<http://www.rfc-editor.org/info/rfc6806>.
Appendix A. Interoperate with Previous MIT version Appendix A. Interoperate with Previous MIT version
MIT implemented an early draft version of this document. This MIT implemented an early draft version of this document. This
section gives a method for detecting and interoperating with that section gives a method for detecting and interoperating with that
version. version.
Initiators behave as follows: Initiators behave as follows:
o If the first acceptor token begins with generic token framing as o If the first acceptor token begins with generic token framing as
skipping to change at page 12, line 20 skipping to change at page 12, line 36
defined in [RFC4121]. defined in [RFC4121].
o If the AP-REQ authenticator contains an extension of type 1 o If the AP-REQ authenticator contains an extension of type 1
containing a KRB-FINISHED message, then process the extension as containing a KRB-FINISHED message, then process the extension as
if it were of type GSS_EXTS_FINISHED, except with a key usage of if it were of type GSS_EXTS_FINISHED, except with a key usage of
KEY_USAGE_IAKERB_FINISHED (42) instead of KEY_USAGE_FINISHED (41). KEY_USAGE_IAKERB_FINISHED (42) instead of KEY_USAGE_FINISHED (41).
Authors' Addresses Authors' Addresses
Benjamin Kaduk (editor) Benjamin Kaduk (editor)
MIT KIT Akamai
Email: kaduk@mit.edu Email: kaduk@mit.edu
Jim Schaad (editor) Jim Schaad (editor)
Soaring Hawk Consulting Soaring Hawk Consulting
Email: ietf@augustcellars.com Email: ietf@augustcellars.com
Larry Zhu Larry Zhu
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
US US
Email: lzhu@microsoft.com Email: lzhu@microsoft.com
Jeffery Altman Jeffery Altman
Secure Endpoints Secure Endpoints
 End of changes. 21 change blocks. 
47 lines changed or deleted 59 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/