draft-ietf-cat-iakerb-07.txt   draft-ietf-cat-iakerb-08.txt 
INTERNET-DRAFT Mike Swift INTERNET-DRAFT Jonathan Trostle
draft-ietf-cat-iakerb-07.txt University of WA draft-ietf-cat-iakerb-08.txt Cisco Systems
Updates: RFC 1510, 1964 Jonathan Trostle Updates: RFC 1510, 1964 Michael Swift
July 2001 Cisco Systems September 2001 University of WA
Bernard Aboba Bernard Aboba
Microsoft Microsoft
Glen Zorn Glen Zorn
Cisco Systems Cisco Systems
Extending the GSS Kerberos Mechanism for Initial Kerberos Authentication Initial and Pass Through Authentication Using Kerberos V5 and the GSS-API
(IAKERB) (IAKERB)
<draft-ietf-cat-iakerb-07.txt> <draft-ietf-cat-iakerb-08.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [6]. all provisions of Section 10 of RFC2026 [5].
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This draft expires in January 2002. Please send comments to the This draft expires in March 2002. Please send comments to the
authors. authors.
1. Abstract 1. Abstract
This document defines extensions to the Kerberos protocol This document defines extensions to the Kerberos protocol
specification (RFC 1510 [1]) and GSSAPI Kerberos mechanism (RFC 1964 specification (RFC 1510 [1]) and GSSAPI Kerberos protocol mechanism
[2]) that enables a RFC 1964 client to obtain Kerberos tickets for (RFC 1964 [2]) that enables a client to 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. Some common scenarios where accessible to the application server. Some common scenarios where
lack of accessibility would occur are when the client does not have lack of accessibility would occur are when the client does not have
an IP address prior to authenticating to an access point, the client an IP address prior to authenticating to an access point, the client
is unable to locate a KDC, or a KDC is behind a firewall. The is unable to locate a KDC, or a KDC is behind a firewall. The
document specifies two protocols to allow a client to exchange KDC document specifies two protocols to allow a client to exchange KDC
messages (which are GSS encapsulated) with an IAKERB proxy instead of messages (which are GSS encapsulated) with an IAKERB proxy instead of
a KDC. a KDC.
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 [7]. document are to be interpreted as described in RFC2119 [6].
3. Motivation 3. Motivation
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 method of operation works well KDC and present them to services. This method of operation works well
in many situations, but is not always applicable. The following is a in many situations, but is not always applicable. The following is a
list of some of the scenarios that this proposal addresses: list of some of the scenarios that this proposal addresses:
(1) The client must initially authenticate to an access point in (1) The client must initially authenticate to an access point in
order to gain full access to the network. Here the client may be order to gain full access to the network. Here the client may be
unable to directly contact the KDC either because it does not have an unable to directly contact the KDC either because it does not have an
IP address, or the access point packet filter does not allow the IP address, or the access point packet filter does not allow the
client to send packets to the Internet before it authenticates to the client to send packets to the Internet before it authenticates to the
access point. access point [8].
(2) A KDC is behind a firewall so the client will send Kerberos (2) A KDC is behind a firewall so the client will send Kerberos
messages to the IAKERB proxy which will transmit the KDC request and messages to the IAKERB proxy which will transmit the KDC request and
reply messages between the client and the KDC. (The IAKERB proxy is a reply messages between the client and the KDC. (The IAKERB proxy is a
special type of Kerberos application server that also relays KDC special type of Kerberos application server that also relays KDC
request and reply messages between a client and the KDC). request and reply messages between a client and the KDC).
4. Overview 4. Overview
This proposal specifies two protocols that address the above This proposal specifies two protocols that address the above
scenarios: the IAKERB proxy option and the IAKERB minimal messages scenarios: the IAKERB proxy option and the IAKERB minimal messages
option. In the IAKERB proxy option (see Figure 1) an application option. In the IAKERB proxy option (see Figure 1) an application
server called the IAKERB proxy acts as a protocol gateway and proxies server called the IAKERB proxy acts as a protocol gateway and proxies
Kerberos messages back and forth between the client and the KDC. The Kerberos messages back and forth between the client and the KDC. The
IAKERB proxy is also responsible for locating the KDC and may IAKERB proxy is also responsible for locating the KDC and may
additionally perform other application proxy level functions such as additionally perform other application proxy level functions such as
auditing. auditing. A compliant IAKERB proxy MUST implement the IAKERB proxy
protocol.
Client <---------> IAKERB proxy <----------> KDC Client <---------> IAKERB proxy <----------> KDC
Figure 1: IAKERB proxying Figure 1: IAKERB proxying
The second protocol is the minimal messages protocol that extends the The second protocol is the minimal messages protocol which is based
technique in [5]; this protocol is targetted at environments where on user-user authentication [4]; this protocol is targetted at
the number of messages (prior to key establishment) needs to be environments where the number of messages, prior to key
minimized. Here the client sends its ticket granting ticket (TGT) to establishment, needs to be minimized. In the normal minimal messages
the IAKERB proxy (in a KRB_TKT_PUSH message) for the TGS case. The protocol, the client sends its ticket granting ticket (TGT) to the
IAKERB proxy then sends a TGS_REQ to the KDC with the client's TGT in IAKERB proxy (in a KRB_TKT_PUSH message) for the TGS case. The IAKERB
the additional tickets field of the TGS_REQ message. As a result, the proxy then sends a TGS_REQ to the KDC with the client's TGT in the
returned ticket will list the client as the ticket's server additional tickets field of the TGS_REQ message. The returned ticket
principal, and will be encrypted with the session key from the will list the client as the ticket's server principal, and will be
client's TGT. The IAKERB proxy then uses this ticket to generate an encrypted with the session key from the client's TGT. The IAKERB
AP request that is sent to the client (see Figure 2). Thus mutual proxy then uses this ticket to generate an AP request that is sent to
authentication is accomplished with three messages between the client the client (see Figure 2). Thus mutual authentication is accomplished
and the IAKERB proxy versus four or more (the difference is larger if with three messages between the client and the IAKERB proxy versus
crossrealm operations are involved). Subsequent to mutual four or more (the difference is larger if crossrealm operations are
authentication and key establishment, the IAKERB proxy sends a ticket involved).
to the client (in a KRB_TKT_PUSH message) that contains the same
fields as the original service ticket except the client and server Subsequent to mutual authentication and key establishment, the IAKERB
names are reversed and it is encrypted in a long term key known to proxy sends a ticket to the client (in a KRB_TKT_PUSH message). This
the IAKERB proxy. Its purpose is to enable fast subsequent re- ticket is created by the IAKERB proxy and contains the same fields as
authentication by the client to the application server (using the the original service ticket that the proxy sent in the AP_REQ
conventional AP request AP reply exchange) for subsequent sessions. message, except the client and server names are reversed and it is
In addition to minimizing the number of messages, a secondary goal is encrypted in a long term key known to the IAKERB proxy. Its purpose
to minimize the number of bytes transferred between the client and is to enable fast subsequent re-authentication by the client to the
the IAKERB proxy prior to mutual authentication and key application server (using the conventional AP request AP reply
establishment. Therefore, the final service ticket (the reverse exchange) for subsequent sessions. In addition to minimizing the
ticket) is sent after mutual authentication and key establishment is number of messages, a secondary goal is to minimize the number of
complete, rather than as part of the initial AP_REQ from the IAKERB bytes transferred between the client and the IAKERB proxy prior to
proxy to the client. mutual authentication and key establishment. Therefore, the final
service ticket (the reverse ticket) is sent after mutual
authentication and key establishment is complete, rather than as part
of the initial AP_REQ from the IAKERB proxy to the client. Thus
protected application data (e.g., GSS signed and wrapped messages)
can flow before this final message is sent.
The AS_REQ case for the minimal messages option is similar, where the The AS_REQ case for the minimal messages option is similar, where the
client sends up the AS_REQ message and the IAKERB proxy forwards it client sends up the AS_REQ message and the IAKERB proxy forwards it
to the KDC. The IAKERB proxy pulls the client TGT out of the AS_REP to the KDC. The IAKERB proxy pulls the client TGT out of the AS_REP
message and also forwards the AS_REP message back to the client. The message; the protocol now proceeds as in the TGS_REQ case described
protocol now proceeds as in the TGS_REQ case with the IAKERB proxy above with the IAKERB proxy including the client's TGT in the
including the client's TGT in the additional tickets field of the additional tickets field of the TGS_REQ message.
TGS_REQ message.
A compliant IAKERB proxy MUST implement the IAKERB proxy protocol,
and MAY implement the IAKERB minimal message protocol. In general,
the existing Kerberos paradigm where clients contact the KDC to
obtain service tickets should be preserved where possible.
For most IAKERB scenarios, such as when the client does not have an
IP address, or cannot directly contact a KDC, the IAKERB proxy
protocol should be adequate. If the client needs to obtain a
crossrealm TGT (and the conventional Kerberos protocol cannot be
used), then the IAKERB proxy protocol must be used. In a scenario
where the client does not have a service ticket for the target
server, it is crucial that the number of messages between the client
and the target server be minimized (especially if the client and
target server are in different realms), and/or it is crucial that the
number of bytes transferred between the client and the target server
be minimized, then the client should consider using the minimal
messages protocol. The reader should see the security considerations
section regarding the minimal messages protocol.
Client --------> IAKERB proxy Client --------> IAKERB proxy
TKT_PUSH (w/ TGT) TKT_PUSH (w/ TGT)
Client IAKERB proxy --------------------> KDC Client IAKERB proxy --------------------> KDC
TGS_REQ with client TGS_REQ with client
TGT as additional TGT TGT as additional TGT
Client IAKERB proxy <-------------------- KDC Client IAKERB proxy <-------------------- KDC
TGS_REP with service TGS_REP with service
skipping to change at page 4, line 4 skipping to change at page 4, line 30
AP_REP AP_REP
------------------------------------------------------------- -------------------------------------------------------------
post-key establishment and application data flow phase: post-key establishment and application data flow phase:
Client <-------- IAKERB proxy KDC Client <-------- IAKERB proxy KDC
TKT_PUSH (w/ticket targetted at IAKERB proxy TKT_PUSH (w/ticket targetted at IAKERB proxy
to enable fast subsequent authentication) to enable fast subsequent authentication)
Figure 2: IAKERB Minimal Messages Option: TGS case Figure 2: IAKERB Minimal Messages Option: TGS case
A compliant IAKERB proxy MUST implement the IAKERB proxy protocol,
and MAY implement the IAKERB minimal message protocol. In general,
the existing Kerberos paradigm where clients contact the KDC to
obtain service tickets should be preserved where possible.
If the client has a service ticket for the target server, needs to
authenticate to the target server, and does not have direct
connectivity with the target server, it should use the IAKERB proxy
protocol. If the client needs to obtain a crossrealm TGT (and the
conventional Kerberos protocol cannot be used), then the IAKERB proxy
protocol must be used. In a scenario where the client does not have a
service ticket for the target server, it is crucial that the number
of messages between the client and the target server be minimized
(especially if the client and target server are in different realms),
and/or it is crucial that the number of bytes transferred between the
client and the target server be minimized, then the client should
consider using the minimal messages protocol. The reader should see
the security considerations section regarding the minimal messages
protocol.
5. GSSAPI Encapsulation 5. GSSAPI Encapsulation
The mechanism ID for IAKERB proxy GSS-API Kerberos, in accordance The mechanism ID for IAKERB proxy GSS-API Kerberos, in accordance
with the mechanism proposed by SPNEGO [8] for negotiating protocol with the mechanism proposed by SPNEGO [7] for negotiating protocol
variations, is: {iso(1) org(3) dod(6) internet(1) security(5) variations, is: {iso(1) org(3) dod(6) internet(1) security(5)
mechanisms(5) iakerb(10) iakerbProxyProtocol(1)}. The proposed mechanisms(5) iakerb(10) iakerbProxyProtocol(1)}. The proposed
mechanism ID for IAKERB minimum messages GSS-API Kerberos, in mechanism ID for IAKERB minimum messages GSS-API Kerberos, in
accordance with the mechanism proposed by SPNEGO for negotiating accordance with the mechanism proposed by SPNEGO for negotiating
protocol variations, is: {iso(1) org(3) dod(6) internet(1) protocol variations, is: {iso(1) org(3) dod(6) internet(1)
security(5) mechanisms(5) iakerb(10) security(5) mechanisms(5) iakerb(10)
iakerbMinimumMessagesProtocol(2)}. iakerbMinimumMessagesProtocol(2)}.
NOTE: An IAKERB implementation does not require SPNEGO in order to
achieve interoperability with other IAKERB peers. Two IAKERB
implementations may interoperate in the same way that any two peers
can interoperate using a pre-established GSSAPI mechanism. The above
OID's allow two SPNEGO peers to securely negotiate IAKERB from among
a set of GSS mechanisms.
The AS request, AS reply, TGS request, and TGS reply messages are all The AS request, AS reply, TGS request, and TGS reply messages are all
encapsulated using the format defined by RFC1964 [2]. This consists encapsulated using the format defined by RFC1964 [2]. This consists
of the GSS-API token framing defined in appendix B of RFC1508 [3]: of the GSS-API token framing defined in appendix B of [3]:
InitialContextToken ::= [APPLICATION 0] IMPLICIT SEQUENCE { InitialContextToken ::= [APPLICATION 0] IMPLICIT SEQUENCE {
thisMech MechType thisMech MechType
-- MechType is OBJECT IDENTIFIER -- MechType is OBJECT IDENTIFIER
-- representing "Kerberos V5" -- representing iakerb proxy or iakerb min messages
innerContextToken ANY DEFINED BY thisMech innerContextToken ANY DEFINED BY thisMech
-- contents mechanism-specific; -- contents mechanism-specific;
-- ASN.1 usage within innerContextToken -- ASN.1 usage within innerContextToken
-- is not required -- is not required
} }
The innerContextToken consists of a 2-byte TOK_ID field (defined The innerContextToken consists of a 2-byte TOK_ID field (defined
below), followed by the Kerberos V5 KRB_AS_REQ, KRB_AS_REP, below), followed by the Kerberos V5 KRB_AS_REQ, KRB_AS_REP,
KRB_TGS_REQ, or KRB_TGS_REP messages, as appropriate. The TOK_ID KRB_TGS_REQ, or KRB_TGS_REP messages, as appropriate. The TOK_ID
field shall be one of the following values, to denote that the field shall be one of the following values, to denote that the
message is either a request to the KDC or a response from the KDC. message is either a request to the KDC or a response from the KDC.
Message TOK_ID Message TOK_ID
KRB_KDC_REQ 00 03 KRB_KDC_REQ 00 03
KRB_KDC_REP 01 03 KRB_KDC_REP 01 03
We also define the token ID for the KRB_TKT_PUSH message (defined We also define the token ID for the KRB_TKT_PUSH token (defined below
below and used in the minimal messages variation): and used in the minimal messages variation):
Message TOK_ID Message TOK_ID
KRB_TKT_PUSH 02 03 KRB_TKT_PUSH 02 03
For completeness, we list the other RFC 1964 defined token ID's here: For completeness, we list the other RFC 1964 defined token ID's here:
Message TOK_ID Message TOK_ID
AP_REQ 01 00 AP_REQ 01 00
skipping to change at page 6, line 27 skipping to change at page 6, line 44
being used) being used)
- retry with same or another KDC if no response is received. If - retry with same or another KDC if no response is received. If
the retries also fail, send an error message with error code the retries also fail, send an error message with error code
KRB_IAKERB_ERR_KDC_NO_RESPONSE to the client. KRB_IAKERB_ERR_KDC_NO_RESPONSE to the client.
2. For received KDC_REP messages 2. For received KDC_REP messages
- encapsulate with GSS framing, using token ID 01 03 and the OID - encapsulate with GSS framing, using token ID 01 03 and the OID
that corresponds to the stored protocol option that corresponds to the stored protocol option
- send to client (using the stored client IP address and port) - send to client (using the stored client IP address and port)
3. For received AP_REQ and AP_REP messages 3. For KRB_ERROR messages received from the KDC
- process locally per RFC 1964 - encapsulate with GSS framing, using token ID 03 00 and the OID
that corresponds to the stored protocol option
- send to client (using the stored client IP address and port)
(one possible exception is the KRB_ERR_RESPONSE_TOO_BIG error
which can lead to a retry of the KDC_REQ message over the TCP
transport by the server, instead of simply proxying the error
to the client).
4. For sending/receiving AP_REQ and AP_REP messages
- process per RFC 1510 and RFC 1964; the created AP_REP message
SHOULD include the subkey (with same etype as the session key)
to facilitate use with other key derivation algorithms outside
of [2]. The subkey SHOULD be created using locally generated
entropy as one of the inputs (in addition to other inputs
such as the session key).
Clients: Clients:
1. For sending KDC_REQ messages 1. For sending KDC_REQ messages
- create AS_REQ or TGS_REQ message - create AS_REQ or TGS_REQ message
- encapsulate with GSS framing (token ID 00 03 and OID - encapsulate with GSS framing (token ID 00 03 and OID
corresponding to the protocol option). corresponding to the protocol option).
- send to server - send to server
2. For received KDC_REP messages 2. For received KDC_REP messages
- decapsulate by removing GSS framing (token ID 01 03) - decapsulate by removing GSS framing (token ID 01 03)
- process inner Kerberos message according to RFC 1510 - process inner Kerberos message according to RFC 1510
3. For received AP_REQ and AP_REP messages 3. For received KRB_ERROR messages
- process locally per RFC 1964 - decapsulate by removing GSS framing (token ID 03 00)
- process inner Kerberos message according to RFC 1510
and possibly retry the request (time skew errors lead
to retries in most existing Kerberos implementations)
4. For sending/receiving AP_REQ and AP_REP messages
- process per RFC 1510 and RFC 1964; the created AP_REQ
message SHOULD include the subsession key in the
authenticator field.
7. The IAKERB minimal messages protocol 7. The IAKERB minimal messages protocol
The client MAY initiate the IAKERB minimal messages variation when The client MAY initiate the IAKERB minimal messages variation when
the number of messages must be minimized (the most significant the number of messages must be minimized (the most significant
reduction in the number of messages can occur when the client and the reduction in the number of messages can occur when the client and the
IAKERB proxy are in different realms). SPNEGO [8] may be used to IAKERB proxy are in different realms). SPNEGO [7] MAY be used to
securely negotiate between the protocols. A compliant IAKERB server securely negotiate between the protocols (and amongst other GSS
MAY support the IAKERB minimal messages protocol. mechanism protocols). A compliant IAKERB server MAY support the
IAKERB minimal messages protocol.
(a) AS_REQ case: (used when the client does not have a TGT) (a) AS_REQ case: (used when the client does not have a TGT)
We extend the technique used in Hornstein [5]. The client indicates We apply the Kerberos user-user authentication protocol [4] in this
that the minimal message sub-protocol will be used by using the scenario (other work in this area includes the IETF work in progress
appropriate OID as described above. The client sends the GSS effort to apply Kerberos user user authentication to DHCP
encapsulated AS_REQ message to the IAKERB proxy, and the IAKERB proxy authentication).
processes the GSS framing (as described above for the IAKERB proxy
option) and forwards the AS_REQ message to the KDC.
The IAKERB proxy will proxy the returned message (AS_REP or The client indicates that the minimal message sub-protocol will be
KRB_ERROR) from the KDC back to the client (after processing and used by using the appropriate OID as described above. The client
removing the GSS framing). The protocol is complete in the KRB_ERROR sends the GSS encapsulated AS_REQ message to the IAKERB proxy, and
case (from the server perspective, but the client should retry the IAKERB proxy processes the GSS framing (as described above for
depending on the error type). In the AS_REP case, the IAKERB proxy the IAKERB proxy option) and forwards the AS_REQ message to the KDC.
will obtain the client's TGT from the AS_REP message before
forwarding the AS_REP message to the client. The IAKERB proxy then The IAKERB proxy will either send a KRB_ERROR message back to the
sends a TGS_REQ message with the client's TGT in the additional client, or it will send an initial context token consisting of the
tickets field to the client's KDC (ENC-TKT-IN-SKEY option). GSS header (minimal messages OID with a two byte token header 01 03),
followed by an AS_REP message. The AS_REP message will contain the
AP_REQ message in a padata field; the ticket in the AP_REQ is a
user-user ticket encrypted in the session key from the client's
original TGT. We define the padata type PA-AP-REQ with type number
25. The corresponding padata value is the AP_REQ message without any
GSS framing. For the IAKERB minimal messages AS option, the AP_REQ
message authenticator MUST include the RFC 1964 [2] checksum. The
mutual-required and use-session-key flags are set in the ap-options
field of the AP_REQ message.
The protocol is complete in the KRB_ERROR case (from the server
perspective, but the client should retry depending on the error
type). If the IAKERB proxy receives an AS_REP message from the KDC,
the IAKERB proxy will then obtain the client's TGT from the AS_REP
message. The IAKERB proxy then sends a TGS_REQ message with the
client's TGT in the additional tickets field to the client's KDC
(ENC-TKT-IN-SKEY option).
The IAKERB proxy MAY handle returned KRB_ERROR messages and retry the The IAKERB proxy MAY handle returned KRB_ERROR messages and retry the
TGS request message. Ultimately, the IAKERB proxy either proxies a TGS request message (e.g. on a KRB_ERR_RESPONSE_TOO_BIG error,
KRB_ERROR message to the client, or it sends a GSS Initial Context switching to TCP from UDP). Ultimately, the IAKERB proxy either
token containing an AP_REQ message to the client. (Note: although the proxies a KRB_ERROR message to the client (after adding the GSS
server sends the initial context token, the client is the initiator.) framing), sends one of the new GSS framed KRB_ERROR messages defined
The IAKERB proxy MUST set the MUTUAL AUTH flag in the Initial Context above, or it receives the TGS_REP message from the KDC and then
token in order to cause the client to authenticate as well. The creates the AP_REQ message according to RFC 1964 [2]. The IAKERB
proxy then sends a GSS token containing the AS_REP message with the
AP_REQ message in the padata field as described above. (Note:
although the server sends the context token with the AP_REQ, the
client is the initiator.) The IAKERB proxy MUST set both the mutual-
required and use-session-key flags in the AP_REQ message in order to
cause the client to authenticate as well. The authenticator SHOULD
include the subsession key (containing locally added entropy). The
client will reply with the GSSAPI enscapsulated AP_REP message, if client will reply with the GSSAPI enscapsulated AP_REP message, if
the IAKERB proxy's authentication succeeds. If all goes well, then, the IAKERB proxy's authentication succeeds (which SHOULD include the
in order to enable subsequent efficient client authentications, the subkey field to facilitate use with other key derivation algorithms
IAKERB proxy will then send a final message of type KRB_TKT_PUSH outside of [2]). If all goes well, then, in order to enable
containing a Kerberos ticket (the reverse ticket) that has the IAKERB subsequent efficient client authentications, the IAKERB proxy will
client principal identifier in the client identifier field of the then send a final message of type KRB_TKT_PUSH containing a Kerberos
ticket and its own principal identity in the server identifier field ticket (the reverse ticket) that has the IAKERB client principal
of the ticket: identifier in the client identifier field of the ticket and its own
principal identity in the server identifier field of the ticket (see
Figure 3):
KRB_TKT_PUSH :: = [APPLICATION 17] SEQUENCE { KRB_TKT_PUSH :: = [APPLICATION 17] SEQUENCE {
pvno[0] INTEGER, -- 5 (protocol version) pvno[0] INTEGER, -- 5 (protocol version)
msg-type[1] INTEGER, -- 17 (message type) msg-type[1] INTEGER, -- 17 (message type)
ticket[2] Ticket ticket[2] Ticket
} }
The key used to encrypt the reverse ticket is a long term secret key NOTE: The KRB_TKT_PUSH message must be encoded using ASN.1 DER. The
key used to encrypt the reverse ticket is a long term secret key
chosen by the IAKERB proxy. The fields are identical to the AP_REQ chosen by the IAKERB proxy. The fields are identical to the AP_REQ
ticket, except the client name will be switched with the server name, ticket, except the client name will be switched with the server name,
and the server realm will be switched with the client realm. (The one and the server realm will be switched with the client realm. (The one
other exception is that addresses should not be copied unless the other exception is that addresses should not be copied from the
IAKERB proxy has included the client's address in the TGS_REQ message AP_REQ ticket to the reverse ticket). Sending the reverse ticket
to the KDC). Sending the reverse ticket allows the client to allows the client to efficiently initiate subsequent reauthentication
efficiently initiate subsequent reauthentication attempts with a attempts with a RFC1964 AP_REQ message. Note that the TKT_PUSH
RFC1964 AP_REQ message. Note that the TKT_PUSH message is sent after message is sent after mutual authentication and key establishment are
mutual authentication and key establishment are complete. complete.
Client --------> IAKERB proxy --------------------> KDC
AS_REQ AS_REQ
Client IAKERB proxy <-------------------- KDC
AS_REP w/ client TGT
Client IAKERB proxy --------------------> KDC
TGS_REQ with client
TGT as additional TGT
Client IAKERB proxy <-------------------- KDC
TGS_REP with service
ticket
Client <-------- IAKERB proxy KDC
AS_REP w/ AP_REQ in padata field
Client --------> IAKERB proxy KDC
AP_REP
-------------------------------------------------------------
post-key establishment and application data flow phase:
Client <-------- IAKERB proxy KDC
TKT_PUSH (w/ticket targetted at IAKERB proxy
to enable fast subsequent authentication)
Figure 3: IAKERB Minimal Messages Option: AS case
(b) TGS_REQ case: (used when the client has a TGT) (b) TGS_REQ case: (used when the client has a TGT)
The client indicates that the minimal messages sub-protocol will be The client indicates that the minimal messages sub-protocol will be
used by using the appropriate OID as described above. The client used by using the appropriate OID as described above. The client
initially sends a KRB_TKT_PUSH message (with the GSS header) to the initially sends a KRB_TKT_PUSH message (with the GSS header) to the
IAKERB proxy in order to send it a TGT. The IAKERB proxy will obtain IAKERB proxy in order to send it a TGT. The IAKERB proxy will obtain
the client's TGT from the KRB_TKT_PUSH message and then proceed to the client's TGT from the KRB_TKT_PUSH message and then proceed to
send a TGS_REQ message to a KDC where the realm of the KDC is equal send a TGS_REQ message to a KDC where the realm of the KDC is equal
to the realm from the server realm field in the TGT sent by the to the realm from the server realm field in the TGT sent by the
client in the KRB_TKT_PUSH message. The protocol then continues as in client in the KRB_TKT_PUSH message. NOTE: this realm could be the
the minimal messages AS_REQ case described above (see Figure 2); the client's home realm, the proxy's realm, or an intermediate realm. The
IAKERB proxy's TGS_REQ message contains the client's TGT in the protocol then continues as in the minimal messages AS_REQ case
additional tickets field (ENC-TKT-IN-SKEY option). The IAKERB proxy described above (see Figure 2); the IAKERB proxy's TGS_REQ message
then receives the TGS_REP message from the KDC and then sends a RFC contains the client's TGT in the additional tickets field (ENC-TKT-
1964 AP_REQ message to the client (with the MUTUAL AUTH flag set - IN-SKEY option). The IAKERB proxy then receives the TGS_REP message
see AS_REQ case). from the KDC and then sends a RFC 1964 AP_REQ message to the client
(with the MUTUAL AUTH flag set - see AS_REQ case).
To summarize, here are the steps for the minimal messages TGS
protocol:
Client:
(has TGT already for, or targetted at, realm X.ORG)
sends TKT_PUSH message to server containing client's ticket
for X.ORG (which could be a crossrealm TGT)
Server:
(has TGT already targetted at realm X.ORG)
sends to KDC (where KDC has principal id = server name,
server realm from client ticket) a TGS_REQ:
TGT in TGS_REQ is server's TGT
Additional ticket in TGS_REQ is client's TGT from TKT_PUSH
message
Server name in TGS_REQ (optional by rfc1510) is not present
Server realm in TGS_REQ is realm in server's TGT - X.ORG
KDC:
Builds a ticket:
Server name = client's name
Client name = server's name, Client realm = server's realm
Server realm = client's realm
Encrypted with: session key from client's TGT (passed in
additional tickets field)
Build a TGS_REP
Encrypted with session key from server's TGT
Sends TGS_REP and ticket to server
Server:
Decrypts TGS_REP from KDC using session key from its TGT
Constructs AP_REQ
Ticket = ticket from KDC (which was encrypted with
client's TGT session key)
authenticator clientname = server's name (matches
clientname in AP-REQ ticket)
authenticator clientrealm = server's realm
subsession key in authenticator is present (same
etype as the etype of the session key in the ticket)
checksum in authenticator is the RFC 1964 checksum
sequence number in authenticator is present (RFC 1964)
ap-options has both use-session-key and mutual-required
flags set
Sends AP_REQ (with GSS-API framing) to client
Client:
Receives AP_REQ
Decrypts ticket using session key from its TGT
Verifies AP_REQ
Builds AP_REP and sends to server (AP_REP SHOULD include
subkey field to facilitate use with other key derivation
algorithms outside of [2] e.g., [8] and its successors.
Some apps may have their own message protection key
derivation algorithm and protected message format.
AP_REP includes the sequence number per RFC 1964.)
Server:
Verifies AP-REP. Builds reverse ticket as described above
and sends reverse ticket to client using the KRB_TKT_PUSH
message. The reverse ticket is the same as the AP_REQ
ticket except the client name, realm are switched with the
server name, realm fields and it is encrypted in a secret
key known to the IAKERB proxy.
8. Addresses in Tickets 8. Addresses in Tickets
In IAKERB, the machine sending requests to the KDC is the server and In IAKERB, the machine sending requests to the KDC is the server and
not the client. As a result, the client should not include its not the client. As a result, the client should not include its
addresses in any KDC requests for two reasons. First, the KDC may addresses in any KDC requests for two reasons. First, the KDC may
reject the forwarded request as being from the wrong client. Second, reject the forwarded request as being from the wrong client. Second,
in the case of initial authentication for a dial-up client, the in the case of initial authentication for a dial-up client, the
client machine may not yet possess a network address. Hence, as client machine may not yet possess a network address. Hence, as
allowed by RFC1510 [1], the addresses field of the AS and TGS allowed by RFC1510 [1], the addresses field of the AS and TGS
requests SHOULD be blank and the caddr field of the ticket SHOULD requests SHOULD be blank and the caddr field of the ticket SHOULD
similarly be left blank. One exception is in an AS request (where the similarly be left blank.
request body is not integrity protected); the IAKERB proxy MAY add
its own addresses and the addresses of the client to the AS request.
9. Combining IAKERB with Other Kerberos Extensions 9. Security Considerations
This protocol is usable with other proposed Kerberos extensions such Similar to other network access protocols, IAKERB allows an
as PKINIT (Public Key Cryptography for Initial Authentication in unauthenticated client (possibly outside the security perimeter of an
Kerberos [4]). In such cases, the messages which would normally be organization) to send messages that are proxied to interior servers.
sent to the KDC are instead sent by the client application to the When combined with DNS SRV RR's for KDC lookup, there is the
server, which then forwards them to a KDC. possibility that an attacker can send an arbitrary message to an
interior server. There are several aspects to note here:
10. Security Considerations (1) in many scenarios, compromise of the DNS lookup will require the
attacker to already have access to the internal network. Thus the
attacker would already be able to send arbitrary messages to interior
servers. No new vulnerabilities are added in these scenarios.
(2) 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
responses to the IAKERB proxy, there are several countermeasures to
prevent arbitrary messages from being sent to internal servers:
(a) KDC port numbers can be statically configured on the IAKERB
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 port 88)
and does not run any other servers on the same port, this
countermeasure would be easy to administer and should be effective.
(b) the proxy can do application level sanity checking and filtering.
This countermeasure should eliminate many of the above attacks.
(c) DNS security can be deployed. This countermeasure is probably
overkill for this particular problem, but if an organization has
already deployed DNS security for other reasons, then it might make
sense to leverage it here. Note that Kerberos could be used to
protect the DNS exchanges. The initial DNS SRV KDC lookup by the
proxy will be unprotected, but an attack here is at most a denial of
service (the initial lookup will be for the proxy's KDC to facilitate
Kerberos protection of subsequent DNS exchanges between itself and
the DNS server).
In the minimal messages protocol option, the application server sends In the minimal messages protocol option, the application server sends
an AP_REQ message to the client. The ticket in the AP_REQ message an AP_REQ message to the client. The ticket in the AP_REQ message
SHOULD NOT contain authorization data since some operating systems SHOULD NOT contain authorization data since some operating systems
may allow the client to impersonate the server and increase its own may allow the client to impersonate the server and increase its own
privileges. If the ticket from the server connotes any authorization, privileges. If the ticket from the server connotes any authorization,
then the minimal messages protocol should not be used. Also, the then the minimal messages protocol should not be used. Also, the
minimal messages protocol may facilitate denial of service attacks in minimal messages protocol may facilitate denial of service attacks in
some environments; to prevent these attacks, it may make sense for some environments; to prevent these attacks, it may make sense for
the minimal messages protocol server to only accept a KRB_TGT_PUSH the minimal messages protocol server to only accept a KRB_TGT_PUSH
message on a local network interface (to ensure that the message was message on a local network interface (to ensure that the message was
not sent from a remote malicious host). not sent from a remote malicious host).
11. Acknowledgements 10. Acknowledgements
We thank Ken Raeburn for his helpful comments. We thank the Kerberos Working Group chair, Doug Engert, for his
efforts in helping to progress this specification. We also thank Ken
Raeburn for his comments and the other working group participants for
their input.
12. References 11. References
[1] J. Kohl, C. Neuman, "The Kerberos Network Authentication [1] J. Kohl, C. Neuman, "The Kerberos Network Authentication
Service (V5)", RFC 1510. Service (V5)", RFC 1510.
[2] J. Linn, "The Kerberos Version 5 GSS-API Mechanism", RFC 1964. [2] J. Linn, "The Kerberos Version 5 GSS-API Mechanism", RFC 1964.
[3] J. Linn, "Generic Security Service Application Program Interface", [3] J. Linn, "Generic Security Service Application Program
RFC 2078. Interface Version 2, Update 1", RFC 2743.
[4] B. Tung, C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky, J. Wray,
J. Trostle, "Public Key Cryptography for Initial Authentication in
Kerberos", WORK IN PROGRESS Internet Draft
draft-ietf-cat-kerberos-pkinit-12.txt.
[5] K. Hornstein, T. Lemon, B. Aboba, J. Trostle, "DHCP Authentication [4] D. Davis, R. Swick, "Workstation Services and Kerberos
via Kerberos V", WORK IN PROGRESS Internet Draft Authentication at Project Athena", Technical Memorandum TM-424,
draft-hornstein-dhc-kerbauth-02.txt. MIT Laboratory for Computer Science, February 1990.
[6] S. Bradner, "The Internet Standards Process -- Revision 3", BCP [5] S. Bradner, "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996. 9, RFC 2026, October 1996.
[7] S. Bradner, "Key words for use in RFCs to Indicate Requirement [6] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[8] E. Baize, D. Pinkas, "The Simple and Protected GSS-API Negotiation [7] E. Baize, D. Pinkas, "The Simple and Protected GSS-API Negotiation
Mechanism," RFC 2478, December 1998. Mechanism," RFC 2478, December 1998.
12. Author's Addresses [8] Part 11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) Specifications, ANSI/IEEE Std. 802.11, 1999 Edition.
Michael Swift 12. Author's Addresses
University of Washington
Seattle, WA
Email: mikesw@cs.washington.edu
Jonathan Trostle Jonathan Trostle
Cisco Systems Cisco Systems
170 W. Tasman Dr. 170 W. Tasman Dr.
San Jose, CA 95134, U.S.A. San Jose, CA 95134, U.S.A.
Email: jtrostle@cisco.com Email: jtrostle@cisco.com
Phone: (408) 527-6201 Phone: (408) 527-6201
Michael Swift
University of Washington
Seattle, WA
Email: mikesw@cs.washington.edu
Bernard Aboba Bernard Aboba
Microsoft Microsoft
One Microsoft Way One Microsoft Way
Redmond, Washington, 98052, U.S.A. Redmond, Washington, 98052, U.S.A.
Email: bernarda@microsoft.com Email: bernarda@microsoft.com
Glen Zorn Glen Zorn
Cisco Systems Cisco Systems
Bellevue, WA U.S.A. Bellevue, WA U.S.A.
Email: gwz@cisco.com Email: gwz@cisco.com
Phone: (425) 468-0955 Phone: (425) 468-0955
This draft expires on January 31st, 2002. This draft expires on March 31st, 2002.
 End of changes. 43 change blocks. 
149 lines changed or deleted 331 lines changed or added

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