diff options
Diffstat (limited to 'crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-06.txt')
| -rw-r--r-- | crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-06.txt | 523 |
1 files changed, 0 insertions, 523 deletions
diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-06.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-06.txt deleted file mode 100644 index 1ab2b03..0000000 --- a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-06.txt +++ /dev/null @@ -1,523 +0,0 @@ - -INTERNET-DRAFT Matthew Hur -draft-ietf-cat-kerberos-pk-cross-06.txt CyberSafe Corporation -Updates: RFC 1510 Brian Tung -expires October 10, 2000 Tatyana Ryutov - Clifford Neuman - Gene Tsudik - ISI - Ari Medvinsky - Keen.com - Bill Sommerfeld - Hewlett-Packard - - - Public Key Cryptography for Cross-Realm Authentication in Kerberos - - -0. Status Of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC 2026. 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. - - - - 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.ietf.org (US East Coast), - nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or - munnari.oz.au (Pacific Rim). - - The distribution of this memo is unlimited. It is filed as - draft-ietf-cat-kerberos-pk-cross-06.txt, and expires May 15, 1999. - Please send comments to the authors. - - -1. Abstract - - This document defines extensions to the Kerberos protocol - specification [1] to provide a method for using public key - cryptography to enable cross-realm authentication. The methods - defined here specify the way in which message exchanges are to be - used to transport cross-realm secret keys protected by encryption - under public keys certified as belonging to KDCs. - - -2. Introduction - - The Kerberos authentication protocol [2] can leverage the - advantages provided by public key cryptography. PKINIT [3] - describes the use of public key cryptography in the initial - authentication exchange in Kerberos. PKTAPP [4] describes how an - application service can essentially issue a kerberos ticket to - itself after utilizing public key cryptography for authentication. - Another informational document species the use of public key - crypography for anonymous authentication in Kerberos [5]. This - specification describes the use of public key crpytography in cross- - realm authentication. - - Without the use of public key cryptography, administrators must - maintain separate keys for every realm which wishes to exchange - authentication information with another realm (which implies n(n-1) - keys), or they must utilize a hierachichal arrangement of realms, - which may complicate the trust model by requiring evaluation of - transited realms. - - Even with the multi-hop cross-realm authentication, there must be - some way to locate the path by which separate realms are to be - transited. The current method, which makes use of the DNS-like - realm names typical to Kerberos, requires trust of the intermediate - KDCs. - - PKCROSS utilizes a public key infrastructure (PKI) [6] to simplify - the administrative burden of maintaining cross-realm keys. Such - usage leverages a PKI for a non-centrally-administratable environment - (namely, inter-realm). Thus, a shared key for cross-realm - authentication can be established for a set period of time, and a - remote realm is able to issue policy information that is returned to - itself when a client requests cross-realm authentication. Such policy - information may be in the form of restrictions [7]. Furthermore, - these methods are transparent to the client; therefore, only the KDCs - need to be modified to use them. In this way, we take advantage of - the the distributed trust management capabilities of public key - crypography while maintaining the advantages of localized trust - management provided by Kerberos. - - - Although this specification utilizes the protocol specfied in the - PKINIT specification, it is not necessary to implement client - changes in order to make use of the changes in this document. - - -3. Objectives - - The objectives of this specification are as follows: - - 1. Simplify the administration required to establish Kerberos - cross-realm keys. - - 2. Avoid modification of clients and application servers. - - 3. Allow remote KDC to control its policy on cross-realm - keys shared between KDCs, and on cross-realm tickets - presented by clients. - - 4. Remove any need for KDCs to maintain state about keys - shared with other KDCs. - - 5. Leverage the work done for PKINIT to provide the public key - protocol for establishing symmetric cross realm keys. - - -4. Definitions - - The following notation is used throughout this specification: - KDC_l ........... local KDC - KDC_r ........... remote KDC - XTKT_(l,r) ...... PKCROSS ticket that the remote KDC issues to the - local KDC - TGT_(c,r) ....... cross-realm TGT that the local KDC issues to the - client for presentation to the remote KDC - - This specification defines the following new types to be added to the - Kerberos specification: - PKCROSS kdc-options field in the AS_REQ is bit 9 - TE-TYPE-PKCROSS-KDC 2 - TE-TYPE-PKCROSS-CLIENT 3 - - This specification defines the following ASN.1 type for conveying - policy information: - CrossRealmTktData ::= SEQUENCE OF TypedData - - This specification defines the following types for policy information - conveyed in CrossRealmTktData: - PLC_LIFETIME 1 - PLC_SET_TKT_FLAGS 2 - PLC_NOSET_TKT_FLAGS 3 - - TicketExtensions are defined per the Kerberos specification [8]: - TicketExtensions ::= SEQUENCE OF TypedData - Where - TypedData ::= SEQUENCE { - data-type[0] INTEGER, - data-value[1] OCTET STRING OPTIONAL - } - - -5. Protocol Specification - - We assume that the client has already obtained a TGT. To perform - cross-realm authentication, the client does exactly what it does - with ordinary (i.e. non-public-key-enabled) Kerberos; the only - changes are in the KDC; although the ticket which the client - forwards to the remote realm may be changed. This is acceptable - since the client treats the ticket as opaque. - - -5.1. Overview of Protocol - - The basic operation of the PKCROSS protocol is as follows: - - 1. The client submits a request to the local KDC for - credentials for the remote realm. This is just a typical - cross realm request that may occur with or without PKCROSS. - - 2. The local KDC submits a PKINIT request to the remote KDC to - obtain a "special" PKCROSS ticket. This is a standard - PKINIT request, except that PKCROSS flag (bit 9) is set in - the kdc-options field in the AS_REQ. - - 3. The remote KDC responds as per PKINIT, except that - the ticket contains a TicketExtension, which contains - policy information such as lifetime of cross realm tickets - issued by KDC_l to a client. The local KDC must reflect - this policy information in the credentials it forwards to - the client. Call this ticket XTKT_(l,r) to indicate that - this ticket is used to authenticate the local KDC to the - remote KDC. - - 4. The local KDC passes a ticket, TGT_(c,r) (the cross realm - TGT between the client and remote KDC), to the client. - This ticket contains in its TicketExtension field the - ticket, XTKT_(l,r), which contains the cross-realm key. - The TGT_(c,r) ticket is encrypted using the key sealed in - XTKT_(l,r). (The TicketExtension field is not encrypted.) - The local KDC may optionally include another TicketExtension - type that indicates the hostname and/or IP address for the - remote KDC. - - 5. The client submits the request directly to the remote - KDC, as before. - - 6. The remote KDC extracts XTKT_(l,r) from the TicketExtension - in order to decrypt the encrypted part of TGT_(c,r). - - -------------------------------------------------------------------- - - Client Local KDC (KDC_l) Remote KDC (KDC_r) - ------ ----------------- ------------------ - Normal Kerberos - request for - cross-realm - ticket for KDC_r - ----------------------> - - PKINIT request for - XTKT(l,r) - PKCROSS flag - set in the AS-REQ - * -------------------------> - - PKINIT reply with - XTKT_(l,r) and - policy info in - ticket extension - <-------------------------- * - - Normal Kerberos reply - with TGT_(c,r) and - XTKT(l,r) in ticket - extension - <--------------------------------- - - Normal Kerberos - cross-realm TGS-REQ - for remote - application - service with - TGT_(c,r) and - XTKT(l,r) in ticket - extension - -------------------------------------------------> - - Normal Kerberos - cross-realm - TGS-REP - <--------------------------------------------------------------- - - * Note that the KDC to KDC messages occur only periodically, since - the local KDC caches the XTKT_(l,r). - -------------------------------------------------------------------- - - - Sections 5.2 through 5.4 describe in detail steps 2 through 4 - above. Section 5.6 describes the conditions under which steps - 2 and 3 may be skipped. - - Note that the mechanism presented above requires infrequent KDC to - KDC communication (as dictated by policy - this is discussed - later). Without such an exchange, there are the following issues: - 1) KDC_l would have to issue a ticket with the expectation that - KDC_r will accept it. - 2) In the message that the client sends to KDC_r, KDC_l would have - to authenticate KDC_r with credentials that KDC_r trusts. - 3) There is no way for KDC_r to convey policy information to KDC_l. - 4) If, based on local policy, KDC_r does not accept a ticket from - KDC_l, then the client gets stuck in the middle. To address such - an issue would require modifications to standard client - processing behavior. - Therefore, the infreqeunt use of KDC to KDC communication assures - that inter-realm KDC keys may be established in accordance with local - policies and that clients may continue to operate without - modification. - - -5.2. Local KDC's Request to Remote KDC - - When the local KDC receives a request for cross-realm authentication, - it first checks its ticket cache to see if it has a valid PKCROSS - ticket, XTKT_(l,r). If it has a valid XTKT_(l,r), then it does not - need to send a request to the remote KDC (see section 5.5). - - If the local KDC does not have a valid XTKT_(l,r), it sends a - request to the remote KDC in order to establish a cross realm key and - obtain the XTKT_(l,r). This request is in fact a PKINIT request as - described in the PKINIT specification; i.e., it consists of an AS-REQ - with a PA-PK-AS-REQ included as a preauthentication field. Note, - that the AS-REQ MUST have the PKCROSS flag (bit 9) set in the - kdc_options field of the AS-REQ. Otherwise, this exchange exactly - follows the description given in the PKINIT specification. In - addition, the naming - - -5.3. Remote KDC's Response to Local KDC - - When the remote KDC receives the PKINIT/PKCROSS request from the - local KDC, it sends back a PKINIT response as described in - the PKINIT specification with the following exception: the encrypted - part of the Kerberos ticket is not encrypted with the krbtgt key; - instead, it is encrypted with the ticket granting server's PKCROSS - key. This key, rather than the krbtgt key, is used because it - encrypts a ticket used for verifying a cross realm request rather - than for issuing an application service ticket. Note that, as a - matter of policy, the session key for the XTKT_(l,r) MAY be of - greater strength than that of a session key for a normal PKINIT - reply, since the XTKT_(l,r) SHOULD be much longer lived than a - normal application service ticket. - - In addition, the remote KDC SHOULD include policy information in the - XTKT_(l,r). This policy information would then be reflected in the - cross-realm TGT, TGT_(c,r). Otherwise, the policy for TGT_(c,r) - would be dictated by KDC_l rather than by KDC_r. The local KDC MAY - enforce a more restrictive local policy when creating a cross-realm - ticket, TGT_(c,r). For example, KDC_r may dictate a lifetime - policy of eight hours, but KDC_l may create TKT_(c,r) with a - lifetime of four hours, as dictated by local policy. Also, the - remote KDC MAY include other information about itself along with the - PKCROSS ticket. These items are further discussed in section 6 - below. - - -5.4. Local KDC's Response to Client - - Upon receipt of the PKINIT/CROSS response from the remote KDC, - the local KDC formulates a response to the client. This reply - is constructed exactly as in the Kerberos specification, except - for the following: - - A) The local KDC places XTKT_(l,r) in the TicketExtension field of - the client's cross-realm, ticket, TGT_(c,r), for the remote realm. - Where - data-type equals 3 for TE-TYPE-PKCROSS-CLIENT - data-value is ASN.1 encoding of XTKT_(l,r) - - B) The local KDC adds the name of its CA to the transited field of - TGT_(c,r). - - -5.5 Remote KDC's Processing of Client Request - - When the remote KDC, KDC_r, receives a cross-realm ticket, - TGT_(c,r), and it detects that the ticket contains a ticket - extension of type TE-TYPE-PKCROSS-CLIENT, KDC_r must first decrypt - the ticket, XTKT_(l,r), that is encoded in the ticket extension. - KDC_r uses its PKCROSS key in order to decrypt XTKT_(l,r). KDC_r - then uses the key obtained from XTKT_(l,r) in order to decrypt the - cross-realm ticket, TGT_(c,r). - - KDC_r MUST verify that the cross-realm ticket, TGT_(c,r) is in - compliance with any policy information contained in XTKT_(l,r) (see - section 6). If the TGT_(c,r) is not in compliance with policy, then - the KDC_r responds to the client with a KRB-ERROR message of type - KDC_ERR_POLICY. - - -5.6. Short-Circuiting the KDC-to-KDC Exchange - - As we described earlier, the KDC to KDC exchange is required only - for establishing a symmetric, inter-realm key. Once this key is - established (via the PKINIT exchange), no KDC to KDC communication - is required until that key needs to be renewed. This section - describes the circumstances under which the KDC to KDC exchange - described in Sections 5.2 and 5.3 may be skipped. - - The local KDC has a known lifetime for TGT_(c,r). This lifetime may - be determined by policy information included in XTKT_(l,r), and/or - it may be determined by local KDC policy. If the local KDC already - has a ticket XTKT(l,r), and the start time plus the lifetime for - TGT_(c,r) does not exceed the expiration time for XTGT_(l,r), then - the local KDC may skip the exchange with the remote KDC, and issue a - cross-realm ticket to the client as described in Section 5.4. - - Since the remote KDC may change its PKCROSS key (referred to in - Section 5.2) while there are PKCROSS tickets still active, it SHOULD - cache the old PKCROSS keys until the last issued PKCROSS ticket - expires. Otherwise, the remote KDC will respond to a client with a - KRB-ERROR message of type KDC_ERR_TGT_REVOKED. - - -6. Extensions for the PKCROSS Ticket - - As stated in section 5.3, the remote KDC SHOULD include policy - information in XTKT_(l,r). This policy information is contained in - a TicketExtension, as defined by the Kerberos specification, and the - authorization data of the ticket will contain an authorization - record of type AD-IN-Ticket-Extensions. The TicketExtension defined - for use by PKCROSS is TE-TYPE-PKCROSS-KDC. - Where - data-type equals 2 for TE-TYPE-PKCROSS-KDC - data-value is ASN.1 encoding of CrossRealmTktData - - CrossRealmTktData ::= SEQUENCE OF TypedData - - - ------------------------------------------------------------------ - CrossRealmTktData types and the corresponding data are interpreted - as follows: - - ASN.1 data - type value interpretation encoding - ---------------- ----- -------------- ---------- - PLC_LIFETIME 1 lifetime (in seconds) INTEGER - for TGT_(c,r) - - cross-realm tickets - issued for clients by - TGT_l - - PLC_SET_TKT_FLAGS 2 TicketFlags that must BITSTRING - be set - - format defined by - Kerberos specification - - PLC_NOSET_TKT_FLAGS 3 TicketFlags that must BITSTRING - not be set - - format defined by - Kerberos specification - - Further types may be added to this table. - ------------------------------------------------------------------ - - -7. Usage of Certificates - - In the cases of PKINIT and PKCROSS, the trust in a certification - authority is equivalent to Kerberos cross realm trust. For this - reason, an implementation MAY choose to use the same KDC certificate - when the KDC is acting in any of the following three roles: - 1) KDC is authenticating clients via PKINIT - 2) KDC is authenticating another KDC for PKCROSS - 3) KDC is the client in a PKCROSS exchange with another KDC - - Note that per PKINIT, the KDC X.509 certificate (the server in a - PKINIT exchange) MUST contain the principal name of the KDC in the - subjectAltName field. - - -8. Transport Issues - - Because the messages between the KDCs involve PKINIT exchanges, and - PKINIT recommends TCP as a transport mechanism (due to the length of - the messages and the likelihood that they will fragment), the same - recommendation for TCP applies to PKCROSS as well. - - -9. Security Considerations - - Since PKCROSS utilizes PKINIT, it is subject to the same security - considerations as PKINIT. Administrators should assure adherence - to security policy - for example, this affects the PKCROSS policies - for cross realm key lifetime and for policy propogation from the - PKCROSS ticket, issued from a remote KDC to a local KDC, to - cross realm tickets that are issued by a local KDC to a client. - - -10. Bibliography - - [1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service - (V5). Request for Comments 1510. - - [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service - for Computer Networks, IEEE Communications, 32(9):33-38. September - 1994. - - [3] B. Tung, C. Neuman, M. Hur, A. Medvinsky, S.Medvinsky, J. Wray - J. Trostle. Public Key Cryptography for Initial Authentication - in Kerberos. - draft-ietf-cat-kerberos-pk-init-11.txt - - [4] A. Medvinsky, M. Hur, S. Medvinsky, B. Clifford Neuman. Public - Key Utilizing Tickets for Application Servers (PKTAPP). draft-ietf- - cat-pktapp-02.txt - - [5] A. Medvinsky, J. Cargille, M. Hur. Anonymous Credentials in - Kerberos. draft-ietf-cat-kerberos-anoncred-01.txt - - [6] ITU-T (formerly CCITT) Information technology - Open Systems - Interconnection - The Directory: Authentication Framework - Recommendation X.509 ISO/IEC 9594-8 - - [7] B.C. Neuman, Proxy-Based Authorization and Accounting for - Distributed Systems. In Proceedings of the 13th International - Conference on Distributed Computing Systems, May 1993. - - [8] C.Neuman, J. Kohl, T. Ts'o. The Kerberos Network Authentication - Service (V5). draft-ietf-cat-kerberos-revisions-05.txt - - -11. Authors' Addresses - - Matthew Hur - CyberSafe Corporation - 1605 NW Sammamish Road - Issaquah WA 98027-5378 - Phone: +1 425 391 6000 - E-mail: matt.hur@cybersafe.com - - Brian Tung - Tatyana Ryutov - Clifford Neuman - Gene Tsudik - USC/Information Sciences Institute - 4676 Admiralty Way Suite 1001 - Marina del Rey, CA 90292-6695 - Phone: +1 310 822 1511 - E-Mail: {brian, tryutov, bcn, gts}@isi.edu - - Ari Medvinsky - Keen.com - 2480 Sand Hill Road, Suite 200 - Menlo Park, CA 94025 - Phone +1 650 289 3134 - E-mail: ari@keen.com - - Bill Sommerfeld - Hewlett Packard - 300 Apollo Drive - Chelmsford MA 01824 - Phone: +1 508 436 4352 - E-Mail: sommerfeld@apollo.hp.com - |
