draft-ietf-cat-user2user-00.txt   draft-ietf-cat-user2user-01.txt 
CAT Working Group Michael M. Swift CAT Working Group Michael M. Swift
INTERNET-DRAFT Microsoft INTERNET-DRAFT Microsoft
<draft-ietf-cat-user2user-00.txt > <draft-ietf-cat-user2user-01.txt >
Expires April 31, 1998 October, 31, 1997 Expires April 30, 1998 October, 31, 1997
User to User Kerberos Authentication using GSS-API User to User Kerberos Authentication using GSS-API
Preliminary Draft
STATUS OF THIS MEMO STATUS OF THIS MEMO
THIS IS A PRELIMINARY DRAFT OF AN INTERNET-DRAFT. IT
DOES NOT REPRESENT THE CONSENSUS OF THE CAT WORKING
GROUP.
This document is an Internet-Draft. Internet-Drafts are This document is an Internet-Draft. Internet-Drafts are
working documents of the Internet Engineering Task Force working documents of the Internet Engineering Task Force
(IETF), its areas, and its working groups. Note that (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also 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 months and may be updated, replaced, or obsoleted of six months and may be updated, replaced, or obsoleted
by other documents at any time. It is inappropriate to by other documents at any time. It is inappropriate to
use Internet-Drafts as reference material or to cite them use Internet-Drafts as reference material or to cite them
skipping to change at line 51 skipping to change at line 46
GSS-API mechanism to support user to user authentication GSS-API mechanism to support user to user authentication
both in the case where the client application explicitly both in the case where the client application explicitly
requests user to user authentication and when it does not requests user to user authentication and when it does not
know whether the server supports user to user know whether the server supports user to user
authentication. authentication.
Table of Contents Table of Contents
1. Introduction 2 1. Introduction 2
2. User to User as a New Mechanism 3 2. User to User as a New Mechanism 2
3. User to User With The Existing Mechanism 5 3. User to User With The Existing Mechanism 4
4. Security Considerations 5 4. Security Considerations 4
5. References 5 5. References 4
1. Introduction 1. Introduction
The Kerberos user to user authentication mechanism allows The Kerberos user to user authentication mechanism allows
for a client application to connect to a service that is for a client application to connect to a service that is
not in possession of a long term secret key. Instead, the not in possession of a long term secret key. Instead, the
authentication request (AP request) is encrypted using authentication request (AP request) is encrypted using
the session key from the service's ticket granting the session key from the service's ticket granting
ticket. According to RFC 1510 [1]: ticket. According to RFC 1510 [1]:
If the ENC-TKT-IN-SKEY option has been specified and If the ENC-TKT-IN-SKEY option has been specified and
an additional ticket has been included in the an additional ticket has been included in the
request, the KDC will decrypt the additional ticket request, the KDC will decrypt the additional ticket
using the key for the server to which the additional using the key for the server to which the additional
ticket was issued and verify that it is a ticket- ticket was issued and verify that it is a ticket-
granting ticket. . If the request succeeds, the granting ticket. ... If the request succeeds, the
session key from the additional ticket will be used session key from the additional ticket will be used
to encrypt the new ticket that is issued instead of to encrypt the new ticket that is issued instead of
using the key of the server for which the new ticket using the key of the server for which the new ticket
will be used (This allows easy implementation of user- will be used (This allows easy implementation of user-
to- user authentication, which uses ticket-granting to- user authentication, which uses ticket-granting
ticket session keys in lieu of secret server keys in ticket session keys in lieu of secret server keys in
situations where such secret keys could be easily situations where such secret keys could be easily
compromised.). compromised.).
The current Kerberos GSS-API mechanism does not support The current Kerberos GSS-API mechanism does not support
skipping to change at line 102 skipping to change at line 97
2. User to User as a New Mechanism 2. User to User as a New Mechanism
In the case that the client application knows that the In the case that the client application knows that the
server only supports user-to-user authentication, then it server only supports user-to-user authentication, then it
is easiest to add this functionality as a new mechanism. is easiest to add this functionality as a new mechanism.
The new protocol extends the existing Kerberos GSS-API The new protocol extends the existing Kerberos GSS-API
protocol by adding an additional round trip to request protocol by adding an additional round trip to request
the TGT from the service. As with all Kerberos GSS-API the TGT from the service. As with all Kerberos GSS-API
messages, the following tokens are encapsulated in the messages, the following tokens are encapsulated in the
GSS-API framing. GSS-API framing. The first token of the exchange is as
follows:
The first token of the exchange is as follows:
KERB-TGT-REQUEST ::= SEQUENCE { KERB-TGT-REQUEST ::= SEQUENCE {
pvno[0] INTEGER, pvno[0] INTEGER,
msg-type[1] INTEGER, msg-type[1] INTEGER,
server-name[2] PrincipalName server-name[2] PrincipalName
OPTIONAL, OPTIONAL,
realm[3] Realm OPTIONAL realm[3] Realm OPTIONAL
} }
The TGT request consists of four fields: The TGT request consists of four fields:
skipping to change at line 149 skipping to change at line 143
The response to the KERB-TGT-REQUEST message is as The response to the KERB-TGT-REQUEST message is as
follows: follows:
KERB-TGT-REPLY ::= SEQUENCE { KERB-TGT-REPLY ::= SEQUENCE {
pvno[0] INTEGER, pvno[0] INTEGER,
msg-type[1] INTEGER, msg-type[1] INTEGER,
ticket[2] Ticket, ticket[2] Ticket,
server-name[4] PrincipalName server-name[4] PrincipalName
OPTIONAL, OPTIONAL,
realm[5] Realm OPTIONAL
} }
The TGT reply contains the following fields: The TGT reply contains the following fields:
pvno and msg-type are as defined in RFC1510 section pvno and msg-type are as defined in RFC1510 section
5.4.1. msg-type is KRB_TGT_REQ (17) 5.4.1. msg-type is KRB_TGT_REP (17)
ticket - contains the TGT for the service specified ticket - contains the TGT for the service specified
by the server name and realm passed by the client by the server name and realm passed by the client
or the default service. or the default service.
server-name - server's principal name. If the client server-name - server's principal name. If the client
does not supply the server name, the server will does not supply the server name, the server will
return the name. This allows the client to return the name. This allows the client to
discover the server's principal name in situations discover the server's principal name in situations
where it isn't known. However, if the client where it isn't known. However, if the client
doesn't know the server's principal name then doesn't know the server's principal name then
authentication is not mutual - any server can authentication is not mutual - any server can
respond to the client. respond to the client. The server realm is not
returned separately because it is in the ticket
structure.
realm - server's realm name. Similar to the server- If the service does not possess a ticket granting ticket,
name field, this is returned if the client doesn't it should return the error KRB_AP_ERR_NO_TGT (0x42).
provide a realm in the request.
If the server name and realm in the TGT request message
do not match the name of the service, then the service
should return the error KRB_AP_ERR_NOT_US.
The mechanism ID for user to user GSS-API Kerberos, in The mechanism ID for user to user GSS-API Kerberos, in
accordance with the mechanism proposed by SPNEGO for accordance with the mechanism proposed by SPNEGO for
negotiating protocol variations, is: negotiating protocol 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) usertouser(1)} infosys(1) gssapi(2) krb5(2) usertouser(3)}
Following the exchange of the TGT request messages, the Following the exchange of the TGT request messages, the
rest of the authentication is identical to the Kerberos rest of the authentication is identical to the Kerberos
GSS-API mechanism defined in RFC 1964 [2]. GSS-API mechanism defined in RFC 1964 [2].
As with the Kerberos GSS-API mechanism, the
innerContextToken field of the context establishment
tokens contain context message (KERB-TGT-REQUEST, KERB-
TGT-REPLY) preceded by a 2-byte TOK_ID field containing
04 03 for the KERB_TGT_REQUEST message and 05 03 for the
KERB_TGT_REPLY message
3. User to User With The Existing Mechanism 3. User to User With The Existing Mechanism
In the case that the client application doesn't know that In the case that the client application doesn't know that
a service requires user-to-user authentication and sends a service requires user-to-user authentication and sends
a normal AP request, it may be useful to recover and have a normal AP request, it may be useful to recover and have
the server return the TGT in the error message. In this the server return the TGT in the error message. In this
case, the server returns a KRB-ERROR message with the case, the server returns a KRB-ERROR message with the
KRB_AP_ERR_USER_TO_USER_REQUIRED (0x42). The error data KRB_AP_ERR_USER_TO_USER_REQUIRED (0x42). The error data
for contains a KERB-TGT-REPLY structure without the for contains a KERB-TGT-REPLY structure without the
server name and realm fields, as they are already server name and realm fields, as they are already
skipping to change at line 225 skipping to change at line 230
[2] J. Linn. The Kerberos Version 5 GSS-API Mechanism. [2] J. Linn. The Kerberos Version 5 GSS-API Mechanism.
Request for Comments 1964 Request for Comments 1964
[3] J. Linn. Generic Security Service Application [3] J. Linn. Generic Security Service Application
Programming Interface. Request For Comments 1508. Programming Interface. Request For Comments 1508.
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. 16 change blocks. 
23 lines changed or deleted 28 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/