302 lines
12 KiB
Plaintext
302 lines
12 KiB
Plaintext
INTERNET-DRAFT Mike Swift
|
||
draft-ietf-cat-iakerb-04.txt Microsoft
|
||
Updates: RFC 1510 Jonathan Trostle
|
||
July 2000 Cisco Systems
|
||
|
||
|
||
Initial Authentication and Pass Through Authentication
|
||
Using Kerberos V5 and the GSS-API (IAKERB)
|
||
|
||
|
||
0. Status Of This Memo
|
||
|
||
This document is an Internet-Draft and is in full conformance
|
||
with all provisions of Section 10 of RFC2026.
|
||
|
||
Internet-Drafts are working documents of the Internet Engineering
|
||
Task Force (IETF), its areas, and its working groups. Note that
|
||
other groups may also distribute working documents as
|
||
Internet-Drafts.
|
||
|
||
Internet-Drafts are draft documents valid for a maximum of six
|
||
months and may be updated, replaced, or obsoleted by other
|
||
documents at any time. It is inappropriate to use Internet-
|
||
Drafts as reference material or to cite them other than as
|
||
"work in progress."
|
||
|
||
The list of current Internet-Drafts can be accessed at
|
||
http://www.ietf.org/ietf/1id-abstracts.txt
|
||
|
||
The list of Internet-Draft Shadow Directories can be accessed at
|
||
http://www.ietf.org/shadow.html.
|
||
|
||
This draft expires on January 31st, 2001.
|
||
|
||
|
||
1. Abstract
|
||
|
||
This document defines an extension to the Kerberos protocol
|
||
specification (RFC 1510 [1]) and GSSAPI Kerberos mechanism (RFC
|
||
1964 [2]) 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.
|
||
|
||
|
||
2. Motivation
|
||
|
||
When authenticating using Kerberos V5, clients obtain tickets from
|
||
a KDC and present them to services. This method of operation works
|
||
|
||
well in many situations, but is not always applicable since it
|
||
requires the client to know its own realm, the realm of the target
|
||
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
|
||
to application servers if one of the above failure cases develops.
|
||
The application server acts as a proxy, forwarding messages back
|
||
and forth between the client and various KDC's (see Figure 1).
|
||
|
||
|
||
Client <---------> App Server <----------> KDC
|
||
proxies
|
||
|
||
|
||
Figure 1: IAKERB proxying
|
||
|
||
|
||
In the case where the client has sent a TGS_REQ message to the
|
||
application server without a realm name in the request, the
|
||
application server will forward an error message to the client
|
||
with its realm name in the e-data field of the error message.
|
||
The client will attempt to proceed using conventional Kerberos.
|
||
|
||
3. When Clients Should Use IAKERB
|
||
|
||
We list several, but possibly not all, cases where the client
|
||
should use IAKERB. In general, the existing Kerberos paradigm
|
||
where clients contact the KDC to obtain service tickets should
|
||
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:
|
||
|
||
(i) the client determines that the KDC(s) in either an
|
||
intermediate realm or the service realm are not responding or
|
||
|
||
the client is unable to locate a KDC,
|
||
|
||
(ii) the client is not able to generate the application server
|
||
realm name.
|
||
|
||
|
||
4. GSSAPI Encapsulation
|
||
|
||
The mechanism ID for 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) initialauth(4)}
|
||
|
||
The AS request, AS reply, TGS request, and TGS reply messages are all
|
||
encapsulated using the format defined by RFC1964 [2]. This consists
|
||
of the GSS-API token framing defined in appendix B of RFC1508 [3]:
|
||
|
||
InitialContextToken ::=
|
||
[APPLICATION 0] IMPLICIT SEQUENCE {
|
||
thisMech MechType
|
||
-- MechType is OBJECT IDENTIFIER
|
||
-- representing "Kerberos V5"
|
||
innerContextToken ANY DEFINED BY thisMech
|
||
-- contents mechanism-specific;
|
||
-- ASN.1 usage within innerContextToken
|
||
-- is not required
|
||
}
|
||
|
||
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-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
|
||
either a request to the KDC or a response from the KDC.
|
||
|
||
Message TOK_ID
|
||
KRB-KDC-REQ 00 03
|
||
KRB-KDC-REP 01 03
|
||
|
||
|
||
5. The Protocol
|
||
|
||
a. The user supplies a password (AS_REQ): Here the Kerberos client
|
||
will send an AS_REQ message to the application server if it cannot
|
||
locate a KDC for the user's realm, or such KDC's do not respond,
|
||
or the user does not enter a name from which the client can derive
|
||
the user's realm name. The client sets the realm field of the
|
||
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
|
||
message, the application server checks if the client has included
|
||
a realm.
|
||
|
||
If the realm was not included in the original request, the
|
||
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 error message can be sent in response to either an AS_REQ
|
||
message, or in response to a TGS_REQ message, in which case the
|
||
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
|
||
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
|
||
between the user's logon realm and the target realm (Figure 2).
|
||
|
||
|
||
User Realm KDC
|
||
/
|
||
/
|
||
/
|
||
/ 2,3
|
||
1,4 /
|
||
Client<-------------->App Server
|
||
|
||
|
||
1 Client sends AS_REQ to App Server
|
||
2 App server forwards AS_REQ to User Realm KDC
|
||
3 App server receives AS_REP from User Realm KDC
|
||
4 App server sends AS_REP back to Client
|
||
|
||
|
||
Figure 2: IAKERB AS_REQ
|
||
|
||
|
||
|
||
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
|
||
TGS_REQ message. The TGS_REQ message is sent to the application
|
||
server.
|
||
|
||
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
|
||
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,
|
||
then the application server will return its realm name and principal
|
||
name to the client using the KRB_AP_ERR_REALM_REQUIRED error
|
||
described above. 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). Using the returned server
|
||
principal name in a TGS request followed by sending an AP request
|
||
message using the received ticket MUST NOT set any mutual
|
||
authentication flags.
|
||
|
||
|
||
6. Addresses in Tickets
|
||
|
||
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
|
||
addresses in any KDC requests for two reasons. First, the KDC may
|
||
reject the forwarded request as being from the wrong client. Second,
|
||
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
|
||
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.
|
||
|
||
|
||
7. Combining IAKERB with Other Kerberos Extensions
|
||
|
||
This protocol is usable with other proposed Kerberos extensions such as
|
||
PKINIT (Public Key Cryptography for Initial Authentication in Kerberos
|
||
[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
|
||
server, which then forwards them to a KDC.
|
||
|
||
|
||
8. Security Considerations
|
||
|
||
A principal is identified by its principal name and realm. A client
|
||
that sends a TGS request to an application server without the request
|
||
realm name will only be able to mutually authenticate the server
|
||
up to its principal name. Thus when requesting mutual authentication,
|
||
it is preferable if clients can either determine the server realm name
|
||
beforehand, or apply some policy checks to the realm name obtained from
|
||
the returned error message.
|
||
|
||
|
||
9. Bibliography
|
||
|
||
[1] J. Kohl, C. Neuman. The Kerberos Network Authentication
|
||
Service (V5). Request for Comments 1510.
|
||
|
||
[2] J. Linn. The Kerberos Version 5 GSS-API Mechanism. Request
|
||
for Comments 1964
|
||
|
||
[3] J. Linn. Generic Security Service Application Program Interface.
|
||
Request for Comments 1508
|
||
|
||
[4] B. Tung, C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky, J. Wray,
|
||
J. Trostle, Public Key Cryptography for Initial Authentication in
|
||
Kerberos, http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-
|
||
pkinit-10.txt.
|
||
|
||
|
||
10. This draft expires on January 31st, 2001.
|
||
|
||
|
||
11. Authors' Addresses
|
||
|
||
Michael Swift
|
||
Microsoft
|
||
One Microsoft Way
|
||
Redmond, Washington, 98052, U.S.A.
|
||
Email: mikesw@microsoft.com
|
||
|
||
Jonathan Trostle
|
||
170 W. Tasman Dr.
|
||
San Jose, CA 95134, U.S.A.
|
||
Email: jtrostle@cisco.com
|
||
Phone: (408) 527-6201
|