One document matched: draft-ietf-cat-iakerb-01.txt
Differences from draft-ietf-cat-iakerb-00.txt
Initial Authentication with Kerberos and the GSS-API (IAKERB)
STATUS OF THIS MEMO
This document is an Internet-Draft. 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".
To learn the current status of any Internet-Draft, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
Coast), or ftp.isi.edu (US West Coast).
Distribution of this document is unlimited. Please send comments
to the CAT working group at cat-ietf@mit.edu or the authors.
ABSTRACT
This draft proposes a new Kerberos authentication mechanism for
use when the client computer is unable to contact a Key
Distribution Center (KDC). Instead, the client will send
Authentication Service (AS) and Ticket Granting Service (TGS)
requests to the server, which will then forward them to the
appropriate KDC.
Table of Contents
1. Introduction 2
2. Basic Protocol 2
3. Addresses in Tickets 3
4. Generating Initial Credentials 3
5. Sample Usage Scenarios 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.3 Case 3: Client and Server in different realms with a TGT 4
6. Combining IAKERB with other Kerberos Extensions 5
7. Security Considerations 5
8. References 5
1. Introduction
The standard Kerberos mechanism works well in a LAN environment
where clients are well connected and can quickly locate and
communicate with network services such as the KDC. Unlike many
other authentication protocols, Kerberos requires that the client
do most of the work of authentication by locating and calling a
KDC to obtain tickets. All a server must do is to decrypt the AP
request and verify that it is not a replay
However, in certain circumstances this is not a good use of
computer resources. On the Internet, for example, servers tend to
be far better connected and more able to locate a KDC then clients
are. Similarly, when dialing up to an Internet Service Provider
(ISP) the client computer is essentially unconnected while the
ISP's computer are well connected to the Internet as well as other
servers locally. Hence, it makes sense in these situations to
allow the client to forward KDC requests to the server and let the
server communicate with the KDC.
2. Basic Protocol
The mechanism ID for user to user 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 basic protocol is an extension of the GSSAPI Kerberos V5
mechanism documented in RFC1964 [2], and consists of two optional
phases, and one mandatory phase. The two optional phases use the
AS and TGS exchanges as defined by the Kerberos V5 protocol in
RFC1510 [1].
In the first phase, the client may send an AS request to the
server, to which the server responds with an AS reply. If the
client does not need to engage in an AS exchange, it may skip this
phase and proceed on to the second or third phase.
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
KRB-AS-REQ 00 03
KRB-AS-REP 01 03
KRB-TGS-REQ 02 03
KRB-TGS-REP 03 03
3. 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.
4. Generating Initial Credentials
As this flavor of authentication uses AS requests, the client
name, realm, and password must be available to the mechanism
implementation. The GSS-API does not support passing in
credentials to the GSS_acquire_cred_handle, and credentials are by
their nature package specific and should be implemented as
mechanism-specific extension. Hence, it is left to the
implementation to add an interface for setting the initial
credentials.
5. Sample Usage Scenarios
Below are detailed three different scenarios using IAKERB and the
messages sent in each case. In the first two cases the client
never procures a ticket granting ticket. This is useful for an
environment where communication is slow and the TGT would not
later be used. In the third scenario the client procures a TGT
first and uses it to request a ticket to the service. It is up to
the implementation which variety to implement.
5.1 Case 1: Client and Server are in same realm
In this case, the first call to gss_init_sec_context() on the
client generates an AS request with the client name set to the
client's principal name and the server name set to the server's
principal name. The client application sends this to the server
application, which then calls gss_accept_sec_context(). The GSS
runtime on the server strips off the GSSAPI framing and forwards
the request to the KDC, which responds with an AS reply. The
runtime returns the AS reply (with added framing) from
gss_accept_sec_context() and the service returns it to the client
application.
The client application passes the AS reply to
gss_init_sec_context(), which creates an AP request and packages
it up identically to the format in RFC 1964 [2]. The client
application then sends the AP request to the server, which calls
gss_accept_sec_context() to verify the AP request.
Client Server KDC
------ ------ ---
AS-REQ(cname,sname,realm)--> forwards -->
<-- forwards <-- AS-REP
AP-REQ --> Verifies AP request
5.2 Case 2: Client and Server in different realm
In this case, the client GSS runtime analyzes the target name and
determines that it is from a different realm than the client. It
then generates an AS request for a cross-realm TGT for the
server's realm. The server runtime forwards the request to the
client's KDC (C.KDC) and returns the AS reply containing a TGT for
the server's realm. The client runtime then generates a TGS
request for a ticket to the server with the cross-realm TGT. The
server runtime forwards this to the server's KDC (S.KDC), which
returns a session ticket to the server. The client runtime then
generates a normal AP request for the server using this ticket.
Client Server S.KDC C.KDC
------ ------ ----- -----
AS-REQ(cname,krbtgt/srealm,crealm)
forwards --------------->
<-- forwards <------ AS-REP
TGS-REQ(krbtgt/srealm,server) forwards ---->
<-- forwards <-- TGS-REP
AP-REQ --> Verifies AP request
5.3 Case 3: Client and Server in different realms with a TGT
In this case, the client plans on contacting additional services
after authenticating with the server so it wants to obtain a TGT.
The transaction is very similar to the previous example, but in
this case the client obtains a TGT in its own realm before
obtaining a cross-realm TGT for the server's realm.
Client Server S.KDC C.KDC
------ ------ ----- -----
AS-REQ(cname,krbtgt/crealm,crealm)
--> forwards --------------->
<-- forwards <------ AS-REP
TGS-REQ(krbtgt/crealm,krbtgt\srealm)
--> forwards --------------->
<-- forwards <------ TGS-REP
TGS-REQ(krbtgt/srealm,server)
--> forwards ---->
<-- forwards <-- TGS-REP
AP-REQ --> Verifies AP request
6. 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 [3]) or User-to-User Kerberos [4]. In both 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.
7. Security Considerations
This variation on the Kerberos protocol does not change its
security characteristics much. The biggest difference is the lack
of addresses in the tickets. As addresses cannot be relied on to
provide security but are at best make it more difficult to break a
protocol, this is not a serious threat.
8. References
[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] B. Tung, C. Neuman, J. Wray, A. Medvinsky, M. Hur, J. Trostle,
Public Key Cryptography for Initial Authentication in Kerberos,
draft-ietf-cat-kerberos-pk-init-04.txt.
[4] J. Linn. Generic Security Service Application Program
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
Michael Swift
Microsoft
One Microsoft Way
Redmond, Washington, 98052, U.S.A.
Email: mikesw@microsoft.com
| PAFTECH AB 2003-2026 | 2026-04-23 10:39:50 |