diff options
Diffstat (limited to 'doc/standardisation/draft-ietf-cat-kerberos-pk-cross-08.txt')
| -rw-r--r-- | doc/standardisation/draft-ietf-cat-kerberos-pk-cross-08.txt | 542 |
1 files changed, 0 insertions, 542 deletions
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-08.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-08.txt deleted file mode 100644 index 41b8e8e5f..000000000 --- a/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-08.txt +++ /dev/null @@ -1,542 +0,0 @@ -INTERNET-DRAFT Matthew Hur -draft-ietf-cat-kerberos-pk-cross-08.txt Cisco Systems -Updates: RFC 1510 Brian Tung -November 8, 2001 (Expires May 8, 2001) Tatyana Ryutov - Clifford Neuman - ISI - Ari Medvinsky - Liberate - Gene Tsudik - UC Irvine - Bill Sommerfeld - Sun Microsystems - - - 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.'' - - 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 list of current Internet-Drafts can be accessed at - http://www.ietf.org/1id-abstracts.html - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - - - - The distribution of this memo is unlimited. It is filed as - draft-ietf-cat-kerberos-pk-cross-07.txt, and expires May 15, 2001. - Please send comments to the authors. - - -1. Abstract - - This document defines extensions to the Kerberos protocol - specification [KERB] 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 - - Symmetric and asymmetric key systems may co-exist within hybrid - architectures in order to leverage the advantages and mitigiate - issues within the respective systems. An example of a hybrid - solution that may employ both symmetric and asymmetric technologies - is Kerberos ciphersuires in TLS [KERBTLS] which utilizes the - Kerberos protocol [KERB] [KERB94] in conjunction with TLS [TLS] - which has commonly been thought of as a public key protocol. - - The Kerberos can leverage the advantages provided by public key - cryptography. PKINIT [PKINIT] describes the use of public key - cryptography in the initial authentication exchange in Kerberos. - PKTAPP [PKTAPP] describes how an application service can essentially - issue a kerberos ticket to itself after utilizing public key - cryptography for authentication. 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 increase network traffic and 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) [X509] 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 [NEUMAN]. 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 - [KERB-REV]: - 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. Note that the service - name in the request is for pkcross/realm@REALM instead of - krbtgt/realm@REALM. - - 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 (for pkcross/realm@REALM) 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. - - -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. This is the reason - that the name pkcross/realm@REALM is used instead of - krbtgt/realm@REALM. 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 - - [KERBTLS] A. Medvinsky and M. Hur, "Addition of Kerberos Cipher - Suites to Transport Layer Security (TLS)", RFC 2712, - October 1999. - - [KERB] J. Kohl and C. Neuman, "The Kerberos Network - Authentication Service (V5)", RFC 1510, September 1993. - - [TLS] T. Dierks and C. Allen, "The TLS Protocol, Version 1.0", - RFC 2246, January 1999. - - [PKINIT] 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-14.txt - - [PKTAPP] A. Medvinsky, M. Hur, S. Medvinsky, C. Neuman. - Public Key Utilizing Tickets for Application - Servers (PKTAPP). draft-ietf-cat-kerberos-pk-tapp-03.txt - - [X509] ITU-T (formerly CCITT) Information technology - Open - Systems Interconnection - The Directory: Authentication - Framework Recommendation X.509 ISO/IEC 9594-8 - - [NEUMAN] B.C. Neuman, "Proxy-Based Authorization and Accounting for - Distributed Systems". Proceedings of the 13th - International Conference on Distributed Computing Systems, - May 1993 - - [KERB94] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication - Service for Computer Networks, IEEE Communications, - 32(9):33-38. September 1994. - - [KERB-REV] C.Neuman, J. Kohl, T. Ts'o. The Kerberos Network - Authentication Service (V5). - draft-ietf-cat-kerberos-revisions-08.txt - - -11. Authors' Addresses - - Matthew Hur - Cisco Systems - 2901 Third Avenue - Seattle, WA 98121 - Phone: +1 206 256 3197 - E-Mail: mhur@cisco.com - - Brian Tung - Tatyana Ryutov - Clifford Neuman - 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}@isi.edu - - Ari Medvinsky - Liberate - 2 Circle Star Way - San Carlos, CA 94070-6200 - Phone: +1 650 701 4000 - EMail: ari@liberate.com - - Gene Tsudik - ICS Dept, 458 CS Building - Irvine CA 92697-3425 - Phone: +1 310 448 9329 - E-Mail: gts@ics.uci.edu - - Bill Sommerfeld - Sun Microsystems - E-Mail: sommerfeld@east.sun.com - |