draft-ietf-cat-iakerb-04.txt   draft-ietf-cat-iakerb-05.txt 
INTERNET-DRAFT Mike Swift INTERNET-DRAFT Mike Swift
draft-ietf-cat-iakerb-04.txt Microsoft draft-ietf-cat-iakerb-05.txt University of WA
Updates: RFC 1510 Jonathan Trostle Updates: RFC 1510 Jonathan Trostle
July 2000 Cisco Systems November 2000 Cisco Systems
Bernard Aboba
Microsoft
Glen Zorn
Cisco Systems
Initial Authentication and Pass Through Authentication Initial Authentication and Pass Through Authentication
Using Kerberos V5 and the GSS-API (IAKERB) Using Kerberos V5 and the GSS-API (IAKERB)
0. Status Of This Memo 0. 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 all provisions of Section 10 of RFC2026. with 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-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as Drafts as reference 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 January 31st, 2001. This draft expires on May 31st, 2001. Please send comments to 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 [2]) that enables a client to obtain Kerberos tickets for 1964 [2]) that enables a client to obtain Kerberos tickets for
services where: services where the KDC is not accessible. Some common scenarios
where lack of accessibility would occur are when the client does
not have an IP address prior to authenticating to an access point,
or a KDC is behind a firewall. The document specifies two
protocols to allow a client to exchange KDC messages with an
IAKERB proxy instead of a KDC.
(1) The client knows its principal name and password, but not 2. Conventions used in this document
its realm name (applicable in the situation where a user is already
on the network but needs to authenticate to an ISP, and the user
does not know his ISP realm name).
(2) The client is able to obtain the IP address of the service in
a realm which it wants to send a request to, but is otherwise unable
to locate or communicate with a KDC in the service realm or one of
the intermediate realms. (One example would be a dial up user who
does not have direct IP connectivity).
(3) The client does not know the realm name of the service.
2. Motivation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC2119 [7].
3. Motivation
When authenticating using Kerberos V5, clients obtain tickets from When authenticating using Kerberos V5, clients obtain tickets from
a KDC and present them to services. This method of operation works a KDC and present them to services. This method of operation works
well in many situations, but is not always applicable since it well in many situations, but is not always applicable. The
requires the client to know its own realm, the realm of the target following is a list of scenarios that this proposal addresses:
service, the names of the KDC's, and to be able to connect to the
KDC's.
This document defines an extension to the Kerberos protocol
specification (RFC 1510) [1] that enables a client to obtain
Kerberos tickets for services where:
(1) The client knows its principal name and password, but not
its realm name (applicable in the situation where a user is already
on the network but needs to authenticate to an ISP, and the user
does not know his ISP realm name).
(2) The client is able to obtain the IP address of the service in
a realm which it wants to send a request to, but is otherwise unable
to locate or communicate with a KDC in the service realm or one of
the intermediate realms. (One example would be a dial up user who
does not have direct IP connectivity).
(3) The client does not know the realm name of the service.
In this proposal, the client sends KDC request messages directly (1) The client must initially authenticate to an access point in
to application servers if one of the above failure cases develops. order to gain full access to the network. Here the client may be
The application server acts as a proxy, forwarding messages back unable to directly contact the KDC either because it does not have
and forth between the client and various KDC's (see Figure 1). an IP address or it is unable to send packets to the KDC, before
it authenticates to the access point. Two protocols in this proposal
address this problem: 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 <---------> App Server <----------> KDC Client <---------> IAKERB proxy <----------> KDC
proxies
Figure 1: IAKERB proxying Figure 1: IAKERB proxying
In the case where the client has sent a TGS_REQ message to the The second protocol is the minimal messages protocol that extends
application server without a realm name in the request, the the technique in [5]; this protocol should be considered for message
application server will forward an error message to the client constrained environments. Here the client sends a ticket granting
with its realm name in the e-data field of the error message. ticket (TGT) to the IAKERB proxy which then includes the client's TGT
The client will attempt to proceed using conventional Kerberos. as an additional ticket in a TGS request to the KDC. The TGS reply will
provide the IAKERB proxy with a service ticket from itself targetted
3. When Clients Should Use IAKERB at the client. An AP exchange between the IAKERB proxy and the client
is then used to complete mutual authentication (see Figure 2). Thus
We list several, but possibly not all, cases where the client mutual authentication is accomplished with three messages instead of
should use IAKERB. In general, the existing Kerberos paradigm four (or possibly more in the crossrealm case) between the client and
where clients contact the KDC to obtain service tickets should the IAKERB proxy.
be preserved where possible.
(a) AS_REQ cases:
(i) The client is unable to locate the user's KDC or the KDC's
in the user's realm are not responding, or
(ii) The user has not entered a name which can be converted
into a realm name (and the realm name cannot be derived from
a certificate).
(b) TGS_REQ cases: (2) A KDC is behind a firewall so the client will send Kerberos
messages to the IAKERB proxy which will proxy the KDC request and
reply messages (using the IAKERB proxy option).
(i) the client determines that the KDC(s) in either an (3) Optionally, IAKERB MAY be used in a scenario where the Kerberos
intermediate realm or the service realm are not responding or client does not know the server principal realm for a TGS request.
the client is unable to locate a KDC, 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.
(ii) the client is not able to generate the application server A compliant IAKERB proxy is not required to support the functionality
realm name. in (3), but is required to support the IAKERB proxy and IAKERB minimal
messages protocols. In general, the existing Kerberos paradigm where
clients contact the KDC to obtain service tickets should be preserved
where possible.
4. GSSAPI Encapsulation 4. GSSAPI Encapsulation
The mechanism ID for IAKERB GSS-API Kerberos, in accordance with the The mechanism ID for IAKERB proxy GSS-API Kerberos, in
mechanism proposed by SPNEGO for negotiating protocol variations, is: accordance with the mechanism proposed by SPNEGO for negotiating
protocol variations, is:
{iso(1) member-body(2) United States(840) mit(113554) infosys(1) {iso(1) member-body(2) United States(840) mit(113554) infosys(1)
gssapi(2) krb5(2) initialauth(4)} 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"
skipping to change at line 147 skipping to change at line 149
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 field 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 message is 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. 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
5. The Protocol 5. The IAKERB proxy protocol
a. The user supplies a password (AS_REQ): Here the Kerberos client The IAKERB proxy will proxy Kerberos KDC request, KDC reply, and KRB_ERROR
will send an AS_REQ message to the application server if it cannot messages back and forth between the client and the KDC as illustrated in
locate a KDC for the user's realm, or such KDC's do not respond, Figure 1. Messages received from the client must first have the Kerberos
or the user does not enter a name from which the client can derive GSS header (RFC1964 [2]) stripped off. The unencapsulated message will
the user's realm name. The client sets the realm field of the then be forwarded to a KDC. The IAKERB proxy is responsible for locating
request equal to its own realm if the realm name is known, an appropriate KDC using the realm information in the KDC request message
otherwise the realm length is set to 0. Upon receipt of the AS_REQ it received from the client. In addition, the IAKERB proxy SHOULD implement
message, the application server checks if the client has included the retry algorithm for KDC requests over UDP. For messages sent by the
a realm. KDC, the IAKERB proxy encapsulates them with a Kerberos GSS header
before sending them to the client.
If the realm was not included in the original request, the 6. The IAKERB minimal messages protocol
application server must determine the realm and add it to the
AS_REQ message before forwarding it. If the application server
cannot determine the client realm, it returns the
KRB_AP_ERR_REALM_REQUIRED error-code in an error message to
the client:
KRB_AP_ERR_REALM_REQUIRED 77 The IAKERB protocol consists of two sub-protocols: the proxy sub-protocol,
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 error message can be sent in response to either an AS_REQ The determination of the sub-protocol to use is completely up to the
message, or in response to a TGS_REQ message, in which case the client, and a compliant IAKERB proxy server MUST support both protocols.
realm and principal name of the application server are placed
into the realm and sname fields respectively, of the KRB-ERROR
message. In the AS_REQ case, once the realm is filled in, the
application server forwards the request to a KDC in the user's
realm. It will retry the request if necessary, and forward the
KDC response back to the client.
At the time the user enters a username and password, the client (a) AS_REQ case:
should create a new credential with an INTERNAL NAME [3] that can
be used as an input into the GSS_Acquire_cred function call.
This functionality is useful when there is no trust relationship We extend the technique used in Hornstein [5]. The client indicates
between the user's logon realm and the target realm (Figure 2). that the minimal message sub-protocol will be used by using the
appropriate OID as described above.
User Realm KDC The IAKERB proxy will proxy the returned message (AS_REP or KRB-ERROR)
/ from the KDC back to the client. The protocol is complete in the
/ KRB-ERROR case. In the AS_REP case, the IAKERB proxy will obtain the
/ client's TGT from the AS_REP message before forwarding it to the client.
/ 2,3 The IAKERB proxy then sends a TGS_REQ message with the client's TGT in
1,4 / the additional tickets field to the client's KDC (ENC-TKT-IN_SKEY
Client<-------------->App Server option).
1 Client sends AS_REQ to App Server The IAKERB proxy MAY handle returned KRB-ERROR messages and retry the
2 App server forwards AS_REQ to User Realm KDC TGS request message. Ultimately, the IAKERB proxy either proxies a
3 App server receives AS_REP from User Realm KDC KRB-ERROR message to the client, or it sends a GSS Initial Context
4 App server sends AS_REP back to Client 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
to cause the client to authenticate as well. The client will reply
with the GSSAPI enscapsulated AP_REP message, if the IAKERB proxy's
authentication succeeds. If all goes well, then, in order to enable
subsequent efficient client authentications, the IAKERB proxy will
then send a final message of type KERB-TGT-REPLY containing a
Kerberos ticket that is the reverse ticket of the ticket that the
IAKERB proxy used to authenticate itself to the client:
Figure 2: IAKERB AS_REQ KERB-TGT-REPLY :: = SEQUENCE {
pvno[0] INTEGER, -- 5
msg-type[1] INTEGER, -- 17
ticket[2] Ticket
}
b. The user does not supply a password (TGS_REQ): The user includes a The encryption key for the reverse ticket is the IAKERB proxy's long
TGT targetted at the user's realm, or an intermediate realm, in a term key. The fields are identical to the AP_REQ ticket, except the
TGS_REQ message. The TGS_REQ message is sent to the application client name will be switched with the server name, and the server
server. realm will be switched with the client realm. (The one other exception
is that addresses should not be copied unless the IAKERB proxy has
included the client's address in the TGS_REQ message to the KDC).
Sending the reverse ticket allows the client to efficiently initiate
subsequent reauthentication attempts with a RFC1964 AP_REQ message.
Note that the TGT-REPLY message is sent after mutual authentication
and key establishment are complete.
If the client has included the realm name in the TGS request, then (b) TGS_REQ case:
the application server will forward the request to a KDC in the
request TGT srealm. It will forward the response back to the client.
If the client has not included the realm name in the TGS request, ii. Minimal messages sub-protocol:
then the application server will return its realm name and principal The client indicates that the minimal messages sub-protocol will be
name to the client using the KRB_AP_ERR_REALM_REQUIRED error used by using the appropriate OID as described above. The client
described above. Sending a TGS_REQ message to the application server initially sends a KERB-TGT-REPLY message to the IAKERB proxy in
without a realm name in the request, followed by a TGS request using order to send it a TGT. The IAKERB proxy will obtain the client's
the returned realm name and then sending an AP request with a mutual TGT from the KERB-TGT-REPLY message and then proceed to send a
authentication flag should be subject to a local policy decision TGS_REQ message to the appropriate KDC (in either the client realm
(see security considerations below). Using the returned server or its own realm) as in the AS_REQ case above. The protocol then
principal name in a TGS request followed by sending an AP request continues as in the minimal messages AS_REQ case described above
message using the received ticket MUST NOT set any mutual (see Figure 2):
authentication flags.
6. Addresses in Tickets Client --------> IAKERB proxy
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
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
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 client
machine may not yet possess a network address. Hence, as allowed by machine may not yet possess a network address. Hence, as allowed by
RFC1510 [1], the addresses field of the AS and TGS requests should be RFC1510 [1], the addresses field of the AS and TGS requests SHOULD be
blank and the caddr field of the ticket should similarly be left blank. blank and the caddr field of the ticket SHOULD similarly be left blank.
7. 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 as
PKINIT (Public Key Cryptography for Initial Authentication in Kerberos PKINIT (Public Key Cryptography for Initial Authentication in Kerberos
[4]). In such cases, the messages which would normally be sent to the [4]). In such cases, the messages which would normally be sent to the
KDC by the GSS runtime are instead sent by the client application to the KDC are instead sent by the client application to the server, which
server, which then forwards them to a KDC. then forwards them to a KDC.
8. Security Considerations 10. Security Considerations
A principal is identified by its principal name and realm. A client A principal is identified by its principal name and realm. A client
that sends a TGS request to an application server without the request that sends a TGS request to an application server (in the IAKERB proxy
realm name will only be able to mutually authenticate the server option) without the request realm name will only be able to mutually
up to its principal name. Thus when requesting mutual authentication, authenticate the server up to its principal name. Thus when requesting
it is preferable if clients can either determine the server realm name mutual authentication, it is preferable if clients can either determine
beforehand, or apply some policy checks to the realm name obtained from the server realm name beforehand, use the referral mechanism, or apply
the returned error message. some policy checks to the realm name obtained from the returned error
message.
9. Bibliography 11. Bibliography
[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). Request for Comments 1510.
[2] J. Linn. The Kerberos Version 5 GSS-API Mechanism. Request [2] J. Linn. The Kerberos Version 5 GSS-API Mechanism. Request
for Comments 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 Request for Comments 1508
[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, http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos- Kerberos", Internet Draft draft-ietf-cat-kerberos-pkinit-12.txt.
pkinit-10.txt.
10. This draft expires on January 31st, 2001. [5] K. Hornstein, T. Lemon, B. Aboba, J. Trostle, DHCP Authentication
via Kerberos V, Internet Draft draft-hornstein-dhc-kerbauth-02.txt.
11. Authors' Addresses [6] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
12. This draft expires on May 31st, 2001.
13. Authors' Addresses
Michael Swift Michael Swift
Microsoft University of Washington
One Microsoft Way Seattle, WA
Redmond, Washington, 98052, U.S.A. Email: mikesw@cs.washington.edu
Email: mikesw@microsoft.com
Jonathan Trostle Jonathan Trostle
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
Microsoft
One Microsoft Way
Redmond, Washington, 98052, U.S.A.
Email: bernarda@microsoft.com
Glen Zorn
Cisco Systems
170 W. Tasman Dr.
San Jose, CA 95134, U.S.A.
Email: gwz@cisco.com
Phone: (425) 468-0955
 End of changes. 43 change blocks. 
153 lines changed or deleted 205 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/