Assar Westerlund
e250cf5cdb
git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@8936 ec53bebd-3082-4978-b11e-865c3cabbd6b
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
|