draft-ietf-cat-iakerb-06.txt   draft-ietf-cat-iakerb-07.txt 
INTERNET-DRAFT Mike Swift INTERNET-DRAFT Mike Swift
draft-ietf-cat-iakerb-06.txt University of WA draft-ietf-cat-iakerb-07.txt University of WA
Updates: RFC 1510 Jonathan Trostle Updates: RFC 1510, 1964 Jonathan Trostle
March 2001 Cisco Systems July 2001 Cisco Systems
Bernard Aboba Bernard Aboba
Microsoft Microsoft
Glen Zorn Glen Zorn
Cisco Systems Cisco Systems
Initial and Pass Through Authentication Using Kerberos V5 and the GSS-API Extending the GSS Kerberos Mechanism for Initial Kerberos Authentication
(IAKERB) (IAKERB)
<draft-ietf-cat-iakerb-06.txt> <draft-ietf-cat-iakerb-07.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 [6].
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.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 on September 30th, 2001. Please send comments to This draft expires in January 2002. Please send comments to the
the authors. authors.
1. Abstract 1. Abstract
This document defines an extension 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 mechanism (RFC 1964
[2]) that enables a client to obtain Kerberos tickets for services [2]) that enables a RFC 1964 client to obtain Kerberos tickets for
where the KDC is not accessible to the client, but is accessible to services where the KDC is not accessible to the client, but is
the application server. Some common scenarios where lack of accessible to the application server. Some common scenarios where
accessibility would occur are when the client does not have an IP lack of accessibility would occur are when the client does not have
address prior to authenticating to an access point, the client is an IP address prior to authenticating to an access point, the client
unable to locate a KDC, or a KDC is behind a firewall. The document is unable to locate a KDC, or a KDC is behind a firewall. The
specifies two protocols to allow a client to exchange KDC messages document specifies two protocols to allow a client to exchange KDC
with an IAKERB proxy instead of a KDC. messages (which are GSS encapsulated) with an IAKERB proxy instead of
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 [7].
3. Motivation 3. Motivation
When authenticating using Kerberos V5, clients obtain tickets from a When authenticating using Kerberos V5, clients obtain tickets from a
skipping to change at page 2, line 50 skipping to change at page 2, line 50
auditing. auditing.
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 that extends the
technique in [5]; this protocol is targetted at environments where technique in [5]; this protocol is targetted at environments where
the number of messages (prior to key establishment) needs to be the number of messages (prior to key establishment) needs to be
minimized. Here the client sends its ticket granting ticket (TGT) to minimized. Here the client sends its ticket granting ticket (TGT) to
the IAKERB proxy (in a KRB-TKT-PUSH message) for the TGS case. The the IAKERB proxy (in a KRB_TKT_PUSH message) for the TGS case. The
IAKERB proxy then sends a TGS_REQ to the KDC with the client's TGT in IAKERB proxy then sends a TGS_REQ to the KDC with the client's TGT in
the additional tickets field of the TGS_REQ message. As a result, the the additional tickets field of the TGS_REQ message. As a result, the
returned ticket will list the client as the ticket's server returned ticket will list the client as the ticket's server
principal, and will be encrypted with the session key from the principal, and will be encrypted with the session key from the
client's TGT. The IAKERB proxy then uses this ticket to generate an client's TGT. The IAKERB proxy then uses this ticket to generate an
AP request that is sent to the client (see Figure 2). Thus mutual AP request that is sent to the client (see Figure 2). Thus mutual
authentication is accomplished with three messages between the client authentication is accomplished with three messages between the client
and the IAKERB proxy versus four or more (the difference is larger if and the IAKERB proxy versus four or more (the difference is larger if
crossrealm operations are involved). Subsequent to mutual crossrealm operations are involved). Subsequent to mutual
authentication and key establishment, the IAKERB proxy sends a ticket authentication and key establishment, the IAKERB proxy sends a ticket
to the client (in a KRB-TKT-PUSH message) that contains the same to the client (in a KRB_TKT_PUSH message) that contains the same
fields as the original service ticket except the client and server fields as the original service ticket except the client and server
names are reversed and it is encrypted in a long term key known to names are reversed and it is encrypted in a long term key known to
the IAKERB proxy. Its purpose is to enable fast subsequent re- the IAKERB proxy. Its purpose is to enable fast subsequent re-
authentication by the client to the application server (using the authentication by the client to the application server (using the
conventional AP request AP reply exchange) for subsequent sessions. conventional AP request AP reply exchange) for subsequent sessions.
In addition to minimizing the number of messages, a secondary goal is In addition to minimizing the number of messages, a secondary goal is
to minimize the number of bytes transferred between the client and to minimize the number of bytes transferred between the client and
the IAKERB proxy prior to mutual authentication and key the IAKERB proxy prior to mutual authentication and key
establishment. Therefore, the final service ticket (the reverse establishment. Therefore, the final service ticket (the reverse
ticket) is sent after mutual authentication and key establishment is ticket) is sent after mutual authentication and key establishment is
skipping to change at page 3, line 32 skipping to change at page 3, line 32
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 and also forwards the AS_REP message back to the client. The
protocol now proceeds as in the TGS_REQ case with the IAKERB proxy protocol now proceeds as in the TGS_REQ case with the IAKERB proxy
including the client's TGT in the additional tickets field of the including the client's TGT in the additional tickets field of the
TGS_REQ message. TGS_REQ message.
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
ticket ticket
Client <-------- IAKERB proxy KDC Client <-------- IAKERB proxy KDC
AP_REQ AP_REQ
Client --------> IAKERB proxy KDC Client --------> IAKERB proxy KDC
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, A compliant IAKERB proxy MUST implement the IAKERB proxy protocol,
and MAY implement the IAKERB minimal message protocol. In general, and MAY implement the IAKERB minimal message protocol. In general,
the existing Kerberos paradigm where clients contact the KDC to the existing Kerberos paradigm where clients contact the KDC to
obtain service tickets should be preserved where possible. obtain service tickets should be preserved where possible.
If the client has a service ticket for the target server, needs to If the client has a service ticket for the target server, needs to
authenticate to the target server, and does not have direct authenticate to the target server, and does not have direct
skipping to change at page 4, line 28 skipping to change at page 4, line 28
and/or it is crucial that the number of bytes transferred between the and/or it is crucial that the number of bytes transferred between the
client and the target server be minimized, then the client should client and the target server be minimized, then the client should
consider using the minimal messages protocol. The reader should see consider using the minimal messages protocol. The reader should see
the security considerations section regarding the minimal messages the security considerations section regarding the minimal messages
protocol. 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 [8] for negotiating protocol
variations, is: {iso(1) member-body(2) United States(840) variations, is: {iso(1) org(3) dod(6) internet(1) security(5)
mit(113554) infosys(1) gssapi(2) krb5(2) initialauth(4)}. The mechanisms(5) iakerb(10) iakerbProxyProtocol(1)}. The proposed
proposed mechanism ID for minimal messages IAKERB GSS-API Kerberos, mechanism ID for IAKERB minimum messages GSS-API Kerberos, in
in accordance with the mechanism proposed by SPNEGO for negotiating accordance with the mechanism proposed by SPNEGO for negotiating
protocol variations, is: {iso(1) member-body(2) United States(840) protocol variations, is: {iso(1) org(3) dod(6) internet(1)
mit(113554) infosys(1) gssapi(2) krb5(2) initialauthminmessages(5)}. security(5) mechanisms(5) iakerb(10)
iakerbMinimumMessagesProtocol(2)}.
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 RFC1508 [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 "Kerberos V5"
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, KRB-TGS- below), followed by the Kerberos V5 KRB_AS_REQ, KRB_AS_REP,
REQ, or KRB-TGS-REP messages, as appropriate. The TOK_ID field shall KRB_TGS_REQ, or KRB_TGS_REP messages, as appropriate. The TOK_ID
be one of the following values, to denote that the message is either field shall be one of the following values, to denote that the
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
We also define the token ID for the KRB-TKT-PUSH message (defined KRB_KDC_REP 01 03
We also define the token ID for the KRB_TKT_PUSH message (defined
below and used in the minimal messages variation): below 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
AP_REP 02 00 AP_REP 02 00
KRB_ERROR 03 00 KRB_ERROR 03 00
skipping to change at page 5, line 38 skipping to change at page 5, line 43
have the Kerberos GSS header (RFC1964 [2]) stripped off. The have the Kerberos GSS header (RFC1964 [2]) stripped off. The
unencapsulated message will then be forwarded to a KDC. The IAKERB unencapsulated message will then be forwarded to a KDC. The IAKERB
proxy is responsible for locating an appropriate KDC using the realm proxy is responsible for locating an appropriate KDC using the realm
information in the KDC request message it received from the client. information in the KDC request message it received from the client.
In addition, the IAKERB proxy SHOULD implement a retry algorithm for In addition, the IAKERB proxy SHOULD implement a retry algorithm for
KDC requests over UDP (including selection of alternate KDC's if the KDC requests over UDP (including selection of alternate KDC's if the
initial KDC does not respond to its requests). For messages sent by initial KDC does not respond to its requests). For messages sent by
the KDC, the IAKERB proxy encapsulates them with a Kerberos GSS the KDC, the IAKERB proxy encapsulates them with a Kerberos GSS
header before sending them to the client. header before sending them to the client.
We define two new Kerberos error codes that allow the proxy to
indicate the following error conditions to the client:
(a) when the proxy is unable to obtain an IP address for a KDC in the
client's realm, it sends the KRB_IAKERB_ERR_KDC_NOT_FOUND KRB_ERROR
(80) message to the client.
(b) when the proxy has an IP address for a KDC in the client realm,
but does not receive a response from any KDC in the realm (including
in response to retries), it sends the KRB_IAKERB_ERR_KDC_NO_RESPONSE
KRB_ERROR (81) message to the client.
To summarize, the sequence of steps for processing is as follows: To summarize, the sequence of steps for processing is as follows:
Servers: 1. For received KDC_REQ messages (with token ID 00 03) Servers:
1. For received KDC_REQ messages (with token ID 00 03)
- process GSS framing (check OID) - process GSS framing (check OID)
if the OID is not one of the two OID's specified in the GSSAPI if the OID is not one of the two OID's specified in the GSSAPI
Encapsulation section above, then process according to mechanism Encapsulation section above, then process according to mechanism
defined by that OID (if the OID is recognized). The processing defined by that OID (if the OID is recognized). The processing
is outside the scope of this specification. Otherwise, strip is outside the scope of this specification. Otherwise, strip
off GSS framing. off GSS framing.
- find KDC for specified realm - find KDC for specified realm (if KDC IP address cannot be
obtained, send a KRB_ERROR message with error code
KRB_IAKERB_ERR_KDC_NOT_FOUND to the client).
- send to KDC (storing client IP address, port, and indication - send to KDC (storing client IP address, port, and indication
whether IAKERB proxy option or minimal messages option is whether IAKERB proxy option or minimal messages option is
being used) being used)
- retry with same or another KDC if no response is received 2. For - retry with same or another KDC if no response is received. If
received KDC_REP messages the retries also fail, send an error message with error code
KRB_IAKERB_ERR_KDC_NO_RESPONSE to the client.
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) 3. - send to client (using the stored client IP address and port)
For received AP_REQ and AP_REP messages
3. For received AP_REQ and AP_REP messages
- process locally per RFC 1964 - process locally per RFC 1964
Clients: 1. For sending KDC_REQ messages
Clients:
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 corresponding to the protocol option).
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 3. For - process inner Kerberos message according to RFC 1510
received AP_REQ and AP_REP messages
3. For received AP_REQ and AP_REP messages
- process locally per RFC 1964 - process locally per RFC 1964
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 [8] may be used to
securely negotiate between the protocols. A compliant IAKERB server securely negotiate between the protocols. A compliant IAKERB server
MAY support the IAKERB minimal messages protocol. 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 extend the technique used in Hornstein [5]. The client indicates
that the minimal message sub-protocol will be used by using the that the minimal message sub-protocol will be used by using the
appropriate OID as described above. The client sends the GSS appropriate OID as described above. The client sends the GSS
encapsulated AS_REQ message to the IAKERB proxy, and the IAKERB proxy encapsulated AS_REQ message to the IAKERB proxy, and the IAKERB proxy
processes the GSS framing (as described above for the IAKERB proxy processes the GSS framing (as described above for the IAKERB proxy
option) and forwards the AS_REQ message to the KDC. option) and forwards the AS_REQ message to the KDC.
The IAKERB proxy will proxy the returned message (AS_REP or KRB- The IAKERB proxy will proxy the returned message (AS_REP or
ERROR) from the KDC back to the client (after processing and removing KRB_ERROR) from the KDC back to the client (after processing and
the GSS framing). The protocol is complete in the KRB-ERROR case removing the GSS framing). The protocol is complete in the KRB_ERROR
(from the server perspective, but the client should retry depending case (from the server perspective, but the client should retry
on the error type). In the AS_REP case, the IAKERB proxy will obtain depending on the error type). In the AS_REP case, the IAKERB proxy
the client's TGT from the AS_REP message before forwarding the AS_REP will obtain the client's TGT from the AS_REP message before
message to the client. The IAKERB proxy then sends a TGS_REQ message forwarding the AS_REP message to the client. The IAKERB proxy then
with the client's TGT in the additional tickets field to the client's sends a TGS_REQ message with the client's TGT in the additional
KDC (ENC-TKT-IN-SKEY option). 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. Ultimately, the IAKERB proxy either proxies a
KRB-ERROR message to the client, or it sends a GSS Initial Context KRB_ERROR message to the client, or it sends a GSS Initial Context
token containing an AP_REQ message to the client. The IAKERB proxy token containing an AP_REQ message to the client. (Note: although the
MUST set the MUTUAL AUTH flag in the Initial Context token in order server sends the initial context token, the client is the initiator.)
to cause the client to authenticate as well. The client will reply The IAKERB proxy MUST set the MUTUAL AUTH flag in the Initial Context
with the GSSAPI enscapsulated AP_REP message, if the IAKERB proxy's token in order to cause the client to authenticate as well. The
authentication succeeds. If all goes well, then, in order to enable client will reply with the GSSAPI enscapsulated AP_REP message, if
subsequent efficient client authentications, the IAKERB proxy will the IAKERB proxy's authentication succeeds. If all goes well, then,
then send a final message of type KRB-TKT-PUSH containing a Kerberos in order to enable subsequent efficient client authentications, the
ticket (the reverse ticket) that has the IAKERB client principal IAKERB proxy will then send a final message of type KRB_TKT_PUSH
identifier in the client identifier field of the ticket and its own containing a Kerberos ticket (the reverse ticket) that has the IAKERB
principal identity in the server identifier field of the ticket: client principal identifier in the client identifier field of the
ticket and its own principal identity in the server identifier field
of the ticket:
KRB-TKT-PUSH :: = 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 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 unless the
IAKERB proxy has included the client's address in the TGS_REQ message IAKERB proxy has included the client's address in the TGS_REQ message
to the KDC). Sending the reverse ticket allows the client to to the KDC). Sending the reverse ticket allows the client to
efficiently initiate subsequent reauthentication attempts with a efficiently initiate subsequent reauthentication attempts with a
RFC1964 AP_REQ message. Note that the TKT-PUSH message is sent after RFC1964 AP_REQ message. Note that the TKT_PUSH message is sent after
mutual authentication and key establishment are complete. mutual authentication and key establishment are complete.
(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. The protocol then continues as in
the minimal messages AS_REQ case described above (see Figure 2); the the minimal messages AS_REQ case described above (see Figure 2); the
IAKERB proxy's TGS_REQ message contains the client's TGT in the IAKERB proxy's TGS_REQ message contains the client's TGT in the
additional tickets field (ENC-TKT-IN-SKEY option). The IAKERB proxy additional tickets field (ENC-TKT-IN-SKEY option). The IAKERB proxy
then receives the TGS_REP message from the KDC and then sends a RFC then receives the TGS_REP message from the KDC and then sends a RFC
1964 AP_REQ message to the client (with the MUTUAL AUTH flag set - 1964 AP_REQ message to the client (with the MUTUAL AUTH flag set -
see AS_REQ case). see AS_REQ case).
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
skipping to change at page 8, line 19 skipping to change at page 8, line 50
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. References 11. Acknowledgements
We thank Ken Raeburn for his helpful comments.
12. 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 Interface",
RFC 2078. RFC 2078.
[4] B. Tung, C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky, J. Wray, [4] B. Tung, C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky, J. Wray,
J. Trostle, "Public Key Cryptography for Initial Authentication in J. Trostle, "Public Key Cryptography for Initial Authentication in
Kerberos", Internet Draft draft-ietf-cat-kerberos-pkinit-12.txt. Kerberos", WORK IN PROGRESS Internet Draft
draft-ietf-cat-kerberos-pkinit-12.txt.
[5] K. Hornstein, T. Lemon, B. Aboba, J. Trostle, "DHCP Authentication [5] K. Hornstein, T. Lemon, B. Aboba, J. Trostle, "DHCP Authentication
via Kerberos V", Internet Draft draft-hornstein-dhc-kerbauth-02.txt. via Kerberos V", WORK IN PROGRESS Internet Draft
draft-hornstein-dhc-kerbauth-02.txt.
[6] S. Bradner, "The Internet Standards Process -- Revision 3", BCP [6] 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 [7] 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 [8] E. Baize, D. Pinkas, "The Simple and Protected GSS-API Negotiation
Mechanism," RFC 2478, December 1998. Mechanism," RFC 2478, December 1998.
skipping to change at page 9, line 16 skipping to change at page 9, line 54
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 September 30th, 2001. This draft expires on January 31st, 2002.
 End of changes. 35 change blocks. 
75 lines changed or deleted 111 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/