draft-ietf-cat-iakerb-03.txt   draft-ietf-cat-iakerb-04.txt 
INTERNET-DRAFT Mike Swift INTERNET-DRAFT Mike Swift
draft-ietf-cat-iakerb-03.txt Microsoft draft-ietf-cat-iakerb-04.txt Microsoft
Updates: RFC 1510 Jonathan Trostle Updates: RFC 1510 Jonathan Trostle
expires April 30, 2000 Cisco Systems July 2000 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.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at line 31 skipping to change at line 31
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.
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:
(1) The client knows its principal name and password, but not (1) The client knows its principal name and password, but not
its realm name (applicable in the situation where a user is already 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 on the network but needs to authenticate to an ISP, and the user
skipping to change at line 163 skipping to change at line 164
request equal to its own realm if the realm name is known, request equal to its own realm if the realm name is known,
otherwise the realm length is set to 0. Upon receipt of the AS_REQ otherwise the realm length is set to 0. Upon receipt of the AS_REQ
message, the application server checks if the client has included message, the application server checks if the client has included
a realm. a realm.
If the realm was not included in the original request, the If the realm was not included in the original request, the
application server must determine the realm and add it to the application server must determine the realm and add it to the
AS_REQ message before forwarding it. If the application server AS_REQ message before forwarding it. If the application server
cannot determine the client realm, it returns the cannot determine the client realm, it returns the
KRB_AP_ERR_REALM_REQUIRED error-code in an error message to KRB_AP_ERR_REALM_REQUIRED error-code in an error message to
the client): the client:
KRB_AP_ERR_REALM_REQUIRED 77 KRB_AP_ERR_REALM_REQUIRED 77
The error message can be sent in response to either an AS_REQ The error message can be sent in response to either an AS_REQ
message, in which case the e-data is empty; or in response to message, or in response to a TGS_REQ message, in which case the
a TGS_REQ message, in which case the e-data will contain the realm and principal name of the application server are placed
realm of the application server encoded as an OCTET STRING. into the realm and sname fields respectively, of the KRB-ERROR
Once the realm is filled in, the application server forwards message. In the AS_REQ case, once the realm is filled in, the
the request to a KDC in the user's realm. It will retry the application server forwards the request to a KDC in the user's
request if necessary, and forward the KDC response back to realm. It will retry the request if necessary, and forward the
the client. KDC response back to the client.
At the time the user enters a username and password, the client At the time the user enters a username and password, the client
should create a new credential with an INTERNAL NAME [3] that can should create a new credential with an INTERNAL NAME [3] that can
be used as an input into the GSS_Acquire_cred function call. be used as an input into the GSS_Acquire_cred function call.
This functionality is useful when there is no trust relationship This functionality is useful when there is no trust relationship
between the user's logon realm and the target realm (Figure 2). between the user's logon realm and the target realm (Figure 2).
User Realm KDC User Realm KDC
/ /
skipping to change at line 208 skipping to change at line 209
b. The user does not supply a password (TGS_REQ): The user includes a b. The user does not supply a password (TGS_REQ): The user includes a
TGT targetted at the user's realm, or an intermediate realm, in a TGT targetted at the user's realm, or an intermediate realm, in a
TGS_REQ message. The TGS_REQ message is sent to the application TGS_REQ message. The TGS_REQ message is sent to the application
server. server.
If the client has included the realm name in the TGS request, then If the client has included the realm name in the TGS request, then
the application server will forward the request to a KDC in the the application server will forward the request to a KDC in the
request TGT srealm. It will forward the response back to the client. 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, If the client has not included the realm name in the TGS request,
then the application server will return its realm name to the then the application server will return its realm name and principal
client using the KRB_AP_ERR_REALM_REQUIRED error described above. name to the client using the KRB_AP_ERR_REALM_REQUIRED error
The error message e-data field contains the application server described above. Sending a TGS_REQ message to the application server
realm name. Note that another principal with the same principal without a realm name in the request, followed by a TGS request using
name and a different realm than the intended application server the returned realm name and then sending an AP request with a mutual
can replace the realm name with its own, thus setting the stage authentication flag should be subject to a local policy decision
for an impersonation attack. Therefore, sending a TGS_REQ message (see security considerations below). Using the returned server
to the application server without a realm name in the request principal name in a TGS request followed by sending an AP request
is a last resort (see security considerations below). message using the received ticket MUST NOT set any mutual
authentication flags.
The client can now proceed using conventional Kerberos with the
realm name from the error message.
6. Addresses in Tickets 6. 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
skipping to change at line 245 skipping to change at line 244
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 by the GSS runtime are instead sent by the client application to the
server, which then forwards them to a KDC. server, which then forwards them to a KDC.
8. Security Considerations 8. 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 without the request
realm name will only be able to mutually authenticate the server realm name will only be able to mutually authenticate the server
up to its principal name; another server with the same principal name up to its principal name. Thus when requesting mutual authentication,
and a different realm name, that has a trust relationship with the it is preferable if clients can either determine the server realm name
client, will be able to impersonate the intended application server. beforehand, or apply some policy checks to the realm name obtained from
Thus, such requests should only be used as a last resort. the returned error message.
9. Bibliography 9. 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, http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-
pkinit-10.txt. pkinit-10.txt.
10. Expires April 30, 2000. 10. This draft expires on January 31st, 2001.
11. Authors' Addresses 11. Authors' Addresses
Michael Swift Michael Swift
Microsoft Microsoft
One Microsoft Way One Microsoft Way
Redmond, Washington, 98052, U.S.A. Redmond, Washington, 98052, U.S.A.
Email: mikesw@microsoft.com Email: mikesw@microsoft.com
Jonathan Trostle Jonathan Trostle
 End of changes. 8 change blocks. 
27 lines changed or deleted 27 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/