diff options
Diffstat (limited to 'third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-gss-crypto-00.txt')
| -rw-r--r-- | third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-gss-crypto-00.txt | 562 |
1 files changed, 562 insertions, 0 deletions
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-gss-crypto-00.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-gss-crypto-00.txt new file mode 100644 index 00000000000..a1466b8e5e7 --- /dev/null +++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-gss-crypto-00.txt @@ -0,0 +1,562 @@ + + + + + + + + + +Internet-Draft K. Raeburn +Kerberos Working Group MIT +Updates: RFC 1964 August 13, 2003 +Document: draft-ietf-krb-wg-gss-crypto-00.txt expires February 13, 2004 + + General Kerberos Cryptosystem Support + for the Kerberos 5 GSSAPI Mechanism + +Abstract + + This document describes an update to the Kerberos 5 mechanism for + GSSAPI to allow the use of Kerberos-defined cryptosystems directly in + GSSAPI messages, without requiring further changes for each new + encryption or checksum algorithm that complies with the Kerberos + crypto framework specifications. + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026 [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. + +1. Introduction + + Kerberos defines an encryption and checksum framework [KCRYPTO] that + provides for complete specification and enumeration of cryptosystem + specifications in a general way, to be used within Kerberos and + associated protocols. The GSSAPI Kerberos 5 mechanism definition + [GSSAPI-KRB5] sets up a framework for enumerating encryption and + checksum types, independently of how such schemes may be used in + Kerberos, thus requiring updates for any new encryption or checksum + algorithm not directly compatible with those already defined. + + + + +Raeburn [Page 1] + +INTERNET DRAFT August 2003 + + + This document describes an update to [GSSAPI-KRB5] to allow the use + of any Kerberos-defined cryptosystems directly in GSSAPI messages, + without requiring further changes for each new encryption or checksum + algorithm that complies with the framework specifications, and + without making assumptions concerning block sizes or other + characteristics of the underlying encryption operations. + +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. + +3. New Algorithm Identifiers + + Two new sealing algorithm numbers and one new signing algorithm + number are defined, for use in MIC, Wrap and Delete tokens. + + + type name octet values + ----------------------------------------- + seal KERBEROS5-ENCRYPT 00 01 + sign KERBEROS5-CHECKSUM 00 01 + sign NONE ff ff + + + The KERBEROS5-ENCRYPT algorithm encrypts using the Kerberos + encryption type [KCRYPTO] indicated by the encryption key type (using + the session key or initiator's subkey, as described in [GSSAPI- + KRB5]), with a key usage value KG_USAGE_SEAL, defined below. All + Kerberos encryption types provide for integrity protection, and + specify any padding that might be required; neither needs to be done + at the GSS mechanism level when KERBEROS5-ENCRYPT is used. When + KERBEROS5-ENCRYPT is used as the seal algorithm, the sign algorithm + MUST be NONE. + + The signing algorithm value NONE MUST be used only with a sealing + algorithm that incorporates integrity protection; currently, + KERBEROS5-ENCRYPT is the only such sealing algorithm. + + The KERBEROS5-CHECKSUM signing algorithm MAY be used in other cases. + The contents of the SGN_CKSUM field are determined by computing a + Kerberos checksum [KCRYPTO], using the session key or subkey, and a + key usage value of KG_USAGE_SIGN. The Kerberos checksum algorithm to + be used is the required-to-implement checksum algorithm associated + with the encryption key type. It should be noted that the checksum + input data in this case is not the same as the "to-be-signed data" + described in section 1.2.1.1 of [GSSAPI-KRB5]; see below. + + + +Raeburn [Page 2] + +INTERNET DRAFT August 2003 + + + The encryption or checksum output incorporated in the MIC and Wrap + tokens is the octet string output from the corresponding operation in + [KCRYPTO]; it should not be confused with the EncryptedData or + Checksum object in [KrbClar]. + + For purposes of key derivation, we add two new usage values to the + list defined in [KrbClar]; one for signing messages, and one for + sealing messages: + + + name value + ---------------------- + KG_USAGE_SEAL 22 + KG_USAGE_SIGN 23 + + +4. Adjustments to Previous Definitions + +4.1. Quality of Protection + + The GSSAPI specification [GSSAPI] says that a zero QOP value + indicates the "default". The original specification for the Kerberos + 5 mechanism says that a zero QOP value (or a QOP value with the + appropriate bits clear) means DES encryption. + + Since the quality of protection cannot be improved without fully + reauthenticating with a stronger key type, the QOP value is now + ignored. + +4.2. Message Layout + + The definitions of the MIC and Wrap tokens in [GSSAPI-KRB5] assumed + an 8-byte checksum size, and a CBC-mode block cipher with an 8-byte + block size, without integrity protection. In the crypto framework + described in [KCRYPTO], integrity protection is built into the + encryption operations. CBC mode is not assumed, and indeed there may + be no initial vector to supply. While the operations are performed + on messages of specific sizes, the underlying cipher may be a stream + cipher. + + We modify the message definitions such that the portions after the + first 8 bytes (which specify the token identification and the signing + and sealing algorithms) are defined by the algorithms chosen. The + remaining bytes must convey sequence number and direction + information, and must protect the integrity of the token id and + algorithm indicators. For the DES-based algorithms specified in + [GSSAPI-KRB5], the definition for the remaining data is backwards + compatible. + + + +Raeburn [Page 3] + +INTERNET DRAFT August 2003 + + + The revised message descriptions are thus as follows: + + + MIC token + Byte # Name Description + ------------------------------------------------------- + 0..1 TOK_ID Identification field (01 01). + 2..3 SGN_ALG Integrity algorithm indicator. + 4..7 Filler Contains ff ff ff ff + 8..N Dependent on SGN_ALG. + + If SGN_ALG is 0000, 0100, 0200: + 8..15 SND_SEQ Sequence number/direction + field, encrypted. + 16..23 SGN_CKSUM Checksum of bytes 0..7 and + application data, as described + in [GSSAPI-KRB5]. + If SGN_ALG is 0001: + 8..15 SND_SEQ Sequence number/direction + field, NOT encrypted. + 16..N SGN_CKSUM Checksum of bytes 0..15 and + application data, with key + usage KG_USAGE_SIGN. + + + Suggestions from Microsoft: Moving to 64-bit sequence numbers + would be better for long sessions with many messages. Using the + direction flag to perturb the encryption or integrity protection + is safer than simply including a flag which a buggy but mostly + working implementation might fail to check. + + I am considering changing to use 64-bit sequence numbers, and + omitting the direction flag from the transmitted cleartext data. + How it would factor into the encrypted Wrap token, I haven't + figured out yet. + + - Change the key usage values based on the direction? It's + suggested in [KCRYPTO], perhaps not strongly enough, that the key + usage numbers should perturb the key, but DES ignores them, + although DES shouldn't use this extension. + + - Add a direction flag byte in encrypted data? Either depends on + an implementor remembering to add the check. Adding it to + checksummed data requires that the implementor get it right. + + - Generate one or two new keys using PRF and random-to-key + operations, using different keys for each direction? Pulling the + DK function out of the simplified profile is probably not a good + + + +Raeburn [Page 4] + +INTERNET DRAFT August 2003 + + + way to do this. + + The filler bytes are included in the checksum calculation for + simplicity. There is no security benefit from including them. + + In the Wrap token, the initial bytes, sequence number and direction + are incorporated into the data to be encrypted. In most cases, this + is likely to be more efficient in terms of space and computing power + than using unencrypted sequence number and direction fields, adding a + checksum, and doing the additional work to authenticate that the + checksum and encrypted data are part of the same message. (The + framework in [KCRYPTO] has no support for integrity protection of a + block of data only some of which is encrypted, except by treating the + two portions independently and using some additional means to ensure + that the two parts continue to be associated with one another.) + + The length is also included, as a 4-byte value in network byte order, + because the decryption operation in the Kerberos crypto framework + does not recover the exact length of the original input. Thus, + messages with application data larger than 4 gigabytes are not + supported. + + [Q: Should this length be 8 bytes? ASN.1 wrapper?] + + + Wrap token + Byte # Name Description + ------------------------------------------------------------- + 0..1 TOK_ID Identification field (02 01). + 2..3 SGN_ALG Integrity algorithm indicator. + 4..5 SEAL_ALG Sealing algorithm indicator. + 6..7 Filler Contains ff ff + 8..last Dependent on SEAL_ALG and SGN_ALG. + + If SEAL_ALG is 0000: + 8..15 SND_SEQ Encrypted sequence number field. + 16..23 SGN_CKSUM Checksum of plaintext padded data, + calculated according to algorithm + specified in SGN_ALG field. (RFC + 1964) + 24..last Data Encrypted padded data. + + If SEAL_ALG is 0001 and SGN_ALG is ffff: + 8..last Data Encrypted bytes 0..5, 2-byte + direction flag, sequence number, + 4-byte data length, and data. + + + + + +Raeburn [Page 5] + +INTERNET DRAFT August 2003 + + + If SEAL_ALG is ffff, and SGN_ALG is 0000, 0100, 0200: + 8..15 SND_SEQ Encrypted sequence number field. + 16..23 SGN_CKSUM Checksum of plaintext padded data, + as in RFC 1964. + 24..last Data plaintext padded data + + If SEAL_ALG if ffff, and SGN_ALG is 0001: + 8..15 SND_SEQ Sequence number/direction field, + NOT encrypted. + 16..N SGN_CKSUM Checksum of bytes 0..15 and + application data, with key usage + KG_USAGE_SIGN. + N+1..last Data plaintext data + + + The direction flag, as in [GSSAPI-KRB5], is made up of bytes + indicating the party sending the token: 00 for the context initiator, + or hex FF for the context acceptor. In the KERBEROS5-ENCRYPT case, + only two bytes are used, and they replace the fixed filler bytes of + the token header, which need no protection; this reduces slightly the + redundancy of the data transmitted. + + The context-deletion token is essentially a MIC token with no user + data and a different TOK_ID value. Thus, its modification is + straightforward. + + + Context deletion token + Byte # Name Description + ------------------------------------------------------- + 0..1 TOK_ID Identification field (01 02). + 2..3 SGN_ALG Integrity algorithm indicator. + 4..7 Filler Contains ff ff ff ff + + If SGN_ALG is 0000, 0100, 0200: + 8..15 SND_SEQ Sequence number/direction + field, encrypted. + 16..23 SGN_CKSUM Checksum of bytes 0..7, as + described in [GSSAPI-KRB5]. + + If SGN_ALG is 0001: + 8..15 SND_SEQ Sequence number/direction + field, NOT encrypted. + 16..N SGN_CKSUM Checksum of bytes 0..15, with + key usage KG_USAGE_SIGN. + + + + + + +Raeburn [Page 6] + +INTERNET DRAFT August 2003 + + +5. Backwards Compatibility Considerations + + The context initiator should request of the KDC credentials using + session-key cryptosystem types supported by that implementation; if + the only types returned by the KDC are not supported by the mechanism + implementation, it should indicate a failure. This may seem obvious, + but early implementations of both Kerberos and the GSSAPI Kerberos + mechanism supported only DES keys, so the cryptosystem compatibility + question was easy to overlook. + + Under the current mechanism, no negotiation of algorithm types + occurs, so server-side (acceptor) implementations cannot request that + clients not use algorithm types not understood by the server. + However, administration of the server's Kerberos data (e.g., the + service key) has to be done in communication with the KDC, and it is + from the KDC that the client will request credentials. The KDC could + therefore be given the task of limiting session keys for a given + service to types actually supported by the Kerberos and GSSAPI + software on the server. + + This does have a drawback for cases where a service principal name is + used both for GSSAPI-based and non-GSSAPI-based communication (most + notably the "host" service key), if the GSSAPI implementation does + not understand (for example) AES but the Kerberos implementation + does. It means that AES session keys cannot be issued for that + service principal, which keeps the protection of non-GSSAPI services + weaker than necessary. + + It would also be possible to have clients attempt to get DES session + keys before trying to get AES session keys, and have the KDC refuse + to issue the DES keys only for the most critical of services, for + which DES protection is considered inadequate. However, that would + eliminate the possibility of connecting with the more secure + cryptosystem to any service that can be accessed with the weaker + cryptosystem. We thus recommend the former approach, putting the + burden on the KDC administration and gaining the best protection + possible for GSSAPI services, possibly at the cost of weaker + protection of non-GSSAPI Kerberos services sharing service principal + names with GSSAPI services that have not been updated to support this + extension. + + [optional:] + + This mechanism extension MUST NOT be used with the DES encryption key + types described in [KCRYPTO], which ignore the key usage values. + + + + + + +Raeburn [Page 7] + +INTERNET DRAFT August 2003 + + +6. Implementation Note + + At least two implementations have been done of extensions to the RFC + 1964 mechanism for specific non-DES encryption types. These are not + standards-track extensions, but implementors may wish to implement + them as well for compatibility with existing products. No guidance + is provided as to when an implementation may wish to use these non- + standard extensions instead of the extension specified in this + document. + +7. Security Considerations + + Various tradeoffs arise regarding the mixing of new and old software, + or GSSAPI-based and non-GSSAPI Kerberos authentication. They are + discussed in section 5. + + Remember to check direction flag. Key usage numbers and direction + checks? Considerations depend on the approach taken.... + +8. Acknowledgements + + Larry Zhu... + +9. Normative References + + [GSSAPI] + Linn, J., "Generic Security Service Application Program Interface + Version 2, Update 1", RFC 2743, January, 2000. + + [GSSAPI-KRB5] + Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, + June, 1996. + + [KCRYPTO] + draft-ietf-krb-wg-crypto-XX -> RFC xxxx + + [KrbClar] + draft-ietf-krb-wg-kerberos-clarifications-XX -> RFC xxxx + + [RFC2026] + RFC 2026 ... + + [RFC2119] + RFC 2119 ... + + + + + + + +Raeburn [Page 8] + +INTERNET DRAFT August 2003 + + +10. Author's Address + + Kenneth Raeburn + Massachusetts Institute of Technology + 77 Massachusetts Avenue + Cambridge, MA 02139 + +Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." + +Document Change History + +Version -XX: + + Split up Abstract and create a real Introduction. Fix RFC 2026 + reference in Status section. Added Conventions, Acknowledgements and + Implementation Note sections. Updated References with more + placeholders. Capitalize some uses of "must" etc. + + Fill in case of Wrap token without integrity protection, using + KERBEROS5-CHECKSUM for SGN_ALG. Fix descriptions of which message + layout is used for which algorithms. + + + + +Raeburn [Page 9] + +INTERNET DRAFT August 2003 + + + Remove discussion of authenticated encryption with additional data. + + Add discussion of 64-bit sequence numbers and data length, and + alternate handling of the direction flag. + + + Version -XX sent in early 2003 to Kerberos working group: + + Initial revision. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Raeburn [Page 10] |