draft-ietf-cat-iakerb-00.txt   draft-ietf-cat-iakerb-01.txt 
CAT Working Group Michael M. Swift CAT Working Group Michael M. Swift
INTERNET-DRAFT Microsoft INTERNET-DRAFT Microsoft
<draft-ietf-cat-iakerb-00.txt > <draft-ietf-cat-iakerb-01.txt >
Expires April 30, 1998 October, 31, 1997 Expires May 21, 1998 November, 21, 1997
Initial Authentication with Kerberos and the GSS-API Initial Authentication with Kerberos and the GSS-API (IAKERB)
(IAKERB)
STATUS OF THIS MEMO STATUS OF THIS MEMO
This document is an Internet-Draft. Internet-Drafts are This document is an Internet-Draft. Internet-Drafts are working
working documents of the Internet Engineering Task Force documents of the Internet Engineering Task Force (IETF), its
(IETF), its areas, and its working groups. Note that areas, and its working groups. Note that other groups may also
other groups may also distribute working documents as distribute working documents as Internet-Drafts.
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum Internet-Drafts are draft documents valid for a maximum of six
of six months and may be updated, replaced, or obsoleted months and may be updated, replaced, or obsoleted by other
by other documents at any time. It is inappropriate to documents at any time. It is inappropriate to use Internet-Drafts
use Internet-Drafts as reference material or to cite them as reference material or to cite them other than as "work in
other than as "work in progress". progress".
To learn the current status of any Internet-Draft, please To learn the current status of any Internet-Draft, please check
check the "1id-abstracts.txt" listing contained in the the "1id-abstracts.txt" listing contained in the Internet-Drafts
Internet-Drafts Shadow Directories on ftp.is.co.za Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
(Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US Coast), or ftp.isi.edu (US West Coast).
West Coast).
Distribution of this document is unlimited. Please send Distribution of this document is unlimited. Please send comments
comments to the CAT working group at cat-ietf@mit.edu or to the CAT working group at cat-ietf@mit.edu or the authors.
the authors.
ABSTRACT ABSTRACT
This draft proposes a new Kerberos authentication This draft proposes a new Kerberos authentication mechanism for
mechanism for use when the client computer is unable to use when the client computer is unable to contact a Key
contact a Key Distribution Center (KDC). Instead, the Distribution Center (KDC). Instead, the client will send
client will send Authentication Service (AS) and Ticket Authentication Service (AS) and Ticket Granting Service (TGS)
Granting Service (TGS) requests to the server, which will requests to the server, which will then forward them to the
then forward them to the appropriate KDC. appropriate KDC.
Table of Contents Table of Contents
1. Introduction 2 1. Introduction 2
2. Basic Protocol 2 2. Basic Protocol 2
3. Addresses in Tickets 3 3. Addresses in Tickets 3
4. Generating Initial Credentials 3 4. Generating Initial Credentials 3
5. Sample Usage Scenarios 3 5. Sample Usage Scenarios 3
5.1 Case 1: Client and Server are in same realm 3 5.1 Case 1: Client and Server are in same realm 3
5.2 Case 2: Client and Server in different realm 4 5.2 Case 2: Client and Server in different realm 4
5.3 Case 3: Client and Server in different realms with a 5.3 Case 3: Client and Server in different realms with a TGT 4
TGT 4
6. Combining IAKERB with other Kerberos Extensions 5 6. Combining IAKERB with other Kerberos Extensions 5
7. Security Considerations 5 7. Security Considerations 5
8. References 5 8. References 5
1. Introduction 1. Introduction
The standard Kerberos mechanism works well in a LAN The standard Kerberos mechanism works well in a LAN environment
environment where clients are well connected and can where clients are well connected and can quickly locate and
quickly locate and communicate with network services such communicate with network services such as the KDC. Unlike many
as the KDC. Unlike many other authentication protocols, other authentication protocols, Kerberos requires that the client
Kerberos requires that the client do most of the work of do most of the work of authentication by locating and calling a
authentication by locating and calling a KDC to obtain KDC to obtain tickets. All a server must do is to decrypt the AP
tickets. All a server must do is to decrypt the AP
request and verify that it is not a replay request and verify that it is not a replay
However, in certain circumstances this is not a good use However, in certain circumstances this is not a good use of
of computer resources. On the Internet, for example, computer resources. On the Internet, for example, servers tend to
servers tend to be far better connected and more able to be far better connected and more able to locate a KDC then clients
locate a KDC then clients are. Similarly, when dialing up are. Similarly, when dialing up to an Internet Service Provider
to an Internet Service Provider (ISP) the client computer (ISP) the client computer is essentially unconnected while the
is essentially unconnected while the ISP's computer are ISP's computer are well connected to the Internet as well as other
well connected to the Internet as well as other servers servers locally. Hence, it makes sense in these situations to
locally. Hence, it makes sense in these situations to allow the client to forward KDC requests to the server and let the
allow the client to forward KDC requests to the server server communicate with the KDC.
and let the server communicate with the KDC.
2. Basic Protocol 2. Basic Protocol
The mechanism ID for user to user GSS-API Kerberos, in The mechanism ID for user to user GSS-API Kerberos, in accordance
accordance with the mechanism proposed by SPNEGO for with the mechanism proposed by SPNEGO for negotiating protocol
negotiating protocol variations, is: variations, is:
{iso(1) member-body(2) United States(840) mit(113554) {iso(1) member-body(2) United States(840) mit(113554)
infosys(1) gssapi(2) krb5(2) initialauth(4)} infosys(1) gssapi(2) krb5(2) initialauth(4)}
The basic protocol is the existing exchanges between The basic protocol is an extension of the GSSAPI Kerberos V5
clients and the KDC detailed in RFC1510 [1]. The first mechanism documented in RFC1964 [2], and consists of two optional
context message is an AS request, to which the server phases, and one mandatory phase. The two optional phases use the
responds with an AS reply. The client may either request AS and TGS exchanges as defined by the Kerberos V5 protocol in
a TGT during the AS request or directly request a session RFC1510 [1].
ticket if the connection is for a short period, only one
service will be contacted, and the service principal and
client principal are both in the same realm. Otherwise,
the client will use the TGT it initially obtained and use
it to create further TGS requests which will also be sent
to the server as context messages.
As with all Kerberos GSS-API messages, the following In the first phase, the client may send an AS request to the
tokens are encapsulated in the GSS-API framing. In server, to which the server responds with an AS reply. If the
addition, the innerContextToken field of the context client does not need to engage in an AS exchange, it may skip this
establishment tokens contain the context message preceded phase and proceed on to the second or third phase.
by a 2-byte TOK_ID field. The messages and their
respective IDs are listed below. The second phase, (which may be skipped if the client does not
need to take advantage of the remote KDC's Ticket Granting
Service), consists of the client sending a TGS request, and
receiving a TGS reply from the server. After receiving the TGS
reply from the server, the client may repeat the above cycle of
sending a TGS request and receiving a TGS reply any number of
times, as necessary.
Finally, the third (and mandatory) phase consists of the GSSAPI
Kerberos V5 initial context establishment exchange, as defined by
RFC1964 [2].
The client may either request a TGT during the first AS exchange
phase, or directly request a session ticket if the connection is
for a short period, only one service will be contacted, and the
service principal and client principal are both in the same realm.
Otherwise, the client will use the TGT it initially obtained and
use it to create further TGS requests during the second phase.
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 [4]:
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, appropriate. The TOK_ID field
shall be one of the following values, to denote the Kerberos V5
protocol message which has been encapsulated in the message:
Message TOK_ID Message TOK_ID
KRB-AS-REQ 05 00 KRB-AS-REQ 00 03
KRB-AS-REP 05 01 KRB-AS-REP 01 03
KRB-TGS-REQ 05 02
KRB-TGS-REP 05 03 KRB-TGS-REQ 02 03
KRB-TGS-REP 03 03
3. Addresses in Tickets 3. Addresses in Tickets
In IAKERB, the machine sending requests to the KDC is the In IAKERB, the machine sending requests to the KDC is the server
server and not the client. As a result, the client should and not the client. As a result, the client should not include its
not include its addresses in any KDC requests for two addresses in any KDC requests for two reasons. First, the KDC may
reasons. First, the, the KDC may reject the forwarded reject the forwarded request as being from the wrong client.
request as being from the wrong client. Second, in the Second, in the case of initial authentication for a dial-up
case of initial authentication for a dial-up client, the client, the client machine may not yet possess a network address.
client machine may not yet possess a network address. Hence, as allowed by RFC1510 [1], the addresses field of the AS
Hence, as allowed by RFC1510 [1], the addresses field of and TGS requests should be blank and the caddr field of the ticket
the AS and TGS requests should be blank and the caddr should similarly be left blank.
field of the ticket should similarly be left blank.
4. Generating Initial Credentials 4. Generating Initial Credentials
As this flavor of authentication uses AS requests, the As this flavor of authentication uses AS requests, the client
client name, realm, and password must be available to the name, realm, and password must be available to the mechanism
mechanism implementation. The GSS-API does not support implementation. The GSS-API does not support passing in
passing in credentials to the GSS_acquire_cred_handle, credentials to the GSS_acquire_cred_handle, and credentials are by
and credentials are by their nature extemely package their nature package specific and should be implemented as
specific. Hence, it is left to the implementation to add mechanism-specific extension. Hence, it is left to the
an interface for setting the initial credentials. implementation to add an interface for setting the initial
credentials.
5. Sample Usage Scenarios 5. Sample Usage Scenarios
Below are detailed three different scenarios using IAKERB Below are detailed three different scenarios using IAKERB and the
and the messages sent in each case. In the first two messages sent in each case. In the first two cases the client
cases the client never procures a ticket granting ticket. never procures a ticket granting ticket. This is useful for an
This is useful for an environment where communication is environment where communication is slow and the TGT would not
slow and the TGT would not later be used. In the third later be used. In the third scenario the client procures a TGT
scenario the client procures a TGT first and uses it to first and uses it to request a ticket to the service. It is up to
request a ticket to the service. It is up to the the implementation which variety to implement.
implementation which variety to implement.
5.1 Case 1: Client and Server are in same realm 5.1 Case 1: Client and Server are in same realm
In this case, the first call to gss_init_sec_context() on In this case, the first call to gss_init_sec_context() on the
the client generates an AS request with the client name client generates an AS request with the client name set to the
set to the client's principal name and the server name client's principal name and the server name set to the server's
set to the server's principal name. The client principal name. The client application sends this to the server
application sends this to the server application, which application, which then calls gss_accept_sec_context(). The GSS
then calls gss_accept_sec_context(). The GSS runtime on runtime on the server strips off the GSSAPI framing and forwards
the server forwards the request to the KDC, which the request to the KDC, which responds with an AS reply. The
responds with an AS reply. The runtime returns the AS runtime returns the AS reply (with added framing) from
reply from gss_accept_sec_context() and the service gss_accept_sec_context() and the service returns it to the client
returns it to the client application. application.
The client application passes the AS reply to The client application passes the AS reply to
gss_init_sec_context(), which creates an AP request and gss_init_sec_context(), which creates an AP request and packages
packages it up identically to the format in RFC 1964 [2]. it up identically to the format in RFC 1964 [2]. The client
The client application then sends the AP request to the application then sends the AP request to the server, which calls
server, which calls gss_accept_sec_context() to verify gss_accept_sec_context() to verify the AP request.
the AP request.
Client Server KDC Client Server KDC
------ ------ ---
AS-REQ(cname,sname,realm)--> forwards --> AS-REQ(cname,sname,realm)--> forwards -->
<-- forwards <-- AS-REP <-- forwards <-- AS-REP
AP-REQ --> Verifies AP request AP-REQ --> Verifies AP request
5.2 Case 2: Client and Server in different realm 5.2 Case 2: Client and Server in different realm
In this case, the client GSS runtime analyzes the target In this case, the client GSS runtime analyzes the target name and
name and determines that it is from a different realm determines that it is from a different realm than the client. It
than the client. It then generates an AS request for a then generates an AS request for a cross-realm TGT for the
cross-realm TGT for the server's realm. The server server's realm. The server runtime forwards the request to the
runtime forwards the request to the client's KDC (C.KDC) client's KDC (C.KDC) and returns the AS reply containing a TGT for
and returns the AS reply containing a TGT for the the server's realm. The client runtime then generates a TGS
server's realm. The client runtime then generates a TGS request for a ticket to the server with the cross-realm TGT. The
request for a ticket to the server with the cross-realm server runtime forwards this to the server's KDC (S.KDC), which
TGT. The server runtime forwards this to the server's KDC returns a session ticket to the server. The client runtime then
(S.KDC), which returns a session ticket to the server. generates a normal AP request for the server using this ticket.
The client runtime then generates a normal AP request for
the server using this ticket.
Client Server S.KDC C.KDC Client Server S.KDC C.KDC
------ ------ ----- -----
AS-REQ(cname,krbtgt/srealm,crealm) AS-REQ(cname,krbtgt/srealm,crealm)
forwards ---------------> forwards --------------->
<-- forwards <------ AS-REP <-- forwards <------ AS-REP
TGS-REQ(krbtgt/srealm,server) forwards ----> TGS-REQ(krbtgt/srealm,server) forwards ---->
<-- forwards <-- TGS-REP <-- forwards <-- TGS-REP
AP-REQ --> Verifies AP request AP-REQ --> Verifies AP request
5.3 Case 3: Client and Server in different realms with a TGT 5.3 Case 3: Client and Server in different realms with a TGT
In this case, the client plans on contacting additional In this case, the client plans on contacting additional services
services after authenticating with the server so it wants after authenticating with the server so it wants to obtain a TGT.
to obtain a TGT. The transaction is very similar to the The transaction is very similar to the previous example, but in
previous example, but in this case the client obtains a this case the client obtains a TGT in its own realm before
TGT in its own realm before obtaining a cross-realm TGT obtaining a cross-realm TGT for the server's realm.
for the server's realm.
Client Server S.KDC C.KDC Client Server S.KDC C.KDC
------ ------ ----- -----
AS-REQ(cname,krbtgt/crealm,crealm) AS-REQ(cname,krbtgt/crealm,crealm)
--> forwards ---------------> --> forwards --------------->
<-- forwards <------ AS-REP <-- forwards <------ AS-REP
TGS-REQ(krbtgt/crealm,krbtgt\srealm) TGS-REQ(krbtgt/crealm,krbtgt\srealm)
--> forwards ---------------> --> forwards --------------->
<-- forwards <------ TGS-REP <-- forwards <------ TGS-REP
TGS-REQ(krbtgt/srealm,server) TGS-REQ(krbtgt/srealm,server)
--> forwards ----> --> forwards ---->
<-- forwards <-- TGS-REP <-- forwards <-- TGS-REP
AP-REQ --> Verifies AP request AP-REQ --> Verifies AP request
6. Combining IAKERB with other Kerberos Extensions 6. Combining IAKERB with other Kerberos Extensions
This protocol is usable with other proposed Kerberos This protocol is usable with other proposed Kerberos extensions
extensions such as PKINIT (Public Key Cryptography for such as PKINIT (Public Key Cryptography for Initial Authentication
Initial Authentication in Kerberos [3]) or User-to-User in Kerberos [3]) or User-to-User Kerberos [4]. In both cases, the
Kerberos [4]. In both cases, the messages which would messages which would normally be sent to the KDC by the GSS
normally be sent to the KDC by the GSS runtime are runtime are instead sent by the client application to the server,
instead sent by the client application to the server,
which then forwards them to a KDC. which then forwards them to a KDC.
7. Security Considerations 7. Security Considerations
This variation on the Kerberos protocol does not change This variation on the Kerberos protocol does not change its
its security characteristics much. The biggest difference security characteristics much. The biggest difference is the lack
is the lack of addresses in the tickets. As addresses of addresses in the tickets. As addresses cannot be relied on to
cannot be relied on to provide security but are at best provide security but are at best make it more difficult to break a
make it more difficult to break a protocol, this is not a protocol, this is not a serious threat.
serious threat.
8. References 8. References
[1] J. Kohl, C. Neuman. The Kerberos Network [1] J. Kohl, C. Neuman. The Kerberos Network Authentication
Authentication Service(V5). Request for Comments 1510. Service(V5). Request for Comments 1510.
[2] J. Linn. The Kerberos Version 5 GSS-API Mechanism. [2] J. Linn. The Kerberos Version 5 GSS-API Mechanism. Request
Request for Comments 1964 for Comments 1964
[3] B. Tung, C. Neuman, J. Wray, A. Medvinsky, M. Hur, J. [3] B. Tung, C. Neuman, J. Wray, A. Medvinsky, M. Hur, J. Trostle,
Trostle, Public Key Cryptography for Initial Public Key Cryptography for Initial Authentication in Kerberos,
Authentication in Kerberos, draft-ietf-cat-kerberos-pk- draft-ietf-cat-kerberos-pk-init-04.txt.
init-04.txt.
[4] M. Swift, User to User Kerberos Authentication using [4] J. Linn. Generic Security Service Application Program
GSS-API, draft-ietf-cat-user2user-01.txt. Interface. Request for Comments 1508
[5] M. Swift, User to User Kerberos Authentication using GSS-API,
draft-ietf-cat-user2user-01.txt.
Author's address Author's address
Michael Swift Michael Swift
Microsoft Microsoft
1 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
 End of changes. 32 change blocks. 
154 lines changed or deleted 178 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/