diff options
Diffstat (limited to 'doc/standardisation/draft-ietf-cat-iakerb-04.txt')
| -rw-r--r-- | doc/standardisation/draft-ietf-cat-iakerb-04.txt | 301 |
1 files changed, 0 insertions, 301 deletions
diff --git a/doc/standardisation/draft-ietf-cat-iakerb-04.txt b/doc/standardisation/draft-ietf-cat-iakerb-04.txt deleted file mode 100644 index 208d057f2..000000000 --- a/doc/standardisation/draft-ietf-cat-iakerb-04.txt +++ /dev/null @@ -1,301 +0,0 @@ -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 |