From 35b1450b8d6e2ba942d1fe97e2dbe0c48e483cf0 Mon Sep 17 00:00:00 2001 From: Assar Westerlund Date: Sun, 23 Apr 2000 17:09:09 +0000 Subject: [PATCH] new drafts git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@8196 ec53bebd-3082-4978-b11e-865c3cabbd6b --- .../draft-ietf-cat-kerberos-extra-tgt-03.txt | 5 + .../draft-ietf-cat-kerberos-pk-cross-06.txt | 523 +++++++ .../draft-ietf-cat-kerberos-set-passwd-03.txt | 345 +++++ .../draft-ietf-cat-krb-dns-locate-02.txt | 339 +++++ .../draft-ietf-cat-krb5gss-mech2-03.txt | 1333 +++++++++++++++++ 5 files changed, 2545 insertions(+) create mode 100644 doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-03.txt create mode 100644 doc/standardisation/draft-ietf-cat-kerberos-pk-cross-06.txt create mode 100644 doc/standardisation/draft-ietf-cat-kerberos-set-passwd-03.txt create mode 100644 doc/standardisation/draft-ietf-cat-krb-dns-locate-02.txt create mode 100644 doc/standardisation/draft-ietf-cat-krb5gss-mech2-03.txt diff --git a/doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-03.txt b/doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-03.txt new file mode 100644 index 000000000..d09a2ded5 --- /dev/null +++ b/doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-03.txt @@ -0,0 +1,5 @@ +This Internet-Draft has expired and is no longer available. + +Unrevised documents placed in the Internet-Drafts directories have a +maximum life of six months. After that time, they must be updated, or +they will be deleted. This document was deleted on March 20, 2000. diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-06.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-06.txt new file mode 100644 index 000000000..1ab2b03e0 --- /dev/null +++ b/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 + diff --git a/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-03.txt b/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-03.txt new file mode 100644 index 000000000..0319f8bf3 --- /dev/null +++ b/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-03.txt @@ -0,0 +1,345 @@ + +INTERNET-DRAFT Mike Swift +draft-ietf-cat-kerberos-set-passwd-03.txt Microsoft +April 2000 Jonathan Trostle + Cisco Systems + John Brezak + Microsoft + Bill Gossman + Cybersafe + + Kerberos Set/Change Password: Version 2 + + +0. Status Of This Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026 [1]. + + 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. + + Comments and suggestions on this document are encouraged. Comments + on this document should be sent to the CAT working group discussion + list: + ietf-cat-wg@stanford.edu + +1. Abstract + + The Kerberos (RFC 1510 [3]) change password protocol (Horowitz [4]), + does not allow for an administrator to set a password for a new user. + This functionality is useful in some environments, and this proposal + extends [4] to allow password setting. The changes are: adding new + fields to the request message to indicate the principal which is + having its password set, not requiring the initial flag in the service + ticket, using a new protocol version number, and adding three new + result codes. We also extend the set/change protocol to allow a + client to send a sequence of keys to the KDC instead of a cleartext + password. If in the cleartext password case, the cleartext password + fails to satisfy password policy, the server should use the result + code KRB5_KPASSWD_POLICY_REJECT. + +2. Conventions used in this document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in + this document are to be interpreted as described in RFC-2119 [2]. + +3. The Protocol + + The service must accept requests on UDP port 464 and TCP port 464 as + well. The protocol consists of a single request message followed by + a single reply message. For UDP transport, each message must be fully + contained in a single UDP packet. + + For TCP transport, there is a 4 octet header in network byte order + precedes the message and specifies the length of the message. This + requirement is consistent with the TCP transport header in 1510bis. + +Request Message + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | message length | protocol version number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AP_REQ length | AP-REQ data / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / KRB-PRIV message / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + All 16 bit fields are in network byte order. + + message length field: contains the number of bytes in the message + including this field. + + protocol version number: contains the hex constant 0x0002 (network + byte order). + + AP-REQ length: length of AP-REQ data, in bytes. If the length is zero, + then the last field contains a KRB-ERROR message instead of a KRB-PRIV + message. + + AP-REQ data: (see [3]) For a change password/key request, the AP-REQ + message service ticket sname, srealm principal identifier is + kadmin/changepw@REALM where REALM is the realm of the change password + service. The same applies to a set password/key request except the + principal identifier is kadmin/setpw@REALM. The ticket in the AP-REQ + must include a subkey in the Authenticator. To enable setting of + passwords/keys, it is not required that the initial flag be set in the + Kerberos service ticket. The initial flag is required for change requests, + but not for set requests. We have the following definitions: + + old passwd initial flag target principal can be + in request? required? distinct from + authenticating principal? + + change password: yes yes no + + set password: no policy (*) yes + + set key: no policy (*) yes + + change key: no yes no + + policy (*): implementations SHOULD allow administrators to set the + initial flag required for set requests policy to either yes or no. + Clients MUST be able to retry set requests that fail due to error 7 + (initial flag required) with an initial ticket. Clients SHOULD NOT + cache service tickets targetted at kadmin/changepw. + + KRB-PRIV message (see [3]) This KRB-PRIV message must be generated + using the subkey from the authenticator in the AP-REQ data. + + The user-data component of the message consists of the following ASN.1 + structure encoded as an OCTET STRING: + + ChangePasswdData :: = SEQUENCE { + newpasswdorkeys[0] NewPasswdOrKeys, + targname[1] PrincipalName OPTIONAL, + -- only present in set password/key: the principal + -- which will have its password or keys set. Not + -- present in a set request if the client principal + -- from the ticket is the principal having its + -- passwords or keys set. + targrealm[2] Realm OPTIONAL, + -- only present in set password/key: the realm for + -- the principal which will have its password or + -- keys set. Not present in a set request if the + -- client principal from the ticket is the principal + -- having its passwords or keys set. + } + + NewPasswdOrKeys :: = CHOICE { + passwords[0] PasswordSequence, -- change/set passwd + keyseq[1] KeySequences -- change/set key + } + + KeySequences :: = SEQUENCE OF KeySequence + + KeySequence :: = SEQUENCE { + key[0] EncryptionKey, + salt[1] OCTET STRING OPTIONAL, + salt-type[2] INTEGER OPTIONAL + } + + PasswordSequence :: = SEQUENCE { + newpasswd[0] OCTET STRING, + oldpasswd[1] OCTET STRING OPTIONAL + -- oldpasswd always present for change password + -- but not present for set password, set key, or + -- change key + } + + The server must verify the AP-REQ message, check whether the client + principal in the ticket is authorized to set or change the password + (either for that principal, or for the principal in the targname + field if present), and decrypt the new password/keys. The server + also checks whether the initial flag is required for this request, + replying with status 0x0007 if it is not set and should be. An + authorization failure is cause to respond with status 0x0005. For + forward compatibility, the server should be prepared to ignore fields + after targrealm in the structure that it does not understand. + + The newpasswdorkeys field contains either the new cleartext password + (with the old cleartext password for a change password operation), + or a sequence of encryption keys with their respective salts. + + In the cleartext password case, if the old password is sent in the + request, the request MUST be a change password request. If the old + password is not present in the request, the request MUST be a set + password request. The server should apply policy checks to the old + and new password after verifying that the old password is valid. + The server can check validity by obtaining a key from the old + password with a keytype that is present in the KDC database for the + user and comparing the keys for equality. The server then generates + the appropriate keytypes from the password and stores them in the KDC + database. If all goes well, status 0x0000 is returned to the client + in the reply message (see below). For a change password operation, + the initial flag in the service ticket MUST be set. + + In the key sequence case, the sequence of keys is sent to the change + or set password service (kadmin/changepw or kadmin/setpw respectively). + For a principal that can act as a server, its preferred keytype should + be sent as the first key in the sequence, but the KDC is not required + to honor this preference. Application servers should use the key + sequence option for changing/setting their keys. The change/set password + services should check that all keys are in the proper format, returning + the KRB5_KPASSWD_MALFORMED error otherwise. + +Reply Message + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | message length | protocol version number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AP_REP length | AP-REP data / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / KRB-PRIV message / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + All 16 bit fields are in network byte order. + + message length field: contains the number of bytes in the message + including this field. + + protocol version number: contains the hex constant 0x0002 (network + byte order). (The reply message has the same format as in [4]). + + AP-REP length: length of AP-REP data, in bytes. If the length is zero, + then the last field contains a KRB-ERROR message instead of a KRB-PRIV + message. + + AP-REP data: the AP-REP is the response to the AP-REQ in the request + packet. + + KRB-PRIV from [4]: This KRB-PRIV message must be generated using the + subkey in the authenticator in the AP-REQ data. + + The server will respond with a KRB-PRIV message unless it cannot + validate the client AP-REQ or KRB-PRIV message, in which case it will + respond with a KRB-ERROR message. NOTE: Unlike change password version + 1, the KRB-ERROR message will be sent back without any encapsulation. + + The user-data component of the KRB-PRIV message, or e-data component + of the KRB-ERROR message, must consist of the following data. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | result code | result string / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | edata / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + result code (16 bits) (result codes 0-4 are from [4]): + The result code must have one of the following values (network + byte order): + KRB5_KPASSWD_SUCCESS 0 request succeeds (This value is not + allowed in a KRB-ERROR message) + KRB5_KPASSWD_MALFORMED 1 request fails due to being malformed + KRB5_KPASSWD_HARDERROR 2 request fails due to "hard" error in + processing the request (for example, + there is a resource or other problem + causing the request to fail) + KRB5_KPASSWD_AUTHERROR 3 request fails due to an error in + authentication processing + KRB5_KPASSWD_SOFTERROR 4 request fails due to a soft error + in processing the request + KRB5_KPASSWD_ACCESSDENIED 5 requestor not authorized + KRB5_KPASSWD_BAD_VERSION 6 protocol version unsupported + KRB5_KPASSWD_INITIAL_FLAG_NEEDED 7 initial flag required + KRB5_KPASSWD_POLICY_REJECT 8 new cleartext password fails policy; + the result string should include a text message to be presented + to the user. + KRB5_KPASSWD_BAD_PRINCIPAL 9 target principal does not exist + (only in response to a set password request). + KRB5_KPASSWD_ETYPE_NOSUPP 10 the request contains a key sequence + containing at least one etype that is not supported by the KDC. + The response edata contains an ASN.1 encoded PKERB-ETYPE-INFO + type that specifies the etypes that the KDC supports: + + KERB-ETYPE-INFO-ENTRY :: = SEQUENCE { + encryption-type[0] INTEGER, + salt[1] OCTET STRING OPTIONAL -- not sent + } + + PKERB-ETYPE-INFO ::= SEQUENCE OF KERB-ETYPE-INFO-ENTRY + + The client should retry the request using only etypes (keytypes) + that are contained within the PKERB-ETYPE-INFO structure in the + previous response. + 0xFFFF if the request fails for some other reason. + The client must interpret any non-zero result code as a failure. + result string - from [4]: + This field is a UTF-8 encoded string which should be displayed + to the user by the client. Specific reasons for a password + + set/change policy failure is one use for this string. + edata: used to convey additional information as defined by the + result code. + +4. Acknowledgements + + The authors thank Tony Andrea for his input to the document. + +5. References + + [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP + 9, RFC 2026, October 1996. + + [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997 + + [3] J. Kohl, C. Neuman. The Kerberos Network Authentication + Service (V5), Request for Comments 1510. + + [4] M. Horowitz. Kerberos Change Password Protocol, + ftp://ds.internic.net/internet-drafts/ + draft-ietf-cat-kerb-chg-password-02.txt + +6. Expiration Date + + This draft expires in October 2000. + +7. Authors' Addresses + + Jonathan Trostle + Cisco Systems + 170 W. Tasman Dr. + San Jose, CA 95134 + Email: jtrostle@cisco.com + + Mike Swift + 1 Microsoft Way + Redmond, WA 98052 + Email: mikesw@microsoft.com + + John Brezak + 1 Microsoft Way + Redmond, WA 98052 + Email: jbrezak@microsoft.com + + Bill Gossman + Cybersafe Corporation + 1605 NW Sammamish Rd. + Issaquah, WA 98027-5378 + Email: bill.gossman@cybersafe.com + diff --git a/doc/standardisation/draft-ietf-cat-krb-dns-locate-02.txt b/doc/standardisation/draft-ietf-cat-krb-dns-locate-02.txt new file mode 100644 index 000000000..bd31750a1 --- /dev/null +++ b/doc/standardisation/draft-ietf-cat-krb-dns-locate-02.txt @@ -0,0 +1,339 @@ + + + + + + +INTERNET-DRAFT Ken Hornstein + NRL +March 10, 2000 Jeffrey Altman +Expires: September 10, 2000 Columbia University + + + + Distributing Kerberos KDC and Realm Information with DNS + + +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. + + Distribution of this memo is unlimited. It is filed as , and expires on September 10, 2000. Please + send comments to the authors. + +Abstract + + Neither the Kerberos V5 protocol [RFC1510] nor the Kerberos V4 proto- + col [RFC????] describe any mechanism for clients to learn critical + configuration information necessary for proper operation of the pro- + tocol. Such information includes the location of Kerberos key dis- + tribution centers or a mapping between DNS domains and Kerberos + realms. + + Current Kerberos implementations generally store such configuration + information in a file on each client machine. Experience has shown + this method of storing configuration information presents problems + with out-of-date information and scaling problems, especially when + + + +Hornstein, Altman [Page 1] + +RFC DRAFT March 10, 2000 + + + using cross-realm authentication. + + This memo describes a method for using the Domain Name System + [RFC1035] for storing such configuration information. Specifically, + methods for storing KDC location and hostname/domain name to realm + mapping information are discussed. + +DNS vs. Kerberos - Case Sensitivity of Realm Names + + In Kerberos, realm names are case sensitive. While it is strongly + encouraged that all realm names be all upper case this recommendation + has not been adopted by all sites. Some sites use all lower case + names and other use mixed case. DNS on the other hand is case insen- + sitive for queries but is case preserving for responses to TXT + queries. Since "MYREALM", "myrealm", and "MyRealm" are all different + it is necessary that the DNS entries be distinguishable. + + Since the recommend realm names are all upper case, we will not + require any quoting to be applied to upper case names. If the realm + name contains lower case characters each character is to be quoted by + a '=' character. So "MyRealm" would be represented as "M=yR=e=a=l=m" + and "myrealm" as "=m=y=r=e=a=l=m". If the realm name contains the + '=' character it will be represented as "==". + + +Overview - KDC location information + + KDC location information is to be stored using the DNS SRV RR [RFC + 2052]. The format of this RR is as follows: + + Service.Proto.Realm TTL Class SRV Priority Weight Port Target + + The Service name for Kerberos is always "_kerberos". + + The Proto can be either "_udp" or "_tcp". If these records are to be + used, a "_udp" record MUST be included. If the Kerberos implementa- + tion supports TCP transport, a "_tcp" record SHOULD be included. + + The Realm is the Kerberos realm that this record corresponds to. + + TTL, Class, SRV, Priority, Weight, Port, and Target have the standard + meaning as defined in RFC 2052. + +Example - KDC location information + + These are DNS records for a Kerberos realm ASDF.COM. It has two Ker- + beros servers, kdc1.asdf.com and kdc2.asdf.com. Queries should be + directed to kdc1.asdf.com first as per the specified priority. + + + +Hornstein, Altman [Page 2] + +RFC DRAFT March 10, 2000 + + + Weights are not used in these records. + + _kerberos._udp.ASDF.COM. IN SRV 0 0 88 kdc1.asdf.com. + _kerberos._udp.ASDF.COM. IN SRV 1 0 88 kdc2.asdf.com. + +Overview - Kerberos password changing server location information + + Kerberos password changing server [KERB-CHG] location is to be stored + using the DNS SRV RR [RFC 2052]. The format of this RR is as fol- + lows: + + Service.Proto.Realm TTL Class SRV Priority Weight Port Target + + The Service name for the password server is always "_kpasswd". + + The Proto MUST be "_udp". + + The Realm is the Kerberos realm that this record corresponds to. + + TTL, Class, SRV, Priority, Weight, Port, and Target have the standard + meaning as defined in RFC 2052. + +Overview - Kerberos admin server location information + + Kerberos admin location information is to be stored using the DNS SRV + RR [RFC 2052]. The format of this RR is as follows: + + Service.Proto.Realm TTL Class SRV Priority Weight Port Target + + The Service name for the admin server is always "_kerberos-adm". + + The Proto can be either "_udp" or "_tcp". If these records are to be + used, a "_tcp" record MUST be included. If the Kerberos admin imple- + mentation supports UDP transport, a "_udp" record SHOULD be included. + + The Realm is the Kerberos realm that this record corresponds to. + + TTL, Class, SRV, Priority, Weight, Port, and Target have the standard + meaning as defined in RFC 2052. + + Note that there is no formal definition of a Kerberos admin protocol, + so the use of this record is optional and implementation-dependent. + +Example - Kerberos administrative server location information + + These are DNS records for a Kerberos realm ASDF.COM. It has one + administrative server, kdc1.asdf.com. + + + + +Hornstein, Altman [Page 3] + +RFC DRAFT March 10, 2000 + + + _kerberos-adm._tcp.ASDF.COM. IN SRV 0 0 88 kdc1.asdf.com. + +Overview - Hostname/domain name to Kerberos realm mapping + + Information on the mapping of DNS hostnames and domain names to Ker- + beros realms is stored using DNS TXT records [RFC 1035]. These + records have the following format. + + Service.Name TTL Class TXT Realm + + The Service field is always "_kerberos", and prefixes all entries of + this type. + + The Name is a DNS hostname or domain name. This is explained in + greater detail below. + + TTL, Class, and TXT have the standard DNS meaning as defined in RFC + 1035. + + The Realm is the data for the TXT RR, and consists simply of the Ker- + beros realm that corresponds to the Name specified. + + When a Kerberos client wishes to utilize a host-specific service, it + will perform a DNS TXT query, using the hostname in the Name field of + the DNS query. If the record is not found, the first label of the + name is stripped and the query is retried. + + Compliant implementations MUST query the full hostname and the most + specific domain name (the hostname with the first label removed). + Compliant implementations SHOULD try stripping all subsequent labels + until a match is found or the Name field is empty. + +Example - Hostname/domain name to Kerberos realm mapping + + For the previously mentioned ASDF.COM realm and domain, some sample + records might be as follows: + + _kerberos.asdf.com. IN TXT "ASDF.COM" + _kerberos.mrkserver.asdf.com. IN TXT "MARKETING.ASDF.COM" + _kerberos.salesserver.asdf.com. IN TXT "SALES.ASDF.COM" + + Let us suppose that in this case, a Kerberos client wishes to use a + Kerberized service on the host foo.asdf.com. It would first query: + + _kerberos.foo.asdf.com. IN TXT + + Finding no match, it would then query: + + + + +Hornstein, Altman [Page 4] + +RFC DRAFT March 10, 2000 + + + _kerberos.asdf.com. IN TXT + + And find an answer of ASDF.COM. This would be the realm that + foo.asdf.com resides in. + + If another Kerberos client wishes to use a Kerberized service on the + host salesserver.asdf.com, it would query: + + _kerberos.salesserver.asdf.com IN TXT + + And find an answer of SALES.ASDF.COM. + +Security considerations + + As DNS is deployed today, it is an unsecure service. Thus the infor- + mation returned by it cannot be trusted. + + Current practice for REALM to KDC mapping is to use hostnames to + indicate KDC hosts (stored in some implementation-dependent location, + but generally a local config file). These hostnames are vulnerable + to the standard set of DNS attacks (denial of service, spoofed + entries, etc). The design of the Kerberos protocol limits attacks of + this sort to denial of service. However, the use of SRV records does + not change this attack in any way. They have the same vulnerabili- + ties that already exist in the common practice of using hostnames for + KDC locations. + + Current practice for HOSTNAME to REALM mapping is to provide a local + configuration of mappings of hostname or domain name to realm which + are then mapped to KDCs. But this again is vulnerable to spoofing + via CNAME records that point to hosts in other domains. This has the + same effect as when a TXT record is spoofed. In a realm with no + cross-realm trusts this is a DoS attack. However, when cross-realm + trusts are used it is possible to redirect a client to use a comprom- + ised realm. + + This is not an exploit of the Kerberos protocol but of the Kerberos + trust model. The same can be done to any application that must + resolve the hostname in order to determine which domain a non-FQDN + belongs to. + + Implementations SHOULD provide a way of specifying this information + locally without the use of DNS. However, to make this feature + worthwhile a lack of any configuration information on a client should + be interpretted as permission to use DNS. + + + + + + +Hornstein, Altman [Page 5] + +RFC DRAFT March 10, 2000 + + +Expiration + + This Internet-Draft expires on September 10, 2000. + +References + + + [RFC1510] + The Kerberos Network Authentication System; Kohl, Newman; Sep- + tember 1993. + + [RFC1035] + Domain Names - Implementation and Specification; Mockapetris; + November 1987 + + [RFC2782] + A DNS RR for specifying the location of services (DNS SRV); Gul- + brandsen, Vixie; Feburary 2000 + + [KERB-CHG] + Kerberos Change Password Protocol; Horowitz; + ftp://ds.internic.net/internet-drafts/draft-ietf-cat-kerb-chg- + password-02.txt + +Authors' Addresses + + Ken Hornstein + US Naval Research Laboratory + Bldg A-49, Room 2 + 4555 Overlook Avenue + Washington DC 20375 USA + + Phone: +1 (202) 404-4765 + EMail: kenh@cmf.nrl.navy.mil + + Jeffrey Altman + The Kermit Project + Columbia University + 612 West 115th Street #716 + New York NY 10025-7799 USA + + Phone: +1 (212) 854-1344 + EMail: jaltman@columbia.edu + + + + + + + + +Hornstein, Altman [Page 6] + diff --git a/doc/standardisation/draft-ietf-cat-krb5gss-mech2-03.txt b/doc/standardisation/draft-ietf-cat-krb5gss-mech2-03.txt new file mode 100644 index 000000000..11e5dc9f9 --- /dev/null +++ b/doc/standardisation/draft-ietf-cat-krb5gss-mech2-03.txt @@ -0,0 +1,1333 @@ + +INTERNET-DRAFT Tom Yu +Common Authentication Technology WG MIT +draft-ietf-cat-krb5gss-mech2-03.txt 04 March 2000 + + The Kerberos Version 5 GSSAPI Mechanism, Version 2 + +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. + + Comments on this document should be sent to + "ietf-cat-wg@lists.stanford.edu", the IETF Common Authentication + Technology WG discussion list. + +Abstract + + This document defines protocols, procedures, and conventions to be + employed by peers implementing the Generic Security Service + Application Program Interface (as specified in RFC 2743) when using + Kerberos Version 5 technology (as specified in RFC 1510). This + obsoletes RFC 1964. + +Acknowledgements + + Much of the material in this specification is based on work done for + Cygnus Solutions by Marc Horowitz. + +Table of Contents + + Status of This Memo ............................................ 1 + Abstract ....................................................... 1 + Acknowledgements ............................................... 1 + Table of Contents .............................................. 1 + 1. Introduction ............................................... 3 + 2. Token Formats .............................................. 3 + 2.1. Packet Notation ....................................... 3 + +Yu Document Expiration: 04 Sep 2000 [Page 1] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + 2.2. Mechanism OID ......................................... 4 + 2.3. Context Establishment ................................. 4 + 2.3.1. Option Format .................................... 4 + 2.3.1.1. Delegated Credentials Option ................ 5 + 2.3.1.2. Null Option ................................. 5 + 2.3.2. Initial Token .................................... 6 + 2.3.2.1. Data to be Checksummed in APREQ ............. 8 + 2.3.3. Response Token ................................... 10 + 2.4. Per-message Tokens .................................... 12 + 2.4.1. Sequence Number Usage ............................ 12 + 2.4.2. MIC Token ........................................ 12 + 2.4.2.1. Data to be Checksummed in MIC Token ......... 13 + 2.4.3. Wrap Token ....................................... 14 + 2.4.3.1. Wrap Token With Integrity Only .............. 14 + 2.4.3.2. Wrap Token With Integrity and Encryption + ............................................. 15 + 2.4.3.2.1. Data to be Encrypted in Wrap Token ..... 16 + 3. ASN.1 Encoding of Octet Strings ............................ 17 + 4. Name Types ................................................. 18 + 4.1. Mandatory Name Forms .................................. 18 + 4.1.1. Kerberos Principal Name Form ..................... 18 + 4.1.2. Exported Name Object Form for Kerberos5 + Mechanism ........................................ 19 + 5. Credentials ................................................ 20 + 6. Parameter Definitions ...................................... 20 + 6.1. Minor Status Codes .................................... 20 + 6.1.1. Non-Kerberos-specific codes ...................... 21 + 6.1.2. Kerberos-specific-codes .......................... 21 + 7. Kerberos Protocol Dependencies ............................. 22 + 8. Security Considerations .................................... 22 + 9. References ................................................. 22 + 10. Author's Address .......................................... 23 + + + + + + + + + + + + + + + + + + + + + + +Yu Document Expiration: 04 Sep 2000 [Page 2] + +Internet-Draft krb5-gss-mech2-03 March 2000 + +1. Introduction + + The original Kerberos 5 GSSAPI mechanism[RFC1964] has a number of + shortcomings. This document attempts to remedy them by defining a + completely new Kerberos 5 GSSAPI mechanism. + + The context establishment token format requires that the + authenticator of AP-REQ messages contain a cleartext data structure + in its checksum field, which is a needless and potentially confusing + overloading of that field. This is implemented by a special checksum + algorithm whose purpose is to copy the input data directly into the + checksum field of the authenticator. + + The number assignments for checksum algorithms and for encryption + types are inconsistent between the Kerberos protocol and the original + GSSAPI mechanism. If new encryption or checksum algorithms are added + to the Kerberos protocol at some point, the GSSAPI mechanism will + need to be separately updated to use these new algorithms. + + The original mechanism specifies a crude method of key derivation (by + using the XOR of the context key with a fixed constant), which is + incompatible with newer cryptosystems which specify key derivation + procedures themselves. The original mechanism also assumes that both + checksums and cryptosystem blocksizes are eight bytes. + + Defining all GSSAPI tokens for the new Kerberos 5 mechanism in terms + of the Kerberos protocol specification ensures that new encryption + types and checksum types may be automatically used as they are + defined for the Kerberos protocol. + +2. Token Formats + + All tokens, not just the initial token, are framed as the + InitialContextToken described in RFC 2743 section 3.1. The + innerContextToken element of the token will not itself be encoded in + ASN.1, with the exception of caller-provided application data. + + One rationale for avoiding the use of ASN.1 in the inner token is + that some implementors may wish to implement this mechanism in a + kernel or other similarly constrained application where handling of + full ASN.1 encoding may be cumbersome. Also, due to the poor + availability of the relevant standards documents, ASN.1 encoders and + decoders are difficult to implement completely correctly, so keeping + ASN.1 usage to a minimum decreases the probability of bugs in the + implementation of the mechanism. In particular, bit strings need to + be transferred at certain points in this mechanism. There are many + conflicting common misunderstandings of how to encode and decode + ASN.1 bit strings, which have led difficulties in the implementaion + of the Kerberos protocol. + + + + + +Yu Document Expiration: 04 Sep 2000 [Page 3] + +Internet-Draft krb5-gss-mech2-03 March 2000 + +2.1. Packet Notation + + The order of transmission of this protocol is described at the octet + level. Packet diagrams depict bits in the order of transmission, + assuming that individual octets are transmitted with the most + significant bit (MSB) first. The diagrams read from left to right + and from top to bottom, as in printed English. In each octet, bit + number 7 is the MSB and bit number 0 is the LSB. + + Numbers prefixed by the characters "0x" are in hexadecimal notation, + as in the C programming language. Even though packet diagrams are + drawn 16 bits wide, no padding should be used to align the ends of + variable-length fields to a 32-bit or 16-bit boundary. + + All integer fields are in network byte order. All other fields have + the size shown in the diagrams, with the exception of variable length + fields. + +2.2. Mechanism OID + + The Object Identifier (OID) of the new krb5 v2 mechanism is: + + {iso(1) member-body(2) us(840) mit(113554) infosys(1) gssapi(2) + krb5v2(3)} + + +2.3. Context Establishment + +2.3.1. Option Format + + Context establishment tokens, i.e., the initial ones that the + GSS_Init_sec_context() and the GSS_Accept_sec_context() calls emit + while a security context is being set up, may contain options that + influence the subsequent behavior of the context. This document + describes only a small set of options, but additional types may be + added by documents intended to supplement this one. The generic + format is as follows: + + bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +byte +-------------------------------+-------------------------------+ + 0 | option type | + +-------------------------------+-------------------------------+ + 2 | | + +-- option length (32 bits) --+ + 4 | | + +-------------------------------+-------------------------------+ + 6 | . | + / option data (variable length) / + | . | + +-------------------------------+-------------------------------+ + + + + +Yu Document Expiration: 04 Sep 2000 [Page 4] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + option type (16 bits) + The type identifier of the following option. + + option length (32 bits) + The length in bytes of the following option. + + option data (variable length) + The actual option data. + + Any number of options may appear in an initator or acceptor token. + The final option in a token must be the null option, in order to mark + the end of the list. Option type 0xffff is reserved. + + The initiator and acceptor shall ignore any options that they do not + understand. + +2.3.1.1. Delegated Credentials Option + + Only the initiator may use this option. The format of the delegated + credentials option is as follows: + + bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +byte +-------------------------------+-------------------------------+ + 0 | option type = 0x00001 | + +-------------------------------+-------------------------------+ + 2 | | + +-- KRB-CRED length --+ + 4 | | + +-------------------------------+-------------------------------+ + 6 | . | + / KRB-CRED message / + | . | + +-------------------------------+-------------------------------+ + + + option type (16 bits) + The option type for this option shall be 0x0001. + + KRB-CRED length (32 bits) + The length in bytes of the following KRB-CRED message. + + KRB-CRED message (variable length) + The option data for this option shall be the KRB-CRED message + that contains the credentials being delegated (forwarded) to the + context acceptor. Only the initiator may use this option. + +2.3.1.2. Null Option + + The Null option terminates the option list, and must be used by both + the initiator and the acceptor. Its format is as follows: + + + + +Yu Document Expiration: 04 Sep 2000 [Page 5] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +byte +-------------------------------+-------------------------------+ + 0 | option type = 0 | + +-------------------------------+-------------------------------+ + 2 | | + +-- length = 0 --+ + 4 | | + +-------------------------------+-------------------------------+ + + + option type (16 bits) + The option type of this option must be zero. + + option length (32 bits) + The length of this option must be zero. + +2.3.2. Initial Token + + This is the initial token sent by the context initiator, generated by + GSS_Init_sec_context(). + + bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +byte +-------------------------------+-------------------------------+ + 0 | initial token id = 0x0101 | + +-------------------------------+-------------------------------+ + 2 | | + +-- reserved flag bits +-----------------------+ + 4 | | I | C | S | R | M | D | + +-------------------------------+-------------------------------+ + 6 | checksum type count | + +-------------------------------+-------------------------------+ + 8 | . | + / checksum type list / + | . | + +-------------------------------+-------------------------------+ + n | . | + / options / + | . | + +-------------------------------+-------------------------------+ + m | | + +-- AP-REQ length --+ + m+2 | | + +-------------------------------+-------------------------------+ + m+4 | . | + / AP-REQ data / + | . | + +-------------------------------+-------------------------------+ + + + initial token ID (16 bits) + Contains the integer 0x0101, which identifies this as the + initial token in the context setup. + + +Yu Document Expiration: 04 Sep 2000 [Page 6] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + reserved flag bits (26 bits) + These bits are reserved for future expansion. They must be set + to zero by the initiator and be ignored by the acceptor. + + I flag (1 bit) + 0x00000020 -- GSS_C_INTEG_FLAG + + C flag (1 bit) + 0x00000010 -- GSS_C_CONF_FLAG + + S flag (1 bit) + 0x00000008 -- GSS_C_SEQUENCE_FLAG + + R flag (1 bit) + 0x00000004 -- GSS_C_REPLAY_FLAG + + M flag (1 bit) + 0x00000002 -- GSS_C_MUTUAL_FLAG + + D flag (1 bit) + 0x00000001 -- GSS_C_DELEG_FLAG; This flag must be set if the + "delegated credentials" option is included. + + checksum type count (16 bits) + The number of checksum types supported by the initiator. + + checksum type list (variable length) + A list of Kerberos checksum types, as defined in RFC 1510 + section 6.4. These checksum types must be collision-proof and + keyed with the context key; no checksum types that are + incompatible with the encryption key shall be used. Each + checksum type number shall be 32 bits wide. This list should + contain all the checksum types supported by the initiator. If + mutual authentication is not used, then this list shall contain + only one checksum type. + + options (variable length) + The context initiation options, described in section 2.3.1. + + AP-REQ length (32 bits) + The length of the following KRB_AP_REQ message. + + AP-REQ data (variable length) + The AP-REQ message as described in RFC 1510. The checksum in + the authenticator will be computed over the items listed in the + next section. + + The optional sequence number field shall be used in the AP-REQ. The + initiator should generate a subkey in the authenticator, and the + acceptor should generate a subkey in the AP-REP. The key used for + the per-message tokens will be the AP-REP subkey, or if that is not + present, the authenticator subkey, or if that is not present, the + session key. When subkeys are generated, it is strongly recommended + +Yu Document Expiration: 04 Sep 2000 [Page 7] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + that they be of the same type as the associated session key. + + XXX The above is not secure. There should be an algorithmic process + to arrive at a subsession key which both sides of the authentication + exchange can perform based on the ticket sessions key and data known + to both parties, and this should probably be part of the revised + Kerberos protocol rather than bound to the GSSAPI mechanism. + +2.3.2.1. Data to be Checksummed in AP-REQ + + The checksum in the AP-REQ message is calculated over the following + items. Like in the actual tokens, no padding should be added to + force integer fields to align on 32 bit boundaries. This particular + set of data should not be sent as a part of any token; it merely + specifies what is to be checksummed in the AP-REQ. The items in this + encoding that precede the initial token ID correspond to the channel + bindings passed to GSS_Init_sec_context(). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Yu Document Expiration: 04 Sep 2000 [Page 8] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +byte +-------------------------------+-------------------------------+ + 0 | | + +-- initiator address type --+ + 2 | | + +-------------------------------+-------------------------------+ + 4 | initiator address length | + +-------------------------------+-------------------------------+ + 6 | . | + / initiator address / + | . | + +-------------------------------+-------------------------------+ + n | | + +-- acceptor address type --+ + | | + +-------------------------------+-------------------------------+ + n+4 | acceptor address length | + +-------------------------------+-------------------------------+ + n+6 | . | + / acceptor address / + | . | + +-------------------------------+-------------------------------+ + m | . | + / application data / + | . | + +-------------------------------+-------------------------------+ + k | initial token id = 0x0101 | + +-------------------------------+-------------------------------+ + k+2 | | + +-- flags --+ + k+4 | | + +-------------------------------+-------------------------------+ + k+6 | checksum type count | + +-------------------------------+-------------------------------+ + k+8 | . | + / checksum type list / + | . | + +-------------------------------+-------------------------------+ + j | . | + / options / + | . | + +-------------------------------+-------------------------------+ + + + initiator address type (32 bits) + The initiator address type, as defined in the Kerberos protocol + specification. If no initiator address is provided, this must + be zero. + + initiator address length (16 bits) + The length in bytes of the following initiator address. If + there is no inititator address provided, this must be zero. + + +Yu Document Expiration: 04 Sep 2000 [Page 9] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + initiator address (variable length) + The actual initiator address, in network byte order. + + acceptor address type (32 bits) + The acceptor address type, as defined in the Kerberos protocol + specification. If no acceptor address is provided, this must be + zero. + + acceptor address length (16 bits) + The length in bytes of the following acceptor address. This + must be zero is there is no acceptor address provided. + + initiator address (variable length) + The actual acceptor address, in network byte order. + + applicatation data (variable length) + The application data, if provided, encoded as a ASN.1 octet + string using DER. If no application data are passed as input + channel bindings, this shall be a zero-length ASN.1 octet + string. + + initial token ID (16 bits) + The initial token ID from the initial token. + + flags (32 bits) + The context establishment flags from the initial token. + + checksum type count (16 bits) + The number of checksum types supported by the initiator. + + checksum type list (variable length) + The same list of checksum types contained in the initial token. + + options (variable length) + The options list from the initial token. + +2.3.3. Response Token + + This is the reponse token sent by the context acceptor, if mutual + authentication is enabled. + + + + + + + + + + + + + + +Yu Document Expiration: 04 Sep 2000 [Page 10] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +byte +-------------------------------+-------------------------------+ + 0 | response token id = 0x0202 | + +-------------------------------+-------------------------------+ + 2 | | + +-- reserved flag bits +-------+ + 4 | | D | E | + +-------------------------------+-------------------------------+ + 6 | | + +-- checksum type --+ + 8 | | + +-------------------------------+-------------------------------+ + 10 | . | + / options / + | . | + +-------------------------------+-------------------------------+ + n | | + +-- AP-REP or KRB-ERROR length --+ + n+2 | | + +-------------------------------+-------------------------------+ + n+4 | . | + / AP-REP or KRB-ERROR data / + | . | + +-------------------------------+-------------------------------+ + m | . | + / MIC data / + | . | + +-------------------------------+-------------------------------+ + + + response token id (16 bits) + Contains the integer 0x0202, which identifies this as the + response token in the context setup. + + reserved flag bits (30 bits) + These bits are reserved for future expansion. They must be set + to zero by the acceptor and be ignored by the initiator. + + D flag -- delegated creds accepted (1 bit) + 0x00000002 -- If this flag is set, the acceptor processed the + delegated credentials, and GSS_C_DELEG_FLAG should be returned + to the caller. + + E flag -- error (1 bit) + 0x00000001 -- If this flag is set, a KRB-ERROR message shall be + present, rather than an AP-REP message. If this flag is not + set, an AP-REP message shall be present. + + checksum type count (16 bits) + The number of checksum types supported by both the initiator and + the acceptor. + + + +Yu Document Expiration: 04 Sep 2000 [Page 11] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + checksum type (32 bits) + A Kerberos checksum type, as defined in RFC 1510 section 6.4. + This checksum type must be among the types listed by the + initiator, and will be used in for subsequent checksums + generated during this security context. + + options (variable length) + The option list, as described earlier. At this time, no options + are defined for the acceptor, but an implementation might make + use of these options to acknowledge an option from the initial + token. After all the options are specified, a null option must + be used to terminate the list. + + AP-REP or KRB-ERROR length (32 bits) + Depending on the value of the error flag, length in bytes of the + AP-REP or KRB-ERROR message. + + AP-REP or KRB-ERROR data (variable length) + Depending on the value of the error flag, the AP-REP or + KRB-ERROR message as described in RFC 1510. If this field + contains an AP-REP message, the sequence number field in the + AP-REP shall be filled. If this is a KRB-ERROR message, no + further fields will be in this message. + + MIC data (variable length) + A MIC token, as described in section 2.4.2, computed over the + concatentation of the response token ID, flags, checksum length + and type fields, and all option fields. This field and the + preceding length field must not be present if the error flag is + set. + +2.4. Per-message Tokens + +2.4.1. Sequence Number Usage + + Sequence numbers for per-message tokens are 31 bit unsigned integers, + which are incremented by 1 after each token. An overflow condition + should result in a wraparound of the sequence number to zero. The + initiator and acceptor each keep their own sequence numbers per + connection. + + The intial sequence number for tokens sent from the initiator to the + acceptor shall be the least significant 31 bits of sequence number in + the AP-REQ message. The initial sequence number for tokens sent from + the acceptor to the initiator shall be the least significant 31 bits + of the sequence number in the AP-REP message if mutual authentication + is used; if mutual authentication is not used, the initial sequence + number from acceptor to initiator shall be the least significant 31 + bits of the sequence number in the AP-REQ message. + + + + + +Yu Document Expiration: 04 Sep 2000 [Page 12] + +Internet-Draft krb5-gss-mech2-03 March 2000 + +2.4.2. MIC Token + + Use of the GSS_GetMIC() call yields a token, separate from the user + data being protected, which can be used to verify the integrity of + that data when it is received. The MIC token has the following + format: + + bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +byte +-------------------------------+-------------------------------+ + 0 | MIC token id = 0x0303 | + +-------------------------------+-------------------------------+ + 2 | D | | + +---+ sequence number --+ + 4 | | + +-------------------------------+-------------------------------+ + 6 | checksum length | + +-------------------------------+-------------------------------+ + 8 | . | + / checksum data / + | . | + +-------------------------------+-------------------------------+ + + + MIC token id (16 bits) + Contains the integer 0x0303, which identifies this as a MIC + token. + + D -- direction bit (1 bit) + This bit shall be zero if the message is sent from the context + initiator. If the message is sent from the context acceptor, + this bit shall be one. + + sequence number (31 bits) + The sequence number. + + checksum length (16 bits) + The number of bytes in the following checksum data field. + + checksum data (variable length) + The checksum itself, as defined in RFC 1510 section 6.4. The + checksum is calculated over the encoding described in the + following section. The key usage GSS_TOK_MIC -- 22 [XXX need to + register this] shall be used in cryptosystems that support key + derivation. + + The mechanism implementation shall only use the checksum type + returned by the acceptor in the case of mutual authentication. If + mutual authentication is not requested, then only the checksum type + in the initiator token shall be used. + + + + + +Yu Document Expiration: 04 Sep 2000 [Page 13] + +Internet-Draft krb5-gss-mech2-03 March 2000 + +2.4.2.1. Data to be Checksummed in MIC Token + + The checksum in the MIC token shall be calculated over the following + elements. This set of data is not actually included in the token as + is; the description only appears for the purpose of specifying the + method of calculating the checksum. + + bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +byte +-------------------------------+-------------------------------+ + 0 | MIC token id = 0x0303 | + +-------------------------------+-------------------------------+ + 2 | D | | + +---+ sequence number --+ + 4 | | + +-------------------------------+-------------------------------+ + 6 | . | + / application data / + | . | + +-------------------------------+-------------------------------+ + + + MIC token ID (16 bits) + The MIC token ID from the MIC message. + + D -- direction bit (1 bit) + This bit shall be zero if the message is sent from the context + initiator. If the message is sent from the context acceptor, + this bit shall be one. + + sequence number (31 bits) + The sequence number. + + application data (variable length) + The application-supplied data, encoded as an ASN.1 octet string + using DER. + +2.4.3. Wrap Token + + Use of the GSS_Wrap() call yields a token which encapsulates the + input user data (optionally encrypted) along with associated + integrity check quantities. + +2.4.3.1. Wrap Token With Integrity Only + + + + + + + + + + + +Yu Document Expiration: 04 Sep 2000 [Page 14] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +byte +-------------------------------+-------------------------------+ + 0 | integrity wrap token id = 0x0404 | + +-------------------------------+-------------------------------+ + 2 | D | | + +---+ sequence number --+ + 4 | | + +-------------------------------+-------------------------------+ + 6 | . | + / application data / + | . | + +-------------------------------+-------------------------------+ + n | checksum length | + +-------------------------------+-------------------------------+ + n+2 | . | + / checksum data / + | . | + +-------------------------------+-------------------------------+ + + + integrity wrap token id (16 bits) + Contains the integer 0x0404, which identifies this as a Wrap + token with integrity only. + + D -- direction bit (1 bit) + This bit shall be zero if the message is sent from the context + initiator. If the message is sent from the context acceptor, + this bit shall be one. + + sequence number (31 bits) + The sequence number. + + application data (variable length) + The application-supplied data, encoded as an ASN.1 octet string + using DER. + + checksum length (16 bits) + The number of bytes in the following checksum data field. + + checksum data (variable length) + The checksum itself, as defined in RFC 1510 section 6.4, + computed over the concatenation of the token ID, sequence + number, direction field, application data length, and + application data, as in the MIC token checksum in the previous + section. The key usage GSS_TOK_WRAP_INTEG -- 23 [XXX need to + register this] shall be used in cryptosystems that support key + derivation. + + The mechanism implementation should only use checksum types which it + knows to be valid for both peers, as described for MIC tokens. + + + + +Yu Document Expiration: 04 Sep 2000 [Page 15] + +Internet-Draft krb5-gss-mech2-03 March 2000 + +2.4.3.2. Wrap Token With Integrity and Encryption + + bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +byte +-------------------------------+-------------------------------+ + | encrypted wrap token id = 0x0505 | + +-------------------------------+-------------------------------+ + 2 | . | + / encrypted data / + | . | + +-------------------------------+-------------------------------+ + + + encrypted wrap token id (16 bits) + Contains the integer 0x0505, which identifies this as a Wrap + token with integrity and encryption. + + encrypted data (variable length) + The encrypted data itself, as defined in RFC 1510 section 6.3, + encoded as an ASN.1 octet string using DER. Note that this is + not the ASN.1 type EncryptedData as defined in RFC 1510 + section 6.1, but rather the ciphertext without encryption type + or kvno information. The encryption is performed using the + key/enctype exchanged during context setup. The confounder and + checksum are as specified in the Kerberos protocol + specification. The key usage GSS_TOK_WRAP_PRIV -- 24 [XXX need + to register this] shall be used in cryptosystems that support + key derivation. The actual data to be encrypted are specified + below. + +2.4.3.2.1. Data to be Encrypted in Wrap Token + + bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +byte +-------------------------------+-------------------------------+ + 0 | D | | + +---+ sequence number --+ + 2 | | + +-------------------------------+-------------------------------+ + 4 | . | + / application data / + | . | + +-------------------------------+-------------------------------+ + + + D -- direction bit (1 bit) + This bit shall be zero if the message is sent from the context + initiator. If the message is sent from the context acceptor, + this bit shall be one. + + sequence number (31 bits) + The sequence number. + + application data (variable length) + The application-supplied data, encoded as an ASN.1 octet string + +Yu Document Expiration: 04 Sep 2000 [Page 16] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + using DER. + +3. ASN.1 Encoding of Octet Strings + + In order to encode arbitirarly-sized application data, ASN.1 octet + string encoding is in this protocol. The Distinguished Encoding + Rules (DER) shall always be used in such cases. For reference + purposes, the DER encoding of an ASN.1 octet string, adapted from + ITU-T X.690, follows: + + +--------+-------//-------+-------//-------+ + |00000100| length octets |contents octets | + +--------+-------//-------+-------//-------+ + | + +-- identifier octet = 0x04 = [UNIVERSAL 4] + + + In this section only, the bits in each octet shall be numbered as in + the ASN.1 specification, from 8 to 1, with bit 8 being the MSB of the + octet, and with bit 1 being the LSB of the octet. + + identifier octet (8 bits) + Contains the constant 0x04, the tag for primitive encoding of an + octet string with the default (UNIVERSAL 4) tag. + + length octets (variable length) + Contains the length of the contents octets, in definite form + (since this encoding uses DER). + + contents octets (variable length) + The contents of the octet string. + + The length octets shall consist of either a short form (one byte + only), which is to be used only if the number of octets in the + contents octets is less than or equal to 127, or a long form, which + is to be used in all other cases. The short form shall consist of a + single octet with bit 8 (the MSB) equal to zero, and the remaining + bits encoding the number of contents octets (which may be zero) as an + unsigned binary integer. + + The long form shall consist of an initial octet and one or more + subsequent octets. The first octet shall have bit 8 (the MSB) set to + one, and the remaining bits shall encode the number of subsequent + octets in the length encoding as an unsigned binary integer. The + length must be encoded in the minimum number of octets. An initial + octet of 0xFF is reserved by the ASN.1 specification. Bits 8 to 1 of + the first subsequent octet, followed by bits 8 to 1 of each + subsequent octet in order, shall be the encoding of an unsigned + binary integer, with bit 8 of the first octet being the most + significant bit. Thus, the length encoding within is in network byte + order. + + + +Yu Document Expiration: 04 Sep 2000 [Page 17] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + An initial length octet of 0x80 shall not be used, as that is + reserved by the ASN.1 specification for indefinite lengths in + conjunction with constructed contents encodings, which are not to be + used with DER. + +4. Name Types + + This section discusses the name types which may be passed as input to + the Kerberos 5 GSSAPI mechanism's GSS_Import_name() call, and their + associated identifier values. It defines interface elements in + support of portability, and assumes use of C language bindings per + RFC 2744. In addition to specifying OID values for name type + identifiers, symbolic names are included and recommended to GSSAPI + implementors in the interests of convenience to callers. It is + understood that not all implementations of the Kerberos 5 GSSAPI + mechanism need support all name types in this list, and that + additional name forms will likely be added to this list over time. + Further, the definitions of some or all name types may later migrate + to other, mechanism-independent, specifications. The occurrence of a + name type in this specification is specifically not intended to + suggest that the type may be supported only by an implementation of + the Kerberos 5 mechanism. In particular, the occurrence of the + string "_KRB5_" in the symbolic name strings constitutes a means to + unambiguously register the name strings, avoiding collision with + other documents; it is not meant to limit the name types' usage or + applicability. + + For purposes of clarification to GSSAPI implementors, this section's + discussion of some name forms describes means through which those + forms can be supported with existing Kerberos technology. These + discussions are not intended to preclude alternative implementation + strategies for support of the name forms within Kerberos mechanisms + or mechanisms based on other technologies. To enhance application + portability, implementors of mechanisms are encouraged to support + name forms as defined in this section, even if their mechanisms are + independent of Kerberos 5. + +4.1. Mandatory Name Forms + + This section discusses name forms which are to be supported by all + conformant implementations of the Kerberos 5 GSSAPI mechanism. + +4.1.1. Kerberos Principal Name Form + + This name form shall be represented by the Object Identifier {iso(1) + member-body(2) us(840) mit(113554) infosys(1) gssapi(2) krb5(2) + krb5_name(1)}. The recommended symbolic name for this type is + "GSS_KRB5_NT_PRINCIPAL_NAME". + + This name type corresponds to the single-string representation of a + Kerberos name. (Within the MIT Kerberos 5 implementation, such names + are parseable with the krb5_parse_name() function.) The elements + included within this name representation are as follows, proceeding + +Yu Document Expiration: 04 Sep 2000 [Page 18] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + from the beginning of the string: + + (1) One or more principal name components; if more than one + principal name component is included, the components are + separated by '/'. Arbitrary octets may be included within + principal name components, with the following constraints and + special considerations: + + (1a) Any occurrence of the characters '@' or '/' within a + name component must be immediately preceded by the '\' + quoting character, to prevent interpretation as a component + or realm separator. + + (1b) The ASCII newline, tab, backspace, and null characters + may occur directly within the component or may be + represented, respectively, by '\n', '\t', '\b', or '\0'. + + (1c) If the '\' quoting character occurs outside the contexts + described in (1a) and (1b) above, the following character is + interpreted literally. As a special case, this allows the + doubled representation '\\' to represent a single occurrence + of the quoting character. + + (1d) An occurrence of the '\' quoting character as the last + character of a component is illegal. + + (2) Optionally, a '@' character, signifying that a realm name + immediately follows. If no realm name element is included, the + local realm name is assumed. The '/' , ':', and null characters + may not occur within a realm name; the '@', newline, tab, and + backspace characters may be included using the quoting + conventions described in (1a), (1b), and (1c) above. + +4.1.2. Exported Name Object Form for Kerberos 5 Mechanism + + When generated by the Kerberos 5 mechanism, the Mechanism OID within + the exportable name shall be that of the original Kerberos 5 + mechanism[RFC1964]. The Mechanism OID for the original Kerberos 5 + mechanism is: + + {iso(1) member-body(2) us(840) mit(113554) infosys(1) gssapi(2) + krb5(2)} + + The name component within the exportable name shall be a contiguous + string with structure as defined for the Kerberos Principal Name + Form. + + In order to achieve a distinguished encoding for comparison purposes, + the following additional constraints are imposed on the export + operation: + + (1) all occurrences of the characters '@', '/', and '\' within + principal components or realm names shall be quoted with an + +Yu Document Expiration: 04 Sep 2000 [Page 19] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + immediately-preceding '\'. + + (2) all occurrences of the null, backspace, tab, or newline + characters within principal components or realm names will be + represented, respectively, with '\0', '\b', '\t', or '\n'. + + (3) the '\' quoting character shall not be emitted within an + exported name except to accomodate cases (1) and (2). + +5. Credentials + + The Kerberos 5 protocol uses different credentials (in the GSSAPI + sense) for initiating and accepting security contexts. Normal + clients receive a ticket-granting ticket (TGT) and an associated + session key at "login" time; the pair of a TGT and its corresponding + session key forms a credential which is suitable for initiating + security contexts. A ticket-granting ticket, its session key, and + any other (ticket, key) pairs obtained through use of the + ticket-granting-ticket, are typically stored in a Kerberos 5 + credentials cache, sometimes known as a ticket file. + + The encryption key used by the Kerberos server to seal tickets for a + particular application service forms the credentials suitable for + accepting security contexts. These service keys are typically stored + in a Kerberos 5 key table (keytab), or srvtab file (the Kerberos 4 + terminology). In addition to their use as accepting credentials, + these service keys may also be used to obtain initiating credentials + for their service principal. + + The Kerberos 5 mechanism's credential handle may contain references + to either or both types of credentials. It is a local matter how the + Kerberos 5 mechanism implementation finds the appropriate Kerberos 5 + credentials cache or key table. + + However, when the Kerberos 5 mechanism attempts to obtain initiating + credentials for a service principal which are not available in a + credentials cache, and the key for that service principal is + available in a Kerberos 5 key table, the mechanism should use the + service key to obtain initiating credentials for that service. This + should be accomplished by requesting a ticket-granting-ticket from + the Kerberos Key Distribution Center (KDC), and decrypting the KDC's + reply using the service key. + +6. Parameter Definitions + + This section defines parameter values used by the Kerberos V5 GSSAPI + mechanism. It defines interface elements in support of portability, + and assumes use of C language bindings per RFC 2744. + +6.1. Minor Status Codes + + This section recommends common symbolic names for minor_status values + to be returned by the Kerberos 5 GSSAPI mechanism. Use of these + +Yu Document Expiration: 04 Sep 2000 [Page 20] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + definitions will enable independent implementors to enhance + application portability across different implementations of the + mechanism defined in this specification. (In all cases, + implementations of GSS_Display_status() will enable callers to + convert minor_status indicators to text representations.) Each + implementation should make available, through include files or other + means, a facility to translate these symbolic names into the concrete + values which a particular GSSAPI implementation uses to represent the + minor_status values specified in this section. + + It is recognized that this list may grow over time, and that the need + for additional minor_status codes specific to particular + implementations may arise. It is recommended, however, that + implementations should return a minor_status value as defined on a + mechanism-wide basis within this section when that code is accurately + representative of reportable status rather than using a separate, + implementation-defined code. + +6.1.1. Non-Kerberos-specific codes + + These symbols should likely be incorporated into the generic GSSAPI + C-bindings document, since they really are more general. + +GSS_KRB5_S_G_BAD_SERVICE_NAME + /* "No @ in SERVICE-NAME name string" */ +GSS_KRB5_S_G_BAD_STRING_UID + /* "STRING-UID-NAME contains nondigits" */ +GSS_KRB5_S_G_NOUSER + /* "UID does not resolve to username" */ +GSS_KRB5_S_G_VALIDATE_FAILED + /* "Validation error" */ +GSS_KRB5_S_G_BUFFER_ALLOC + /* "Couldn't allocate gss_buffer_t data" */ +GSS_KRB5_S_G_BAD_MSG_CTX + /* "Message context invalid" */ +GSS_KRB5_S_G_WRONG_SIZE + /* "Buffer is the wrong size" */ +GSS_KRB5_S_G_BAD_USAGE + /* "Credential usage type is unknown" */ +GSS_KRB5_S_G_UNKNOWN_QOP + /* "Unknown quality of protection specified" */ + + +6.1.2. Kerberos-specific-codes + + + + + + + + + + +Yu Document Expiration: 04 Sep 2000 [Page 21] + +Internet-Draft krb5-gss-mech2-03 March 2000 + +GSS_KRB5_S_KG_CCACHE_NOMATCH + /* "Principal in credential cache does not match desired name" */ +GSS_KRB5_S_KG_KEYTAB_NOMATCH + /* "No principal in keytab matches desired name" */ +GSS_KRB5_S_KG_TGT_MISSING + /* "Credential cache has no TGT" */ +GSS_KRB5_S_KG_NO_SUBKEY + /* "Authenticator has no subkey" */ +GSS_KRB5_S_KG_CONTEXT_ESTABLISHED + /* "Context is already fully established" */ +GSS_KRB5_S_KG_BAD_SIGN_TYPE + /* "Unknown signature type in token" */ +GSS_KRB5_S_KG_BAD_LENGTH + /* "Invalid field length in token" */ +GSS_KRB5_S_KG_CTX_INCOMPLETE + /* "Attempt to use incomplete security context" */ + + +7. Kerberos Protocol Dependencies + + This protocol makes several assumptions about the Kerberos protocol, + which may require changes to the successor of RFC 1510. + + Sequence numbers, checksum types, and address types are assumed to be + no wider than 32 bits. The Kerberos protocol specification might + need to be modified to accomodate this. This obviously requires some + further discussion. + + Key usages need to be registered within the Kerberos protocol for use + with GSSAPI per-message tokens. The current specification of the + Kerberos protocol does not include descriptions of key derivations or + key usages, but planned revisions to the protocol will include them. + + This protocol also makes the assumption that any cryptosystem used + with the session key will include integrity protection, i.e., it + assumes that no "raw" cryptosystems will be used. + +8. Security Considerations + + The GSSAPI is a security protocol; therefore, security considerations + are discussed throughout this document. The original Kerberos 5 + GSSAPI mechanism's constraints on possible cryptosystems and checksum + types do not permit it to be readily extended to accomodate more + secure cryptographic technologies with larger checksums or encryption + block sizes. Sites are strongly encouraged to adopt the mechanism + specified in this document in the light of recent publicity about the + deficiencies of DES. + +9. References + + [X.680] ISO/IEC, "Information technology -- Abstract Syntax Notation + One (ASN.1): Specification of basic notation", ITU-T X.680 (1997) | + ISO/IEC 8824-1:1998 + +Yu Document Expiration: 04 Sep 2000 [Page 22] + +Internet-Draft krb5-gss-mech2-03 March 2000 + + [X.690] ISO/IEC, "Information technology -- ASN.1 encoding rules: + Specification of Basic Encoding Rules (BER), Canonical Encoding Rules + (CER) and Distinguished Encoding Rules (DER)", ITU-T X.690 (1997) | + ISO/IEC 8825-1:1998. + + [RFC1510] Kohl, J., Neumann, C., "The Kerberos Network Authentication + Service (V5)", RFC 1510. + + [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", + RFC 1964. + + [RFC2743] Linn, J., "Generic Security Service Application Program + Interface, Version 2, Update 1", RFC 2743. + + [RFC2744] Wray, J., "Generic Security Service API Version 2: + C-bindings", RFC 2744. + +10. Author's Address + + Tom Yu + Massachusetts Institute of Technology + Room E40-345 + 77 Massachusetts Avenue + Cambridge, MA 02139 + USA + + email: tlyu@mit.edu + phone: +1 617 253 1753 + + + + + + + + + + + + + + + + + + + + + + + + + + +Yu Document Expiration: 04 Sep 2000 [Page 23] +