draft-ietf-cat-iakerb-05.txt   draft-ietf-cat-iakerb-06.txt 
INTERNET-DRAFT Mike Swift INTERNET-DRAFT Mike Swift
draft-ietf-cat-iakerb-05.txt University of WA draft-ietf-cat-iakerb-06.txt University of WA
Updates: RFC 1510 Jonathan Trostle Updates: RFC 1510 Jonathan Trostle
November 2000 Cisco Systems March 2001 Cisco Systems
Bernard Aboba Bernard Aboba
Microsoft Microsoft
Glen Zorn Glen Zorn
Cisco Systems Cisco Systems
Initial Authentication and Pass Through Authentication Initial and Pass Through Authentication Using Kerberos V5 and the GSS-API
Using Kerberos V5 and the GSS-API (IAKERB) (IAKERB)
<draft-ietf-cat-iakerb-06.txt>
0. Status Of This Memo Status of this Memo
This document is an Internet-Draft and is in full conformance This document is an Internet-Draft and is in full conformance with
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 other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other and may be updated, replaced, or obsoleted by other documents at any
documents at any time. It is inappropriate to use Internet- time. It is inappropriate to use Internet- Drafts as reference
Drafts as reference material or to cite them other than as material or to cite them other than as "work in progress."
"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 May 31st, 2001. Please send comments to the This draft expires on September 30th, 2001. Please send comments to
authors. the authors.
1. Abstract 1. Abstract
This document defines an extension to the Kerberos protocol This document defines an extension to the Kerberos protocol
specification (RFC 1510 [1]) and GSSAPI Kerberos mechanism (RFC specification (RFC 1510 [1]) and GSSAPI Kerberos mechanism (RFC 1964
1964 [2]) that enables a client to obtain Kerberos tickets for [2]) that enables a client to obtain Kerberos tickets for services
services where the KDC is not accessible. Some common scenarios where the KDC is not accessible to the client, but is accessible to
where lack of accessibility would occur are when the client does the application server. Some common scenarios where lack of
not have an IP address prior to authenticating to an access point, accessibility would occur are when the client does not have an IP
or a KDC is behind a firewall. The document specifies two address prior to authenticating to an access point, the client is
protocols to allow a client to exchange KDC messages with an unable to locate a KDC, or a KDC is behind a firewall. The document
IAKERB proxy instead of a KDC. specifies two protocols to allow a client to exchange KDC messages
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 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
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 When authenticating using Kerberos V5, clients obtain tickets from a
a KDC and present them to services. This method of operation works KDC and present them to services. This method of operation works well
well in many situations, but is not always applicable. The in many situations, but is not always applicable. The following is a
following is a list of 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 unable to directly contact the KDC either because it does not have an
an IP address or it is unable to send packets to the KDC, before IP address, or the access point packet filter does not allow the
it authenticates to the access point. Two protocols in this proposal client to send packets to the Internet before it authenticates to the
address this problem: the IAKERB proxy option and the IAKERB access point.
minimal messages option. In the IAKERB proxy option (see
Figure 1) an application server called the IAKERB proxy acts as a (2) A KDC is behind a firewall so the client will send Kerberos
protocol gateway and proxies Kerberos messages back and forth messages to the IAKERB proxy which will transmit the KDC request and
between the client and the KDC. The IAKERB proxy is also reply messages between the client and the KDC. (The IAKERB proxy is a
responsible for locating the KDC and may additionally perform special type of Kerberos application server that also relays KDC
other application proxy level functions such as auditing. request and reply messages between a client and the KDC).
4. Overview
This proposal specifies two protocols that address the above
scenarios: the IAKERB proxy option and the IAKERB minimal messages
option. In the IAKERB proxy option (see Figure 1) an application
server called the IAKERB proxy acts as a protocol gateway and proxies
Kerberos messages back and forth between the client and the KDC. The
IAKERB proxy is also responsible for locating the KDC and may
additionally perform other application proxy level functions such as
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 second protocol is the minimal messages protocol that extends the
the technique in [5]; this protocol should be considered for message technique in [5]; this protocol is targetted at environments where
constrained environments. Here the client sends a ticket granting the number of messages (prior to key establishment) needs to be
ticket (TGT) to the IAKERB proxy which then includes the client's TGT minimized. Here the client sends its ticket granting ticket (TGT) to
as an additional ticket in a TGS request to the KDC. The TGS reply will the IAKERB proxy (in a KRB-TKT-PUSH message) for the TGS case. The
provide the IAKERB proxy with a service ticket from itself targetted IAKERB proxy then sends a TGS_REQ to the KDC with the client's TGT in
at the client. An AP exchange between the IAKERB proxy and the client the additional tickets field of the TGS_REQ message. As a result, the
is then used to complete mutual authentication (see Figure 2). Thus returned ticket will list the client as the ticket's server
mutual authentication is accomplished with three messages instead of principal, and will be encrypted with the session key from the
four (or possibly more in the crossrealm case) between the client and client's TGT. The IAKERB proxy then uses this ticket to generate an
the IAKERB proxy. AP request that is sent to the client (see Figure 2). Thus mutual
authentication is accomplished with three messages between the client
and the IAKERB proxy versus four or more (the difference is larger if
crossrealm operations are involved). Subsequent to mutual
authentication and key establishment, the IAKERB proxy sends a ticket
to the client (in a KRB-TKT-PUSH message) that contains the same
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
the IAKERB proxy. Its purpose is to enable fast subsequent re-
authentication by the client to the application server (using the
conventional AP request AP reply exchange) for subsequent sessions.
In addition to minimizing the number of messages, a secondary goal is
to minimize the number of bytes transferred between the client and
the IAKERB proxy prior to 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.
(2) A KDC is behind a firewall so the client will send Kerberos The AS_REQ case for the minimal messages option is similar, where the
messages to the IAKERB proxy which will proxy the KDC request and client sends up the AS_REQ message and the IAKERB proxy forwards it
reply messages (using the IAKERB proxy option). 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
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
TGS_REQ message.
(3) Optionally, IAKERB MAY be used in a scenario where the Kerberos Client --------> IAKERB proxy
client does not know the server principal realm for a TGS request. TKT-PUSH (w/ TGT)
Here the client may send the TGS_REQ message to the application
server with a zero length realm name in the request body. The
application server MAY send a KDC_ERR_WRONG_REALM error back to the
client which will include the application server's realm in the
realm field of the KRB_ERROR message.
A compliant IAKERB proxy is not required to support the functionality Client IAKERB proxy --------------------> KDC
in (3), but is required to support the IAKERB proxy and IAKERB minimal TGS_REQ with client
messages protocols. In general, the existing Kerberos paradigm where TGT as additional TGT
clients contact the KDC to obtain service tickets should be preserved
where possible.
4. GSSAPI Encapsulation Client IAKERB proxy <-------------------- KDC
TGS_REP with service
ticket
The mechanism ID for IAKERB proxy GSS-API Kerberos, in Client <-------- IAKERB proxy KDC
accordance with the mechanism proposed by SPNEGO for negotiating AP_REQ
protocol variations, is:
{iso(1) member-body(2) United States(840) mit(113554) infosys(1) Client --------> IAKERB proxy KDC
gssapi(2) krb5(2) initialauth(4)}. AP_REP
The proposed mechanism ID for minimal messages IAKERB GSS-API
Kerberos, in accordance with the mechanism proposed by SPNEGO for -------------------------------------------------------------
negotiating protocol variations, is: post-key establishment and application data flow phase:
{iso(1) member-body(2) United States(840) mit(113554) infosys(1)
gssapi(2) krb5(2) initialauthminmessages(5)}. Client <-------- IAKERB proxy KDC
TKT-PUSH (w/ticket targetted at IAKERB proxy
to enable fast subsequent authentication)
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
The mechanism ID for IAKERB proxy GSS-API Kerberos, in accordance
with the mechanism proposed by SPNEGO [8] for negotiating protocol
variations, is: {iso(1) member-body(2) United States(840)
mit(113554) infosys(1) gssapi(2) krb5(2) initialauth(4)}. The
proposed mechanism ID for minimal messages IAKERB GSS-API Kerberos,
in accordance with the mechanism proposed by SPNEGO for negotiating
protocol variations, is: {iso(1) member-body(2) United States(840)
mit(113554) infosys(1) gssapi(2) krb5(2) initialauthminmessages(5)}.
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 ::= InitialContextToken ::= [APPLICATION 0] IMPLICIT SEQUENCE {
[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, below), followed by the Kerberos V5 KRB-AS-REQ, KRB-AS-REP, KRB-TGS-
KRB-TGS-REQ, or KRB-TGS-REP messages, as appropriate. The TOK_ID field REQ, or KRB-TGS-REP messages, as appropriate. The TOK_ID field shall
shall be one of the following values, to denote that the message is be one of the following values, to denote that the message is either
either a request to the KDC or a response from the KDC. 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
5. The IAKERB proxy protocol We also define the token ID for the KRB-TKT-PUSH message (defined
below and used in the minimal messages variation):
The IAKERB proxy will proxy Kerberos KDC request, KDC reply, and KRB_ERROR Message TOK_ID
messages back and forth between the client and the KDC as illustrated in
Figure 1. Messages received from the client must first have the Kerberos
GSS header (RFC1964 [2]) stripped off. The unencapsulated message will
then be forwarded to a KDC. The IAKERB proxy is responsible for locating
an appropriate KDC using the realm information in the KDC request message
it received from the client. In addition, the IAKERB proxy SHOULD implement
the retry algorithm for KDC requests over UDP. For messages sent by the
KDC, the IAKERB proxy encapsulates them with a Kerberos GSS header
before sending them to the client.
6. The IAKERB minimal messages protocol KRB-TKT-PUSH 02 03
The IAKERB protocol consists of two sub-protocols: the proxy sub-protocol, For completeness, we list the other RFC 1964 defined token ID's here:
and the minimal messages sub-protocol. The client should initiate the
IAKERB minimal messages sub-protocol when the number of messages must be
minimized (the most significant reduction in the number of messages can
occur when the client and the IAKERB proxy are in different realms).
The determination of the sub-protocol to use is completely up to the Message TOK_ID
client, and a compliant IAKERB proxy server MUST support both protocols.
(a) AS_REQ case: AP_REQ 01 00
AP_REP 02 00
KRB_ERROR 03 00
6. The IAKERB proxy protocol
The IAKERB proxy will proxy Kerberos KDC request, KDC reply, and
KRB_ERROR messages back and forth between the client and the KDC as
illustrated in Figure 1. Messages received from the client must first
have the Kerberos GSS header (RFC1964 [2]) stripped off. The
unencapsulated message will then be forwarded to a KDC. The IAKERB
proxy is responsible for locating an appropriate KDC using the realm
information in the KDC request message it received from the client.
In addition, the IAKERB proxy SHOULD implement a retry algorithm for
KDC requests over UDP (including selection of alternate KDC's if the
initial KDC does not respond to its requests). For messages sent by
the KDC, the IAKERB proxy encapsulates them with a Kerberos GSS
header before sending them to the client.
To summarize, the sequence of steps for processing is as follows:
Servers: 1. For received KDC_REQ messages (with token ID 00 03)
- process GSS framing (check OID)
if the OID is not one of the two OID's specified in the GSSAPI
Encapsulation section above, then process according to mechanism
defined by that OID (if the OID is recognized). The processing
is outside the scope of this specification. Otherwise, strip
off GSS framing.
- find KDC for specified realm
- send to KDC (storing client IP address, port, and indication
whether IAKERB proxy option or minimal messages option is
being used)
- retry with same or another KDC if no response is received 2. For
received KDC_REP messages
- encapsulate with GSS framing, using token ID 01 03 and the OID
that corresponds to the stored protocol option
- send to client (using the stored client IP address and port) 3.
For received AP_REQ and AP_REP messages
- process locally per RFC 1964
Clients: 1. For sending KDC_REQ messages
- create AS_REQ or TGS_REQ message
- encapsulate with GSS framing (token ID 00 03 and OID
corresponding
to the protocol option).
- send to server 2. For received KDC_REP messages
- decapsulate by removing GSS framing (token ID 01 03)
- process inner Kerberos message according to RFC 1510 3. For
received AP_REQ and AP_REP messages
- process locally per RFC 1964
7. The IAKERB minimal messages protocol
The client MAY initiate the IAKERB minimal messages variation when
the number of messages must be minimized (the most significant
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
securely negotiate between the 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)
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. appropriate OID as described above. The client sends the GSS
encapsulated AS_REQ message to the IAKERB proxy, and the IAKERB proxy
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 KRB-ERROR) The IAKERB proxy will proxy the returned message (AS_REP or KRB-
from the KDC back to the client. The protocol is complete in the ERROR) from the KDC back to the client (after processing and removing
KRB-ERROR case. In the AS_REP case, the IAKERB proxy will obtain the the GSS framing). The protocol is complete in the KRB-ERROR case
client's TGT from the AS_REP message before forwarding it to the client. (from the server perspective, but the client should retry depending
The IAKERB proxy then sends a TGS_REQ message with the client's TGT in on the error type). In the AS_REP case, the IAKERB proxy will obtain
the additional tickets field to the client's KDC (ENC-TKT-IN_SKEY the client's TGT from the AS_REP message before forwarding the AS_REP
option). message to the client. 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. 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. The IAKERB proxy
MUST set the MUTUAL AUTH flag in the Initial Context token in order MUST set the MUTUAL AUTH flag in the Initial Context token in order
to cause the client to authenticate as well. The client will reply to cause the client to authenticate as well. The client will reply
with the GSSAPI enscapsulated AP_REP message, if the IAKERB proxy's with the GSSAPI enscapsulated AP_REP message, if the IAKERB proxy's
authentication succeeds. If all goes well, then, in order to enable authentication succeeds. If all goes well, then, in order to enable
subsequent efficient client authentications, the IAKERB proxy will subsequent efficient client authentications, the IAKERB proxy will
then send a final message of type KERB-TGT-REPLY containing a then send a final message of type KRB-TKT-PUSH containing a Kerberos
Kerberos ticket that is the reverse ticket of the ticket that the ticket (the reverse ticket) that has the IAKERB client principal
IAKERB proxy used to authenticate itself to the client: identifier in the client identifier field of the ticket and its own
principal identity in the server identifier field of the ticket:
KERB-TGT-REPLY :: = SEQUENCE { KRB-TKT-PUSH :: = SEQUENCE {
pvno[0] INTEGER, -- 5 pvno[0] INTEGER, -- 5 (protocol version)
msg-type[1] INTEGER, -- 17 msg-type[1] INTEGER, -- 17 (message type)
ticket[2] Ticket ticket[2] Ticket
} }
The encryption key for the reverse ticket is the IAKERB proxy's long The key used to encrypt the reverse ticket is a long term secret key
term key. The fields are identical to the AP_REQ ticket, except the chosen by the IAKERB proxy. The fields are identical to the AP_REQ
client name will be switched with the server name, and the server ticket, except the client name will be switched with the server name,
realm will be switched with the client realm. (The one other exception and the server realm will be switched with the client realm. (The one
is that addresses should not be copied unless the IAKERB proxy has other exception is that addresses should not be copied unless the
included the client's address in the TGS_REQ message to the KDC). IAKERB proxy has included the client's address in the TGS_REQ message
Sending the reverse ticket allows the client to efficiently initiate to the KDC). Sending the reverse ticket allows the client to
subsequent reauthentication attempts with a RFC1964 AP_REQ message. efficiently initiate subsequent reauthentication attempts with a
Note that the TGT-REPLY message is sent after mutual authentication RFC1964 AP_REQ message. Note that the TKT-PUSH message is sent after
and key establishment are complete. mutual authentication and key establishment are complete.
(b) TGS_REQ case: (b) TGS_REQ case: (used when the client has a TGT)
ii. Minimal messages sub-protocol:
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 KERB-TGT-REPLY message to the IAKERB proxy in initially sends a KRB-TKT-PUSH message (with the GSS header) to the
order to send it a TGT. The IAKERB proxy will obtain the client's IAKERB proxy in order to send it a TGT. The IAKERB proxy will obtain
TGT from the KERB-TGT-REPLY message and then proceed to send a the client's TGT from the KRB-TKT-PUSH message and then proceed to
TGS_REQ message to the appropriate KDC (in either the client realm send a TGS_REQ message to a KDC where the realm of the KDC is equal
or its own realm) as in the AS_REQ case above. The protocol then to the realm from the server realm field in the TGT sent by the
continues as in the minimal messages AS_REQ case described above client in the KRB-TKT-PUSH message. The protocol then continues as in
(see Figure 2): 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
Client --------> IAKERB proxy additional tickets field (ENC-TKT-IN-SKEY option). The IAKERB proxy
TGT 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 -
Client IAKERB proxy --------------------> KDC see AS_REQ case).
TGS_REQ with client
TGT as additional TGT
Client IAKERB proxy <-------------------- KDC
TGS_REP with service
ticket
Client <-------- IAKERB proxy KDC
AP_REQ
Client --------> IAKERB proxy KDC
AP_REP
Figure 2: IAKERB Minimal Messages Option: TGS case
7. Determining Application Server Realm from Error Message
As a last resort (with respect to determining the realm name for
the application server), the application client MAY send a TGS_REQ
message to the application server where the request body realm name
has length 0. The application server MAY reply with a KRB_ERROR
message with error code KDC_ERR_WRONG_REALM where the realm field
contains the application server realm.
Sending a TGS_REQ message to the application server without a realm
name in the request, followed by a TGS request using the returned
realm name and then sending an AP request with a mutual authentication
flag should be subject to a local policy decision (see security
considerations below).
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 client in the case of initial authentication for a dial-up client, the
machine may not yet possess a network address. Hence, as allowed by client machine may not yet possess a network address. Hence, as
RFC1510 [1], the addresses field of the AS and TGS requests SHOULD be allowed by RFC1510 [1], the addresses field of the AS and TGS
blank and the caddr field of the ticket SHOULD similarly be left blank. 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
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. Combining IAKERB with Other Kerberos Extensions
This protocol is usable with other proposed Kerberos extensions such as This protocol is usable with other proposed Kerberos extensions such
PKINIT (Public Key Cryptography for Initial Authentication in Kerberos as PKINIT (Public Key Cryptography for Initial Authentication in
[4]). In such cases, the messages which would normally be sent to the Kerberos [4]). In such cases, the messages which would normally be
KDC are instead sent by the client application to the server, which sent to the KDC are instead sent by the client application to the
then forwards them to a KDC. server, which then forwards them to a KDC.
10. Security Considerations 10. Security Considerations
A principal is identified by its principal name and realm. A client In the minimal messages protocol option, the application server sends
that sends a TGS request to an application server (in the IAKERB proxy an AP_REQ message to the client. The ticket in the AP_REQ message
option) without the request realm name will only be able to mutually SHOULD NOT contain authorization data since some operating systems
authenticate the server up to its principal name. Thus when requesting may allow the client to impersonate the server and increase its own
mutual authentication, it is preferable if clients can either determine privileges. If the ticket from the server connotes any authorization,
the server realm name beforehand, use the referral mechanism, or apply then the minimal messages protocol should not be used. Also, the
some policy checks to the realm name obtained from the returned error minimal messages protocol may facilitate denial of service attacks in
message. some environments; to prevent these attacks, it may make sense for
the minimal messages protocol server to only accept a KRB_TGT_PUSH
message on a local network interface (to ensure that the message was
not sent from a remote malicious host).
11. Bibliography 11. References
[1] J. Kohl, C. Neuman. The Kerberos Network Authentication [1] J. Kohl, C. Neuman, "The Kerberos Network Authentication
Service (V5). Request for Comments 1510. Service (V5)", RFC 1510.
[2] J. Linn. The Kerberos Version 5 GSS-API Mechanism. Request [2] J. Linn, "The Kerberos Version 5 GSS-API Mechanism", RFC 1964.
for Comments 1964
[3] J. Linn. Generic Security Service Application Program Interface. [3] J. Linn, "Generic Security Service Application Program Interface",
Request for Comments 1508 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", 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", Internet Draft draft-hornstein-dhc-kerbauth-02.txt.
[6] Bradner, S., "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] Bradner, S., "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.
12. This draft expires on May 31st, 2001. [8] E. Baize, D. Pinkas, "The Simple and Protected GSS-API Negotiation
Mechanism," RFC 2478, December 1998.
13. Authors' Addresses 12. Author's Addresses
Michael Swift Michael Swift
University of Washington University of Washington
Seattle, WA Seattle, WA
Email: mikesw@cs.washington.edu 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.
skipping to change at line 332 skipping to change at page 9, line 4
University of Washington University of Washington
Seattle, WA Seattle, WA
Email: mikesw@cs.washington.edu 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
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
170 W. Tasman Dr. Bellevue, WA U.S.A.
San Jose, CA 95134, 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.
 End of changes. 51 change blocks. 
203 lines changed or deleted 295 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/