home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_a_c / draft-ietf-cat-user2user-00.txt < prev    next >
Text File  |  1997-10-28  |  9KB  |  260 lines
  1. CAT Working Group                           Michael M. Swift
  2. INTERNET-DRAFT                                     Microsoft
  3. <draft-ietf-cat-user2user-00.txt >
  4. Expires April 31, 1998                     October, 31, 1997
  5.  
  6.   
  7.   
  8.                               
  9.      User to User Kerberos Authentication using GSS-API
  10.                       Preliminary Draft
  11.                               
  12.  
  13.  
  14.  
  15. STATUS OF THIS MEMO
  16.  
  17.   THIS IS A PRELIMINARY DRAFT OF AN INTERNET-DRAFT.  IT
  18.   DOES NOT REPRESENT THE CONSENSUS OF THE CAT WORKING
  19.   GROUP.
  20.   
  21.   
  22.   
  23.   This document is an Internet-Draft. Internet-Drafts are
  24.   working documents of the Internet Engineering Task Force
  25.   (IETF), its areas, and its working groups. Note that
  26.   other groups may also distribute working documents as
  27.   Internet-Drafts.
  28.   
  29.   
  30.   
  31.   Internet-Drafts are draft documents valid for a maximum
  32.   of six months and may be updated, replaced, or obsoleted
  33.   by other documents at any time. It is inappropriate to
  34.   use Internet-Drafts as reference material or to cite them
  35.   other than as "work in progress".
  36.   
  37.  
  38.  
  39.   To learn the current status of any Internet-Draft, please
  40.   check the "1id-abstracts.txt" listing contained in the
  41.   Internet-Drafts Shadow Directories on ftp.is.co.za
  42.   (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific
  43.   Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US
  44.   West Coast).
  45.   
  46.   
  47.   
  48.   Distribution of this document is unlimited.  Please send
  49.   comments to the CAT working group at cat-ietf@mit.edu or
  50.   the authors.
  51.   
  52.  
  53. ABSTRACT
  54.  
  55.   This draft proposes a simple extension to the Kerberos
  56.   GSS-API mechanism to support user to user authentication
  57.   both in the case where the client application explicitly
  58.   requests user to user authentication and when it does not
  59.   know whether the server supports user to user
  60.   authentication.
  61.   
  62.  
  63. Table of Contents
  64.  
  65. 1. Introduction                                            2
  66.  
  67. 2. User to User as a New Mechanism                         3
  68.  
  69. 3. User to User With The Existing Mechanism                5
  70.  
  71. 4. Security Considerations                                 5
  72.  
  73. 5. References                                              5
  74.  
  75.  
  76.  
  77.  
  78. 1.    Introduction
  79.  
  80.   The Kerberos user to user authentication mechanism allows
  81.   for a client application to connect to a service that is
  82.   not in possession of a long term secret key. Instead, the
  83.   authentication request (AP request) is encrypted using
  84.   the session key from the service's ticket granting
  85.   ticket. According to RFC 1510 [1]:
  86.   
  87.       If the ENC-TKT-IN-SKEY option has been specified and
  88.       an additional ticket has been included in the
  89.       request, the KDC will decrypt the additional ticket
  90.       using the key for the server to which the additional
  91.       ticket was issued and verify that it is a ticket-
  92.       granting ticket. .  If the request succeeds, the
  93.       session key from the additional ticket will be used
  94.       to encrypt the new ticket that is issued instead of
  95.       using the key of the server for which the new ticket
  96.       will be used (This allows easy implementation of user-
  97.       to- user authentication, which uses ticket-granting
  98.       ticket session keys in lieu of secret server keys in
  99.       situations where such secret keys could be easily
  100.       compromised.).
  101.       
  102.   
  103.   
  104.   The current Kerberos GSS-API mechanism does not support
  105.   this flavor of authentication, and new messages and flags
  106.   are defined to add this support. For the case that the
  107.   client knows that the service requires user-to-user
  108.   authentication, a new message (KERB-TGT-REQUEST)  is
  109.   defined. In the case that a client sends a normal AP
  110.   request but the service only supports user-to-user
  111.   authentication, a new Kerberos error as well as error
  112.   data type is defined.
  113.   
  114.  
  115. 2.    User to User as a New Mechanism
  116.  
  117.   In the case that the client application knows that the
  118.   server only supports user-to-user authentication, then it
  119.   is easiest to add this functionality as a new mechanism.
  120.   The new protocol extends the existing Kerberos GSS-API
  121.   protocol by adding an additional round trip to request
  122.   the TGT from the service. As with all Kerberos GSS-API
  123.   messages, the following tokens are encapsulated in the
  124.   GSS-API framing.
  125.   
  126.   The first token of the exchange is as follows:
  127.   
  128.      KERB-TGT-REQUEST ::= SEQUENCE {
  129.              pvno[0]                         INTEGER,
  130.              msg-type[1]                     INTEGER,
  131.              server-name[2]                  PrincipalName
  132.      OPTIONAL,
  133.              realm[3]                        Realm OPTIONAL
  134.      }
  135.      
  136.   The TGT request consists of four fields:
  137.   
  138.       pvno and msg-type are as defined in RFC1510 section
  139.           5.4.1. msg-type is
  140.           KRB_TGT_REQ (16).
  141.           
  142.       server-name - this field optionally contains the name
  143.           of the server. If the client application doesn't
  144.           know the server name this can be left blank and
  145.           the server application will pick the appropriate
  146.           server credentials.
  147.           
  148.       realm - this field optionally contains the realm of
  149.           the server. If the client application doesn't know
  150.           the server realm this field can be left blank and
  151.           the server application will pick the appropriate
  152.           server credentials.
  153.           
  154.   The server name and realm are included to allow a server
  155.   application to act for multiple principles in different
  156.   realms and to choose which credentials to use. Depending
  157.   on the implementation of the Kerberos mechanism, the
  158.   application may call gss_accept_sec_context() multiple
  159.   times until the token is accepted.
  160.   
  161.   The response to the KERB-TGT-REQUEST message is as
  162.   follows:
  163.   
  164.      KERB-TGT-REPLY ::= SEQUENCE {
  165.      
  166.              pvno[0]                         INTEGER,
  167.              msg-type[1]                     INTEGER,
  168.              ticket[2]                       Ticket,
  169.              server-name[4]                  PrincipalName
  170.      OPTIONAL,
  171.              realm[5]                        Realm OPTIONAL
  172.              }
  173.      
  174.   The TGT reply contains the following fields:
  175.   
  176.       pvno and msg-type are as defined in RFC1510 section
  177.           5.4.1. msg-type is KRB_TGT_REQ (17)
  178.           
  179.       ticket - contains the TGT for the service specified
  180.           by the server name and realm passed by the client
  181.           or the default service.
  182.           
  183.       server-name - server's principal name. If the client
  184.           does not supply the server name, the server will
  185.           return the name. This allows the client to
  186.           discover the server's principal name in situations
  187.           where it isn't known. However, if the client
  188.           doesn't know the server's principal name then
  189.           authentication is not mutual - any server can
  190.           respond to the client.
  191.           
  192.        realm - server's realm name. Similar to the server-
  193.           name field, this is returned if the client doesn't
  194.           provide a realm in the request.
  195.           
  196.   The mechanism ID for user to user GSS-API Kerberos, in
  197.   accordance with the mechanism proposed by SPNEGO for
  198.   negotiating protocol variations,  is:
  199.   
  200.       {iso(1) member-body(2) United States(840) mit(113554)
  201.      infosys(1) gssapi(2) krb5(2) usertouser(1)}
  202.      
  203.   Following the exchange of the TGT request messages, the
  204.   rest of the authentication is identical to the Kerberos
  205.   GSS-API mechanism defined in RFC 1964 [2].
  206.   
  207.  
  208. 3.    User to User With The Existing Mechanism
  209.  
  210.   In the case that the client application doesn't know that
  211.   a service requires user-to-user authentication and sends
  212.   a normal AP request, it may be useful to recover and have
  213.   the server return the TGT in the error message. In this
  214.   case, the server returns a KRB-ERROR message with the
  215.   KRB_AP_ERR_USER_TO_USER_REQUIRED (0x42). The error data
  216.   for contains a KERB-TGT-REPLY structure without the
  217.   server name and realm fields, as they are already
  218.   included in the KERB-ERROR message. The Kerberos
  219.   mechanism then continues as in [2] but with a user-to-
  220.   user ticket instead of a normal session ticket.
  221.   
  222.  
  223. 4.    Security Considerations
  224.  
  225.   There is some risk in a server handing out its ticket-
  226.   granting-ticket to any client that requests it, in that
  227.   it gives an attacker a piece of encrypted material to
  228.   decrypt. However, the same material may be obtained from
  229.   listening to any legitimate client connect. In addition,
  230.   the server may divulge its name in the KERB-TGT-RESPONSE
  231.   message allowing, but again this may be obtained from
  232.   capturing any legitimate request to the server.
  233.   
  234.  
  235. 5.    References
  236.  
  237.   [1]  J. Kohl, C. Neuman.  The Kerberos Network
  238.      Authentication Service(V5).  Request for Comments 1510.
  239.      
  240.   [2]  J. Linn.  The Kerberos Version 5 GSS-API Mechanism.
  241.      Request for Comments 1964
  242.      
  243.   [3] J. Linn. Generic Security Service Application
  244.      Programming Interface. Request For Comments 1508.
  245.      
  246.   
  247.   
  248.   
  249.   
  250.   Author's address
  251.      
  252.   Michael Swift
  253.   Microsoft
  254.   1 Microsoft Way
  255.   Redmond, Washington, 98052, U.S.A.
  256.   
  257.   Email: mikesw@microsoft.com
  258.   
  259.  
  260.