draft-ietf-kitten-iakerb-01.txt   draft-ietf-kitten-iakerb-02.txt 
NETWORK WORKING GROUP J. Schaad, Ed. NETWORK WORKING GROUP B. Kaduk, Ed.
Internet-Draft Soaring Hawk Consulting Internet-Draft MIT KIT
Updates: 4120 (if approved) L. Zhu Updates: 4120,4121 (if approved) J. Schaad, Ed.
Intended status: Standards Track Microsoft Corporation Intended status: Standards Track Soaring Hawk Consulting
Expires: August 18, 2014 J. Altman Expires: April 13, 2015 L. Zhu
Microsoft Corporation
J. Altman
Secure Endpoints Secure Endpoints
February 14, 2014 October 10, 2014
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-01 draft-ietf-kitten-iakerb-02
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 using the GSS-API acceptor as the exchange messages with the KDC by using the GSS-API acceptor as a
proxy, by 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.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 August 18, 2014. This Internet-Draft will expire on April 13, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 2, line 16 skipping to change at page 2, line 20
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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. GSS-API Encapsulation . . . . . . . . . . . . . . . . . . . . 3 3. GSS-API Encapsulation . . . . . . . . . . . . . . . . . . . . 3
4. Finish Message . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Enterprise principal names . . . . . . . . . . . . . . . 6
5. Addresses in Tickets . . . . . . . . . . . . . . . . . . . . 7 4. Finish Message . . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Addresses in Tickets . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Assigned Numbers . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9.2. Informative references . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
Appendix A. Interoperate with Previous MIT version . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 10.2. Informative references . . . . . . . . . . . . . . . . . 11
Appendix A. Interoperate with Previous MIT version . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
When authenticating using Kerberos V5, clients obtain tickets from a When authenticating using Kerberos V5, clients obtain tickets from a
KDC and present them to services. This model of operation cannot KDC and present them to services. This model of operation cannot
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. authenticates to the access point. The Initial and Pass Through
Authentication Using Kerberos (IAKERB) mechanism allows for the use
of Kerberos in such scenarios where the client is unable to directly
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
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.
Building upon these Kerberos extensions, this document extends Building upon these Kerberos extensions, this document extends
[RFC4120] and [RFC4121] such that the client can communicate with the [RFC4120] and [RFC4121] such that the client can communicate with the
KDC using a Generic Security Service Application Program Interface KDC using a Generic Security Service Application Program Interface
(GSS-API) [RFC2743] acceptor as the proxy. The GSS-API acceptor (GSS-API) [RFC2743] acceptor as a message-passing proxy. (This is
completely unrelated to the type of proxy specified in [RFC4120].)
The client acts as a GSS-API initiator, and the GSS-API acceptor
relays the KDC request and reply messages between the client and the relays the KDC request and reply messages between the client and the
KDC. The GSS-API acceptor, when relaying the Kerberos messages, is KDC, transitioning to normal [RFC4121] GSS-krb5 messages once the
called an IAKERB proxy. Consequently, IAKERB as defined in this client has obtained the necessary credentials. Consequently, IAKERB
document requires the use of GSS-API. as defined in this document requires the use of the GSS-API.
The GSS-API acceptor, when relaying these Kerberos messages, is
called an IAKERB proxy.
2. Conventions Used in This Document 2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"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 [RFC2119]. document are to be interpreted as described in [RFC2119].
3. GSS-API Encapsulation 3. GSS-API Encapsulation
The mechanism Objection Identifier (OID) for GSS-API IAKERB, in The GSS-API mechanism Objection Identifier (OID) for IAKERB is id-
accordance with the mechanism proposed by [RFC4178] for negotiating kerberos-iakerb:
protocol variations, is id-kerberos-iakerb:
id-kerberos-iakerb ::= id-kerberos-iakerb ::=
{ iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2) { iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2)
iakerb(5) } iakerb(5) }
All context establishment token of IAKERB MUST have the generic token All context establishment tokens of IAKERB MUST have the token
framing described in section 3.1 of [RFC2743] with the mechanism OID framing described in section 4.1 of [RFC4121] with the mechanism OID
being id-kerberos-iakerb. MIT implemented an earlier draft of this being id-kerberos-iakerb. MIT implemented an earlier draft of this
specification, details on how to inter operate with that specification; details on how to interoperate with that
implementation can be found in Appendix A. implementation can be found in Appendix A.
The client starts by constructing the ticket request, and if the The client starts by constructing a ticket request, as if it is being
ticket request is being made to the KDC, the client, instead of made directly to the KDC. Instead of contacting the KDC directly,
contacting the KDC directly, encapsulates the request message into the client encapsulates the request message into the output token of
the output token of the GSS_Init_security_context() call and returns the GSS_Init_security_context() call and returns
GSS_S_CONTINUE_NEEDED [RFC2743] indicating that at least one more GSS_S_CONTINUE_NEEDED [RFC2743], indicating that at least one more
token is required in order to establish the context. The output token is required in order to establish the context. The output
token is then passed for use as the input token to the token is then passed over the application protocol for use as the
GSS_Accept_sec_context() call in accordance with GSS-API. The GSS- input token to the GSS_Accept_sec_context() call in accordance with
API acceptor extracts the Kerberos request in the input token, GSS-API. The GSS-API acceptor extracts the Kerberos request from the
locates the target KDC, and sends the request on behalf of the input token, locates the target KDC, and sends the request on behalf
client. After receiving the KDC reply, the GSS-API acceptor then of the client. After receiving the KDC reply, the GSS-API acceptor
encapsulates the reply message into the output token of then encapsulates the reply message into the output token of
GSS_Accept_sec_context(). The GSS-API acceptor returns GSS_Accept_sec_context(). The GSS-API acceptor returns
GSS_S_CONTINUE_NEEDED [RFC2743] indicating that at least one more GSS_S_CONTINUE_NEEDED [RFC2743] indicating that at least one more
token is required in order to establish the context. The output token is required in order to establish the context. The output
token is passed to the initiator in accordance with GSS-API. token is passed to the initiator over the application protocol in
accordance with GSS-API.
Client <---------> IAKERB proxy <---------> KDC +--------+ +--------------+ +-----+
| | --------> | | --------> | |
| Client | | IAKERB proxy | | KDC |
| | <-------- | | <-------- | |
+--------+ +--------------+ +-----+
The innerToken described in section 3.1 of [RFC2743] and subsequent For all context tokens generated by the IAKERB mechanism, the
GSS-API mechanism tokens have the following formats: it starts with a innerToken described in section 4.1 of [RFC4121] has the following
two-octet token-identifier (TOK_ID), followed by an IAKERB message or format: it starts with a two-octet token-identifier (TOK_ID), which
a Kerberos message. is followed by an IAKERB message or a Kerberos message.
Only one IAKERB specific message, namely the IAKERB_PROXY message, is Only one IAKERB specific message, namely the IAKERB_PROXY message, is
defined in this document. The TOK_ID values for Kerberos messages defined in this document. The TOK_ID values for Kerberos messages
are the same as defined in [RFC4121]. are the same as defined in [RFC4121].
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. The HEADER structure immediately followed by a Kerberos message, which is
Kerberos message can be an AS-REQ, an AS-REP, a TGS-REQ, a TGS-REP, optional. The Kerberos message can be an AS-REQ, an AS-REP, a TGS-
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
-- 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 IAKERB client fills out the IAKERB-HEADER structure as follows: The client fills out the IAKERB-HEADER structure as follows: the
the target-realm contains the realm name the ticket request is target-realm contains the realm name the ticket request is addressed
addressed to. In the initial message from the client, the cookie to. In the initial message from the client, the cookie field is
field is absent. The client MUST specify a target-realm. If the absent. The client MAY send a completely empty IAKERB_PROXY message
client does not know the realm of the client's true principal name (consisting solely of the octets 05 01 and an IAKERB_HEADER with
[RFC6806], it MUST specify a realm it knows. This can be the realm zero-length target-realm) in order to query the Kerberos realm of the
of the client's host. acceptor, see Section 3.1. In all other cases, the client MUST
specify a target-realm. This can be the realm of the client's host,
if no other realm information is available. client's host.
Upon receipt of the IAKERB_PROXY message, the GSS-API acceptor Upon receipt of the IAKERB_PROXY message, the GSS-API acceptor
inspects the target-realm field in the IAKERB_HEADER, and locates a inspects the target-realm field in the IAKERB_HEADER, locates a KDC
KDC of that realm, and sends the ticket request to that KDC. for that realm, and sends the ticket request to that KDC. The IAKERB
proxy MAY engage in fallback behavior, retransmitting packets to a
given KDC and/or sending the request to other KDCs in that realm if
the initial transmission does not receive a reply, as would be done
if the proxy was making requests on its own behalf.
The GSS-API server encapsulates the KDC reply message in the returned The GSS-API acceptor encapsulates the KDC reply message in the
IAKERB message. It fills out the target realm using the realm sent returned IAKERB message. It fills out the target realm using the
by the client and the KDC reply message is included immediately realm sent by the client and the KDC reply message is included
following the IAKERB-HEADER header. immediately following the IAKERB-HEADER header.
When the GSS-API acceptor is unable to obtain an IP address for a KDC When the GSS-API acceptor is unable to obtain an IP address for a KDC
in the client's realm, it sends a KRB_ERROR message with the code in the client's realm, it sends a KRB_ERROR message with the code
KRB_AP_ERR_IAKERB_KDC_NOT_FOUND to the client and the context fails KRB_AP_ERR_IAKERB_KDC_NOT_FOUND to the client in place of an actual
to establish. There is no accompanying error data defined in this reply from the KDC, and the context fails to establish. There is no
document for this error code. accompanying error data defined in this document for this error code.
KRB_AP_ERR_IAKERB_KDC_NOT_FOUND 85 KRB_AP_ERR_IAKERB_KDC_NOT_FOUND 85
-- The IAKERB proxy could not find a KDC. -- The IAKERB proxy could not find a KDC.
When the GSS-API acceptor has an IP address for a KDC in the client When the GSS-API acceptor has an IP address for at least one KDC in
realm, but does not receive a response from any KDC in the realm the target realm, but does not receive a response from any KDC in the
(including in response to retries), it sends a KRB_ERROR message with realm (including in response to retries), it sends a KRB_ERROR
the code KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE to the client and the message with the code KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE to the client
context fails to establish. There is no accompanying error data and the context fails to establish. There is no accompanying error
defined in this document for this error code. data defined in this document for this error code.
KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE 86 KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE 86
-- The KDC did not respond to the IAKERB proxy. -- The KDC did not respond to the IAKERB proxy.
The IAKERB proxy can send opaque data in the cookie field of the The IAKERB proxy can send opaque data in the cookie field of the
IAKERB-HEADER structure in the server reply to the client, in order IAKERB-HEADER structure in the server reply to the client, in order
to, for example, minimize the amount of state information kept by the to, for example, minimize the amount of state information kept by the
GSS-API acceptor. The content and the encoding of the cookie field GSS-API acceptor. The content and the encoding of the cookie field
is a local matter of the IAKERB proxy. The client MUST copy the is a local matter of the IAKERB proxy. Whenever the cookie is
cookie verbatim from the previous server response whenever the cookie present in a token received by the initiator, the initiator MUST copy
is present into the subsequent tokens that contains an IAKERB_PROXY the cookie verbatim into its subsequent response tokens which contain
message. IAKERB_PROXY messages.
The client and the server can repeat the sequence of sending and The client and the server can repeat the sequence of sending and
receiving the IAKERB messages as described above, in order to allow receiving the IAKERB messages as described above for an arbitrary
the client interact with the KDC through the IAKERB proxy, and to number of message exchanges, in order to allow the client to interact
obtain Kerberos tickets as needed. with the KDC through the IAKERB proxy, and to obtain Kerberos tickets
as needed to authenticate to the acceptor.
When obtaining the initial TGT, the client may start with an NT-
ENTERPRISE name type and the client host does not have a Kerberos
realm. To resolve the NT-ENTERPRISE name type, the client typically
starts with the client host realm and then finds out the true realm
of the client based on [RFC6806]. In this case the GSS-API client
can retrieve the realm of the GSS-API server as follows: the client
returns GSS_S_CONTINUE_NEEDED with the output token containing an
IAKERB message with an empty target-realm in the IAKERB-HEADER and no
Kerberos message following the IAKERB-HEADER structure. Upon receipt
of the realm request, the GSS-API server fills out the target realm
field using the realm of the server, and returns
GSS_S_CONTINUE_NEEDED with the output token containing the IAKERB
message with the server's realm and no Kerberos message following the
IAKERB-HEADER header. The GSS-API client can then use the returned
realm in subsequent IAKERB messages to resolve the NT-ENTERPRISE name
type. Since the GSS-API server can act as a Kerberos acceptor, it
always has a Kerberos realm in this case.
When the client obtained a service ticket, the client sends a Once the client has obtained the service ticket needed to
KRB_AP_REQ message to the server, and performs the client-server authenticate to the acceptor, subsequent GSS-API context tokens are
application exchange as defined in [RFC4120] and [RFC4121]. of type KRB_AP_REQ, not IAKERB_PROXY, and the client performs the
client-server application exchange as defined in [RFC4120] and
[RFC4121].
For implementations conforming to this specification, both the For implementations conforming to this specification, both the
authenticator subkey and the GSS_EXTS_FINISHED extension as defined authenticator subkey and the GSS_EXTS_FINISHED extension as defined
in Section 4 MUST be present in the AP-REQ authenticator. This in Section 4 MUST be present in the AP-REQ authenticator. This
checksum provides integrity protection for the messages exchanged checksum provides integrity protection for the IAKERB messages
including the unauthenticated clear texts in the IAKERB-HEADER previously exchanged, including the unauthenticated clear texts in
structure. the IAKERB-HEADER structure.
If the pre-authentication data is encrypted in the long-term If the pre-authentication data is encrypted in the long-term
password-based key of the principal, the risk of security exposures password-based key of the principal, the risk of security exposures
is significant. Implementations SHOULD provide the AS_REQ armoring is significant. Implementations SHOULD utilize the AS_REQ armoring
as defined in [RFC6113] unless an alternative protection is deployed. as defined in [RFC6113] unless an alternative protection is deployed.
In addition, the anonymous Kerberos FAST option is RECOMMENDED for In addition, the anonymous Kerberos FAST option is RECOMMENDED for
the client to complicate traffic analysis. the client to complicate traffic analysis.
3.1. Enterprise principal names
The introduction of principal name canonicalization by [RFC6806]
created the possibility for a client to have a principal name (of
type NT-ENTERPRISE) for which it is trying to obtain credentials, but
no information about what realm's KDC to contact to obtain those
credentials. A Kerberos client not using IAKERB would typically
resolve the NT-ENTERPRISE name to a principal name by starting from
the realm of the client's host and finding out the true realm of the
enterprise principal based on referrals [RFC6806].
A client using IAKERB may not have any realm information, even for
the realm of the client's host, or may know that the client host's
realm is not appropriate for a given enterprise principal name. In
such cases, the client can retrieve the realm of the GSS-API acceptor
as follows: the client returns GSS_S_CONTINUE_NEEDED with the output
token containing an IAKERB message with an empty target-realm in the
IAKERB-HEADER and no Kerberos message following the IAKERB-HEADER
structure. Upon receipt of the realm request, the GSS-API acceptor
fills out an IAKERB_PROXY response message, filling the target-realm
field with the realm of the acceptor, and returns
GSS_S_CONTINUE_NEEDED with the output token containing the IAKERB
message with the server's realm and no Kerberos message following the
IAKERB-HEADER header. The GSS-API initiator can then use the
returned realm in subsequent IAKERB messages to resolve the NT-
ENTERPRISE name type. Since the GSS-API acceptor can act as a
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 the type GSS_EXTS_IAKERB_FINISHED and the extension data extension of type GSS_EXTS_FINISHED with extension data containing
contains the ASN.1 DER encoding of the structure IAKERB-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
-- 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,
-- in the order that the tokens were sent. -- in the order that the tokens were sent.
... ...
} }
pnp The gss-mic field in the KRB-FINISHED structure contains a The gss-mic field in the KRB-FINISHED structure contains a Kerberos
Kerberos checksum [RFC3961] of all the preceding context tokens of checksum [RFC3961] of all the preceding context tokens of this GSS-
this GSS-API context (including the InitialContextToken header), API context (including the generic token framing of the GSSAPI-Token
concatenated in chronological order (note that GSS-API context token type from [RFC4121]), concatenated in chronological order (note that
exchanges are synchronous.) The checksum type is the required GSS-API context token exchanges are synchronous). The checksum type
checksum type of the enctype of the subkey in the authenticator, the is the required checksum type of the enctype of the subkey in the
protocol key for the checksum operation is the authenticator subkey, authenticator, the protocol key for the checksum operation is the
and the key usage number is KEY_USAGE_FINISHED. authenticator subkey, and the key usage number is KEY_USAGE_FINISHED.
KEY_USAGE_FINISHED 41 KEY_USAGE_FINISHED 41
The GSS-API acceptor MUST then verify the checksum contained in the The GSS-API acceptor MUST then verify the checksum contained in the
GSS_EXTS_FINISHED extension. This checksum provides integrity GSS_EXTS_FINISHED extension. This checksum provides integrity
protection for the messages exchanged including the unauthenticated protection for the messages exchanged including the unauthenticated
clear texts in the IAKERB-HEADER structure. clear texts in the IAKERB-HEADER structure.
5. Addresses in Tickets 5. Addresses in Tickets
In IAKERB, the machine sending requests to the KDC is the GSS-API In IAKERB, the machine sending requests to the KDC is the GSS-API
acceptor and not the client. As a result, the client should not acceptor and not the client. As a result, the client should not
include its addresses in any KDC requests for two reasons. First, include its addresses in any KDC requests for two reasons. First,
the KDC may reject the forwarded request as being from the wrong the KDC may reject the forwarded request as being from the wrong
client. Second, in the case of initial authentication for a dial-up client. Second, in the case of initial authentication for a dial-up
client, the client machine may not yet possess a network address. client, the client machine may not yet possess a network address.
Hence, as allowed by [RFC4120], the addresses field of the AS-REQ and Hence, as allowed by [RFC4120], the addresses field of the AS-REQ and
TGS-REQ requests SHOULD be blank and the caddr field of the ticket TGS-REQ requests SHOULD be blank.
SHOULD similarly be left blank.
6. Security Considerations 6. Security Considerations
A typical IAKERB client sends the AS_REQ with pre-authentication data The IAKERB proxy is a man-in-the-middle for the client's Kerberos
encrypted in the long-term keys of the user before the server is exchanges. The Kerberos protocol is designed to be used over an
authenticated. This enables offline attacks by un-trusted servers. untrusted network, so this is not a critical flaw, but it does expose
To mitigate this threat, the client SHOULD use Kerberos FAST[RFC6113] to the IAKERB proxy all information sent in cleartext over those
and require KDC authentication to protect the user's credentials. exchanges, such as the principal names in requests. Since the
typical usage involves the client obtaining a service ticket for the
service operating the proxy, which will receive the client principal
as part of normal authentication, this is also not a serious concern.
However, an IAKERB client not using an armored FAST channel [RFC6113]
sends an AS_REQ with pre-authentication data encrypted in the long-
term keys of the user, even before the acceptor is authenticated.
This subjects the user's long-term key to an offline attack by the
proxy. To mitigate this threat, the client SHOULD use FAST [RFC6113]
and its KDC authentication facility to protect the user's
credentials.
The client name is in clear text in the authentication exchange Similarly, the client principal name is in cleartext in the AS and
messages and ticket granting service exchanges according to [RFC4120] TGS exchanges, whereas in the AP exchanges embedded in GSS context
whereas the client name is encrypted in client- server application tokens for the regular krb5 mechanism, the client principal name is
exchange messages. By using the IAKERB proxy to relay the ticket present only in encrypted form. Thus, more information is exposed
requests and responses, the client's identity could be revealed in over the network path between initiator and acceptor when IAKERB is
the client-server traffic where the same identity could have been used than when the krb5 mechanism is used, unless FAST armor is
concealed if IAKERB were not used. Hence, to complicate traffic employed. (This information would be exposed in other traffic from
analysis and provide privacy for the IAKERB client, the IAKERB client the initiator when the krb5 mech is used.) As such, to complicate
traffic analysis and provide privacy for the client, the client
SHOULD request the anonymous Kerberos FAST option [RFC6113]. SHOULD request the anonymous Kerberos FAST option [RFC6113].
Similar to other network access protocols, IAKERB allows an Similar to other network access protocols, IAKERB allows an
unauthenticated client (possibly outside the security perimeter of an unauthenticated client (possibly outside the security perimeter of an
organization) to send messages that are proxied to interior servers. organization) to send messages that are proxied to servers inside the
To reduce attack surface, firewall filters can be applied to allow perimeter. To reduce the attack surface, firewall filters can be
from which hosts the client requests can be proxied and the proxy can applied to restrict from which hosts client requests can be proxied,
further restrict the set of realms to which the requests can be and the proxy can further restrict the set of realms to which
proxied. requests can be proxied.
In the intended use scenario, the client uses the proxy to obtain a
TGT and then a service ticket for the service it is authenticating to
(possibly preceeded by exchanges to produce FAST armor). However,
the protocol allows arbitrary KDC-REQs to be passed through, and
there is no limit to the number of exchanges that may be proxied.
The client can send KDC-REQs unrelated to the current authentication,
and obtain service tickets for other service principals in the
database of the KDC being contacted.
In a scenario where DNS SRV RR's are being used to locate the KDC, In a scenario where DNS SRV RR's are being used to locate the KDC,
IAKERB is being used, and an external attacker can modify DNS IAKERB is being used, and an external attacker can modify DNS
responses to the IAKERB proxy, there are several countermeasures to responses to the IAKERB proxy, there are several countermeasures to
prevent arbitrary messages from being sent to internal servers: prevent arbitrary messages from being sent to internal servers:
1. KDC port numbers can be statically configured on the IAKERB 1. KDC port numbers can be statically configured on the IAKERB
proxy. In this case, the messages will always be sent to KDC's. proxy. In this case, the messages will always be sent to KDC's.
For an organization that runs KDC's on a static port (usually For an organization that runs KDC's on a static port (usually
port 88) and does not run any other servers on the same port, port 88) and does not run any other servers on the same port,
skipping to change at page 8, line 38 skipping to change at page 10, line 5
between itself and the DNS server). between itself and the DNS server).
7. Acknowledgements 7. Acknowledgements
Jonathan Trostle, Michael Swift, Bernard Aboba and Glen Zorn wrote Jonathan Trostle, Michael Swift, Bernard Aboba and Glen Zorn wrote
earlier revision of this document. earlier revision of this document.
The hallway conversations between Larry Zhu and Nicolas Williams The hallway conversations between Larry Zhu and Nicolas Williams
formed the basis of this document. formed the basis of this document.
8. IANA Considerations 8. Assigned Numbers
The value for the error code KRB_AP_ERR_IAKERB_KDC_NOT_FOUND is 85.
The value for the error code KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE is 86.
The key usage number KEY_USAGE_FINISHED is 41.
The key usage number KEY_USAGE_IAKERB_FINISHED is 42.
9. IANA Considerations
IANA is requested to make a modification in the "Kerberos GSS-API IANA is requested to make a modification in the "Kerberos GSS-API
Token Type Identifiers" registry. Token Type Identifiers" registry.
The following data to the table: The following data to the table:
+-------+--------------+------------+ +-------+--------------+------------+
| ID | Description | Reference | | ID | Description | Reference |
+-------+--------------+------------+ +-------+--------------+------------+
| 05 01 | IAKERB_PROXY | [THIS RFC] | | 05 01 | IAKERB_PROXY | [THIS RFC] |
+-------+--------------+------------+ +-------+--------------+------------+
9. References 10. References
9.1. Normative References 10.1. Normative References
[CCITT.X680.2002]
International Telephone and Telegraph Consultative
Committee, "Abstract Syntax Notation One (ASN.1):
Specification of basic notation", CCITT Recommendation
X.680, July 2002.
[CCITT.X690.2002]
International Telephone and Telegraph Consultative
Committee, "ASN.1 encoding rules: Specification of basic
encoding Rules (BER), Canonical encoding rules (CER) and
Distinguished encoding rules (DER)", CCITT Recommendation
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, March 1997.
[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, January 2000.
[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, February 2005.
[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. July 2005.
[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, July
2005. 2005.
[RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
Simple and Protected Generic Security Service Application
Program Interface (GSS-API) Negotiation Mechanism", RFC
4178, October 2005.
[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, March 2012.
9.2. Informative references 10.2. Informative references
[CCITT.X680.2002]
International International Telephone and Telegraph
Consultative Committee, "Abstract Syntax Notation One
(ASN.1): Specification of basic notation", CCITT
Recommendation X.680, July 2002.
[CCITT.X690.2002]
International International Telephone and Telegraph
Consultative Committee, "ASN.1 encoding rules:
Specification of basic encoding Rules (BER), Canonical
encoding rules (CER) and Distinguished encoding rules
(DER)", CCITT Recommendation X.690, July 2002.
[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, April 2011.
[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, April 2011.
[RFC6806] Hartman, S., Raeburn, K., and L. Zhu, "Kerberos Principal [RFC6806] Hartman, S., Raeburn, K., and L. Zhu, "Kerberos Principal
Name Canonicalization and Cross-Realm Referrals", RFC Name Canonicalization and Cross-Realm Referrals", RFC
6806, November 2012. 6806, November 2012.
Appendix A. Interoperate with Previous MIT version Appendix A. Interoperate with Previous MIT version
MIT implemented an early draft version of this document, this section MIT implemented an early draft version of this document. This
gives a method for detecting and interoperating with that version. section gives a method for detecting and interoperating with that
version.
Initiators behave as follows: Initiators behave as follows:
o If the acceptor token is framed, then use the protocol as defined o If the first acceptor token begins with generic token framing as
above. described in section 3.1 of [RFC2743], then use the protocol as
defined in this document.
o Else
* All future tokens sent to the acceptor are to be unframed. o If the first acceptor token is missing the generic token framing
(i.e., the token begins with the two-byte token ID 05 01), then
* When creating the finish message, the value of one (1) should * When creating the finish message, the value of one (1) should
be used in place of GSS_EXTS_FINISHED. be used in place of GSS_EXTS_FINISHED.
* When computing the checksum, the value of * When computing the checksum, the value of
KEY_USAGE_IAKERB_FINISHED should be used in place of KEY_USAGE_IAKERB_FINISHED should be used in place of
KEY_USAGE_FINISHED. KEY_USAGE_FINISHED.
KEY_USAGE_IAKERB_FINISHED 42 KEY_USAGE_IAKERB_FINISHED 42
Acceptors behave as follows: Acceptors behave as follows:
o If you framed the response token, use the finish extension o After the first initiator token, allow initiator tokens to omit
processing defined in the main document. generic token framing. This allowance is required only for
IAKERB_PROXY messages (those using token ID 05 01), not for tokens
defined in [RFC4121].
o If you did not frame the response token, use the finish extension o If the AP-REQ authenticator contains an extension of type 1
processing defined in the previous paragraph. containing a KRB-FINISHED message, then process the extension as
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).
Authors' Addresses Authors' Addresses
Benjamin Kaduk (editor)
MIT KIT
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
 End of changes. 50 change blocks. 
171 lines changed or deleted 247 lines changed or added

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