diff options
Diffstat (limited to 'third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-06.txt')
| -rw-r--r-- | third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-06.txt | 523 |
1 files changed, 523 insertions, 0 deletions
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-06.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-06.txt new file mode 100644 index 00000000000..1ab2b03e079 --- /dev/null +++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-06.txt @@ -0,0 +1,523 @@ + +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 + |