< draft-ietf-krb-wg-crypto-06.txt   draft-ietf-krb-wg-crypto-07.txt >
INTERNET DRAFT K. Raeburn INTERNET DRAFT K. Raeburn
Kerberos Working Group MIT Kerberos Working Group MIT
Document: draft-ietf-krb-wg-crypto-06.txt October 27, 2003 Document: draft-ietf-krb-wg-crypto-07.txt February 10, 2004
expires April 27, 2004 expires August 10, 2004
Encryption and Checksum Specifications Encryption and Checksum Specifications
for Kerberos 5 for Kerberos 5
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [RFC2026]. Internet-Drafts all provisions of Section 10 of RFC2026 [RFC2026]. Internet-Drafts
are working documents of the Internet Engineering Task Force (IETF), are working documents of the Internet Engineering Task Force (IETF),
its areas, and its working groups. Note that other groups may also its areas, and its working groups. Note that other groups may also
skipping to change at page 2, line 5 skipping to change at page 2, line 5
protocols, and the actual mechanisms themselves. Several mechanisms protocols, and the actual mechanisms themselves. Several mechanisms
are also defined in this document. Some are taken from RFC 1510, are also defined in this document. Some are taken from RFC 1510,
modified in form to fit this new framework, and occasionally modified modified in form to fit this new framework, and occasionally modified
in content when the old specification was incorrect. New mechanisms in content when the old specification was incorrect. New mechanisms
are presented here as well. This document does NOT indicate which are presented here as well. This document does NOT indicate which
mechanisms may be considered "required to implement". mechanisms may be considered "required to implement".
Comments should be sent to the editor, or to the IETF Kerberos Comments should be sent to the editor, or to the IETF Kerberos
working group (ietf-krb-wg@anl.gov). working group (ietf-krb-wg@anl.gov).
Table of Contents 1mTable of Contents0m
Status of this Memo . . . . . . . . . . . . . . . . . . . . . . . . 1 Status of this Memo . . . . . . . . . . . . . . . . . . . . . . . . 1
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . 2 Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . 2
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Encryption algorithm profile . . . . . . . . . . . . . . . . . . 4 3. Encryption algorithm profile . . . . . . . . . . . . . . . . . . 4
4. Checksum algorithm profile . . . . . . . . . . . . . . . . . . . 9 4. Checksum algorithm profile . . . . . . . . . . . . . . . . . . . 9
5. Simplified profile for CBC ciphers with key derivation . . . . . 10 5. Simplified profile for CBC ciphers with key derivation . . . . . 10
5.1. A key derivation function . . . . . . . . . . . . . . . . . . . 11 5.1. A key derivation function . . . . . . . . . . . . . . . . . . . 11
5.2. Simplified profile parameters . . . . . . . . . . . . . . . . . 13 5.2. Simplified profile parameters . . . . . . . . . . . . . . . . . 13
5.3. Cryptosystem profile based on simplified profile . . . . . . . 14 5.3. Cryptosystem profile based on simplified profile . . . . . . . 14
5.4. Checksum profiles based on simplified profile . . . . . . . . . 16 5.4. Checksum profiles based on simplified profile . . . . . . . . . 16
6. Profiles for Kerberos encryption and checksum algorithms . . . . 16 6. Profiles for Kerberos encryption and checksum algorithms . . . . 16
6.1. Unkeyed checksums . . . . . . . . . . . . . . . . . . . . . . . 16 6.1. Unkeyed checksums . . . . . . . . . . . . . . . . . . . . . . . 17
6.2. DES-based encryption and checksum types . . . . . . . . . . . . 18 6.2. DES-based encryption and checksum types . . . . . . . . . . . . 18
6.3. Triple-DES based encryption and checksum types . . . . . . . . 28 6.3. Triple-DES based encryption and checksum types . . . . . . . . 28
7. Use of Kerberos encryption outside this specification . . . . . . 30 7. Use of Kerberos encryption outside this specification . . . . . . 30
8. Assigned Numbers . . . . . . . . . . . . . . . . . . . . . . . . 31 8. Assigned Numbers . . . . . . . . . . . . . . . . . . . . . . . . 31
9. Implementation Notes . . . . . . . . . . . . . . . . . . . . . . 33 9. Implementation Notes . . . . . . . . . . . . . . . . . . . . . . 33
10. Security Considerations . . . . . . . . . . . . . . . . . . . . 33 10. Security Considerations . . . . . . . . . . . . . . . . . . . . 33
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 35 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 35
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 36 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 36
A. Test vectors . . . . . . . . . . . . . . . . . . . . . . . . . . 37 A. Test vectors . . . . . . . . . . . . . . . . . . . . . . . . . . 37
A.1. n-fold . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 A.1. n-fold . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
A.2. mit_des_string_to_key . . . . . . . . . . . . . . . . . . . . . 39 A.2. mit_des_string_to_key . . . . . . . . . . . . . . . . . . . . . 39
A.3. DES3 DR and DK . . . . . . . . . . . . . . . . . . . . . . . . 43 A.3. DES3 DR and DK . . . . . . . . . . . . . . . . . . . . . . . . 43
A.4. DES3string_to_key . . . . . . . . . . . . . . . . . . . . . . . 44 A.4. DES3string_to_key . . . . . . . . . . . . . . . . . . . . . . . 44
A.5. Modified CRC-32 . . . . . . . . . . . . . . . . . . . . . . . . 45 A.5. Modified CRC-32 . . . . . . . . . . . . . . . . . . . . . . . . 45
B. Significant Changes from RFC 1510 . . . . . . . . . . . . . . . . 45 B. Significant Changes from RFC 1510 . . . . . . . . . . . . . . . . 45
Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Normative References . . . . . . . . . . . . . . . . . . . . . . . . 47 Intellectual Property Statement . . . . . . . . . . . . . . . . . . 47
Normative References . . . . . . . . . . . . . . . . . . . . . . . . 48
Informative References . . . . . . . . . . . . . . . . . . . . . . . 49 Informative References . . . . . . . . . . . . . . . . . . . . . . . 49
Editor's address . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Editor's address . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . . 50 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . . 50
1. Introduction 1. Introduction
The Kerberos protocols are designed to encrypt messages of arbitrary The Kerberos protocols [Kerb] are designed to encrypt messages of
sizes, using block encryption ciphers, or less commonly, stream arbitrary sizes, using block encryption ciphers, or less commonly,
encryption ciphers. Encryption is used to prove the identities of stream encryption ciphers. Encryption is used to prove the
the network entities participating in message exchanges. However, identities of the network entities participating in message
nothing in the Kerberos protocol requires any specific encryption exchanges. However, nothing in the Kerberos protocol requires any
algorithm be used, as long as certain operations are available in the specific encryption algorithm be used, as long as certain operations
algorithm that is used. are available in the algorithm that is used.
The following sections specify the encryption and checksum mechanisms The following sections specify the encryption and checksum mechanisms
currently defined for Kerberos, as well as a framework for defining currently defined for Kerberos, as well as a framework for defining
future mechanisms. The encoding, chaining, padding and other future mechanisms. The encoding, chaining, padding and other
requirements for each are described. Test vectors for several requirements for each are described. Test vectors for several
functions are given in appendix A. functions are given in appendix A.
2. Concepts 2. Concepts
Both encryption and checksum mechanisms are defined in terms of Both encryption and checksum mechanisms are defined in terms of
skipping to change at page 5, line 49 skipping to change at page 5, line 49
attacker must be minimized. attacker must be minimized.
string-to-key (UTF-8 string, UTF-8 string, opaque)->(protocol-key) string-to-key (UTF-8 string, UTF-8 string, opaque)->(protocol-key)
This function generates a key from two UTF-8 strings and an This function generates a key from two UTF-8 strings and an
opaque octet string. One of the strings is normally the opaque octet string. One of the strings is normally the
principal's pass phrase, but is in general merely a secret principal's pass phrase, but is in general merely a secret
string. The other string is a "salt" string intended to string. The other string is a "salt" string intended to
produce different keys from the same password for different produce different keys from the same password for different
users or realms. While the strings provided will use UTF-8 users or realms. While the strings provided will use UTF-8
encoding, no specific version of Unicode should be assumed; all encoding, no specific version of Unicode should be assumed; all
valid UTF-8 strings should be allowed. valid UTF-8 strings should be allowed. Strings provided in
other encodings MUST first be converted to UTF-8 before
applying this function.
The third argument, the octet string, may be used to pass The third argument, the octet string, may be used to pass
mechanism-specific parameters in to this function. Since doing mechanism-specific parameters in to this function. Since doing
so implies knowledge of the specific encryption system, it is so implies knowledge of the specific encryption system, it is
intended that generating non-default parameter values be an intended that generating non-default parameter values be an
uncommon operation, and that normal Kerberos applications be uncommon operation, and that normal Kerberos applications be
able to treat this parameter block as an opaque object supplied able to treat this parameter block as an opaque object supplied
by the Key Distribution Center or defaulted to some mechanism- by the Key Distribution Center or defaulted to some mechanism-
specific constant value. specific constant value.
skipping to change at page 7, line 49 skipping to change at page 8, line 5
versus decrypt) must be the only input needed for this versus decrypt) must be the only input needed for this
initialization. initialization.
This state should be treated as opaque in any uses outside of an This state should be treated as opaque in any uses outside of an
encryption algorithm definition. encryption algorithm definition.
IMPLEMENTATION NOTE: [Kerb1510] was vague on whether and to what IMPLEMENTATION NOTE: [Kerb1510] was vague on whether and to what
degree an application protocol could exercise control over the degree an application protocol could exercise control over the
initial vector used in DES CBC operations. Some existing initial vector used in DES CBC operations. Some existing
implementations permit the setting of the initial vector. This implementations permit the setting of the initial vector. This
new specification does not permit application control of the framework does not provide for application control of the cipher
cipher state (beyond "initialize" and "carry over from previous state (beyond "initialize" and "carry over from previous
encryption"), since the form and content of the initial cipher encryption"), since the form and content of the initial cipher
state can vary between encryption systems, and may not always be a state can vary between encryption systems, and may not always be a
single block of random data. single block of random data.
New Kerberos application protocols should not assume that they can New Kerberos application protocols should not assume that they can
control the initial vector, or that one even exists. However, a control the initial vector, or that one even exists. However, a
general-purpose implementation may wish to provide the capability, general-purpose implementation may wish to provide the capability,
in case applications explicitly setting it are encountered. in case applications explicitly setting it are encountered.
encrypt (specific-key, state, octet string)->(state, octet string) encrypt (specific-key, state, octet string)->(state, octet string)
skipping to change at page 15, line 46 skipping to change at page 16, line 5
default string-to-key As given. default string-to-key As given.
params params
pseudo-random function tmp1 = H(octet-string) pseudo-random function tmp1 = H(octet-string)
tmp2 = truncate tmp1 to multiple of m tmp2 = truncate tmp1 to multiple of m
PRF = E(protocol-key, tmp2, initial-cipher-state) PRF = E(protocol-key, tmp2, initial-cipher-state)
key generation functions: key generation functions:
cryptosystem from simplified profile
----------------------------------------------------------------------------
string-to-key function As given. string-to-key function As given.
random-to-key function As given. random-to-key function As given.
cryptosystem from simplified profile
key-derivation function The "well-known constant" used for the DK key-derivation function The "well-known constant" used for the DK
function is the key usage number, expressed as function is the key usage number, expressed as
four octets in big-endian order, followed by one four octets in big-endian order, followed by one
octet indicated below. octet indicated below.
Kc = DK(base-key, usage | 0x99); Kc = DK(base-key, usage | 0x99);
Ke = DK(base-key, usage | 0xAA); Ke = DK(base-key, usage | 0xAA);
Ki = DK(base-key, usage | 0x55); Ki = DK(base-key, usage | 0x55);
5.4. Checksum profiles based on simplified profile 5.4. Checksum profiles based on simplified profile
skipping to change at page 19, line 8 skipping to change at page 19, line 17
The first octet supplies the 8 most significant bits (with the The first octet supplies the 8 most significant bits (with the
octet's MSB used as the DES input block's MSB, etc.), the second octet's MSB used as the DES input block's MSB, etc.), the second
octet the next 8 bits, ..., and the eighth octet supplies the 8 least octet the next 8 bits, ..., and the eighth octet supplies the 8 least
significant bits. significant bits.
Encryption under DES using cipher block chaining requires an Encryption under DES using cipher block chaining requires an
additional input in the form of an initialization vector; this vector additional input in the form of an initialization vector; this vector
is specified for each encryption system, below. is specified for each encryption system, below.
The DES specifications [DESI81] identify four 'weak' and twelve The DES specifications [DESI81] identify four 'weak' and twelve
'semi-weak' keys; those keys shall not be used for encrypting 'semi-weak' keys; those keys SHALL NOT be used for encrypting
messages for use in Kerberos. The "variant keys" generated for the messages for use in Kerberos. The "variant keys" generated for the
RSA-MD5-DES, RSA-MD4-DES and DES-MAC checksum types by an exclusive- RSA-MD5-DES, RSA-MD4-DES and DES-MAC checksum types by an exclusive-
or of a DES key with a hexadecimal constant are not checked for this or of a DES key with a constant are not checked for this property.
property.
A DES key is 8 octets of data. This consists of 56 bits of actual A DES key is 8 octets of data. This consists of 56 bits of actual
key data, and 8 parity bits, one per octet. The key is encoded as a key data, and 8 parity bits, one per octet. The key is encoded as a
series of 8 octets written in MSB-first order. The bits within the series of 8 octets written in MSB-first order. The bits within the
key are also encoded in MSB order. For example, if the encryption key are also encoded in MSB order. For example, if the encryption
key is (B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8) key is (B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8)
where B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8 where B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8
are the parity bits, the first octet of the key would be are the parity bits, the first octet of the key would be
B1,B2,...,B7,P1 (with B1 as the most significant bit). See the B1,B2,...,B7,P1 (with B1 as the most significant bit). See the
[DESM80] introduction for reference. [DESM80] introduction for reference.
skipping to change at page 35, line 46 skipping to change at page 35, line 46
This document also places no bounds on the amount of data that can be This document also places no bounds on the amount of data that can be
handled in various operations. In order to avoid denial of service handled in various operations. In order to avoid denial of service
attacks, implementations will probably want to restrict message sizes attacks, implementations will probably want to restrict message sizes
at some higher level. at some higher level.
11. IANA Considerations 11. IANA Considerations
Two registries for numeric values should be created: Kerberos Two registries for numeric values should be created: Kerberos
Encryption Type Numbers and Kerberos Checksum Type Numbers. These Encryption Type Numbers and Kerberos Checksum Type Numbers. These
are signed 32-bit values in twos-complement form. Positive values up are signed values ranging from -2147483648 to 2147483647. Positive
to 2**31-1 inclusive should be assigned only for algorithms specified values should be assigned only for algorithms specified in accordance
in accordance with this specification for use with Kerberos or with this specification for use with Kerberos or related protocols.
related protocols. Negative values through -2**31 are for private Negative values are for private use; local and experimental
use; local and experimental algorithms should use these values. Zero algorithms should use these values. Zero is reserved and may not be
is reserved and may not be assigned. assigned.
Positive encryption and checksum type numbers may be assigned Positive encryption and checksum type numbers may be assigned
following either of two policies described in [BCP26]. following either of two policies described in [BCP26].
Standards-track specifications may be assigned values under the Standards-track specifications may be assigned values under the
Standards Action policy. Standards Action policy.
Specifications in Informational RFCs may be assigned values after Specifications in non-standards track RFCs may be assigned values
Expert Review. A non-IETF specification may be assigned values by after Expert Review. A non-IETF specification may be assigned values
publishing an Informational or standards-track RFC referencing the by publishing an Informational or standards-track RFC referencing the
external specification; that specification must be public and external specification; that specification must be public and
published in some permanent record much like the IETF RFCs. It is published in some permanent record much like the IETF RFCs. It is
highly desirable, though not required, that the full specification be highly desirable, though not required, that the full specification be
published as an IETF RFC. published as an IETF RFC.
Smaller encryption type values, which encode to smaller octet strings Smaller encryption type values should be used for IETF standards-
under ASN.1, should be used for IETF standards-track mechanisms, and track mechanisms, and much higher values (16777216 and above) for
much higher values (hex 0x1000000 and above) for other mechanisms. other mechanisms. (Rationale: In the Kerberos ASN.1 encoding,
No other guidance into allocation order is given. smaller numbers encode to smaller octet sequences, so this favors
standards-track mechanisms with slightly smaller messages.) Aside
from that guideline, IANA may choose numbers as it sees fit.
Draft IETF specifications should not include values for encryption Internet-Draft specifications should not include values for
and checksum type numbers. Instead, they should indicate that values encryption and checksum type numbers. Instead, they should indicate
would be assigned by IANA when the document is approved as an RFC. that values would be assigned by IANA when the document is approved
For development and interoperability testing, values in the private- as an RFC. For development and interoperability testing, values in
use range (negative values) may be used, but should not be included the private-use range (negative values) may be used, but should not
in the draft specification. be included in the draft specification.
Each registered value should have an associated unique name to refer Each registered value should have an associated unique name to refer
to it by. The lists given in section 8 should be used as an initial to it by. The lists given in section 8 should be used as an initial
registry; they include reservations for specifications in progress in registry; they include reservations for specifications in progress in
parallel with this document, and for certain other values believed to parallel with this document, and for certain other values believed to
be in use already. be in use already.
12. Acknowledgments 12. Acknowledgments
This document is an extension of the encryption specification This document is an extension of the encryption specification
skipping to change at page 39, line 16 skipping to change at page 39, line 16
The function mit_des_string_to_key is defined in section 6.2. We The function mit_des_string_to_key is defined in section 6.2. We
present here several test values, with some of the intermediate present here several test values, with some of the intermediate
results. The fourth test demonstrates the use of UTF-8 with three results. The fourth test demonstrates the use of UTF-8 with three
characters. The last two tests are specifically constructed so as to characters. The last two tests are specifically constructed so as to
trigger the weak-key fixups for the intermediate key produced by fan- trigger the weak-key fixups for the intermediate key produced by fan-
folding; we have no test cases that cause such fixups for the final folding; we have no test cases that cause such fixups for the final
key. key.
UTF-8 encodings used in test vector: UTF-8 encodings used in test vector:
eszett C3 9F s-caron C5 A1 c-acute C4 87 eszett U+00DF C3 9F s-caron U+0161 C5 A1
g-clef F0 9D 84 9E c-acute U+0107 C4 87 g-clef U+1011E F0 9D 84 9E
Test vector: Test vector:
salt: "ATHENA.MIT.EDUraeburn" salt: "ATHENA.MIT.EDUraeburn"
415448454e412e4d49542e4544557261656275726e 415448454e412e4d49542e4544557261656275726e
password: "password" 70617373776f7264 password: "password" 70617373776f7264
fan-fold result: c01e38688ac86c2e fan-fold result: c01e38688ac86c2e
intermediate key: c11f38688ac86d2f intermediate key: c11f38688ac86d2f
DES key: cbc22fae235298e3 DES key: cbc22fae235298e3
salt: "WHITEHOUSE.GOVdanny" 5748495445484f5553452e474f5664616e6e79 salt: "WHITEHOUSE.GOVdanny"
password: "potatoe" 706f7461746f65 5748495445484f5553452e474f5664616e6e79
fan-fold result: a028944ee63c0416 password: "potatoe" 706f7461746f65
intermediate key: a129944fe63d0416 fan-fold result: a028944ee63c0416
DES key: df3d32a74fd92a01 intermediate key: a129944fe63d0416
DES key: df3d32a74fd92a01
salt: "EXAMPLE.COMpianist" 4558414D504C452E434F4D7069616E697374 salt: "EXAMPLE.COMpianist" 4558414D504C452E434F4D7069616E697374
password: g-clef f09d849e password: g-clef (U+1011E) f09d849e
fan-fold result: 3c4a262c18fab090 fan-fold result: 3c4a262c18fab090
intermediate key: 3d4a262c19fbb091 intermediate key: 3d4a262c19fbb091
DES key: 4ffb26bab0cd9413 DES key: 4ffb26bab0cd9413
salt: "ATHENA.MIT.EDUJuri" + s-caron + "i" + c-acute
415448454e412e4d49542e4544554a757269c5a169c487
password: eszett c39f
fan-fold result: b8f6c40e305afc9e
intermediate key: b9f7c40e315bfd9e
DES key: 62c81a5232b5e69d
salt: "ATHENA.MIT.EDUJuri" + s-caron(U+0161) + "i" + c-acute(U+0107)
415448454e412e4d49542e4544554a757269c5a169c487
password: eszett(U+00DF)
c39f
fan-fold result:b8f6c40e305afc9e
intermediate key: b9f7c40e315bfd9e
DES key: 62c81a5232b5e69d
salt: "AAAAAAAA" 4141414141414141 salt: "AAAAAAAA" 4141414141414141
password: "11119999" 3131313139393939 password: "11119999" 3131313139393939
fan-fold result: e0e0e0e0f0f0f0f0 fan-fold result: e0e0e0e0f0f0f0f0
intermediate key: e0e0e0e0f1f1f101 intermediate key: e0e0e0e0f1f1f101
DES key: 984054d0f1a73e31 DES key: 984054d0f1a73e31
salt: "FFFFAAAA" 4646464641414141 salt: "FFFFAAAA" 4646464641414141
password: "NNNN6666" 4e4e4e4e36363636 password: "NNNN6666" 4e4e4e4e36363636
fan-fold result: 1e1e1e1e0e0e0e0e fan-fold result: 1e1e1e1e0e0e0e0e
intermediate key: 1f1f1f1f0e0e0efe intermediate key: 1f1f1f1f0e0e0efe
skipping to change at page 44, line 46 skipping to change at page 44, line 39
key: 850bb51358548cd05e86768c313e3bfef7511937dcf72c3e key: 850bb51358548cd05e86768c313e3bfef7511937dcf72c3e
salt: "WHITEHOUSE.GOVdanny" salt: "WHITEHOUSE.GOVdanny"
passwd: "potatoe" passwd: "potatoe"
key: dfcd233dd0a43204ea6dc437fb15e061b02979c1f74f377a key: dfcd233dd0a43204ea6dc437fb15e061b02979c1f74f377a
salt: "EXAMPLE.COMbuckaroo" salt: "EXAMPLE.COMbuckaroo"
passwd: "penny" passwd: "penny"
key: 6d2fcdf2d6fbbc3ddcadb5da5710a23489b0d3b69d5d9d4a key: 6d2fcdf2d6fbbc3ddcadb5da5710a23489b0d3b69d5d9d4a
salt: "ATHENA.MIT.EDUJuri" + s-caron + "i" + c-acute salt: "ATHENA.MIT.EDUJuri" + s-caron(U+0161) + "i"
passwd: eszett + c-acute(U+0107)
passwd: eszett(U+00DF)
key: 16d5a40e1ce3bacb61b9dce00470324c831973a7b952feb0 key: 16d5a40e1ce3bacb61b9dce00470324c831973a7b952feb0
salt: "EXAMPLE.COMpianist" salt: "EXAMPLE.COMpianist"
passwd: g-clef passwd: g-clef(U+1011E)
key: 85763726585dbc1cce6ec43e1f751f07f1c4cbb098f40b19 key: 85763726585dbc1cce6ec43e1f751f07f1c4cbb098f40b19
A.5. Modified CRC-32 A.5. Modified CRC-32
Below are modified-CRC32 values for various ASCII and octet strings. Below are modified-CRC32 values for various ASCII and octet strings.
Only the printable ASCII characters are checksummed, no C-style Only the printable ASCII characters are checksummed, no C-style
trailing zero-valued octet. The 32-bit modified CRC and the sequence trailing zero-valued octet. The 32-bit modified CRC and the sequence
of output bytes as used in Kerberos are shown. (The octet values are of output bytes as used in Kerberos are shown. (The octet values are
separated here to emphasize that they are octet values and not 32-bit separated here to emphasize that they are octet values and not 32-bit
numbers, which will be the most convenient form for manipulation in numbers, which will be the most convenient form for manipulation in
skipping to change at page 47, line 42 skipping to change at page 47, line 39
performing encryption is direct control over the negotiation performing encryption is direct control over the negotiation
and to select a "sufficiently strong" encryption algorithm and to select a "sufficiently strong" encryption algorithm
(whatever that means in the context of a given application). (whatever that means in the context of a given application).
While Kerberos directly provides no facility for negotiating While Kerberos directly provides no facility for negotiating
encryption types between the application client and server, encryption types between the application client and server,
there are other means for accomplishing similar goals. For there are other means for accomplishing similar goals. For
example, requesting only "strong" session key types from the example, requesting only "strong" session key types from the
KDC, and assuming that the type actually returned by the KDC KDC, and assuming that the type actually returned by the KDC
will be understood and supported by the application server. will be understood and supported by the application server.
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Normative References Normative References
[Bellare98] [Bellare98]
Bellare, M., Desai, A., Pointcheval, D., and P. Rogaway, Bellare, M., Desai, A., Pointcheval, D., and P. Rogaway,
"Relations Among Notions of Security for Public-Key Encryption "Relations Among Notions of Security for Public-Key Encryption
Schemes". Extended abstract published in Advances in Cryptology- Schemes". Extended abstract published in Advances in Cryptology-
Crypto 98 Proceedings, Lecture Notes in Computer Science Vol. Crypto 98 Proceedings, Lecture Notes in Computer Science Vol.
1462, H. Krawcyzk ed., Springer-Verlag, 1998. 1462, H. Krawcyzk ed., Springer-Verlag, 1998.
[Blumenthal96] [Blumenthal96]
Blumenthal, U., and S. Bellovin, "A Better Key Schedule for DES- Blumenthal, U., and S. Bellovin, "A Better Key Schedule for DES-
Like Ciphers", Proceedings of PRAGOCRYPT '96, 1996. Like Ciphers", Proceedings of PRAGOCRYPT '96, 1996.
[CRC] [CRC]
International Organization for Standardization, "ISO Information International Organization for Standardization, "ISO Information
Processing Systems - Data Communication - High-Level Data Link Processing Systems - Data Communication - High-Level Data Link
Control Procedure - Frame Structure," IS 3309, 3rd Edition, Control Procedure - Frame Structure," IS 3309, 3rd Edition,
October 1984. October 1984.
[DES77] [DES77]
National Bureau of Standards, U.S. Department of Commerce, "Data National Bureau of Standards, U.S. Department of Commerce, "Data
skipping to change at page 49, line 34 skipping to change at page 50, line 4
Cheng, P., and R. Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1", Cheng, P., and R. Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1",
RFC 2202, September 1997. RFC 2202, September 1997.
[IPSEC-HMAC] [IPSEC-HMAC]
Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and
AH", RFC 2404, November 1998. AH", RFC 2404, November 1998.
[Kerb] [Kerb]
Neuman, C., Kohl, J., Ts'o, T., Yu, T., Hartman, S., and K. Neuman, C., Kohl, J., Ts'o, T., Yu, T., Hartman, S., and K.
Raeburn, "The Kerberos Network Authentication Service (V5)", Raeburn, "The Kerberos Network Authentication Service (V5)",
draft-ietf-krb-wg-kerberos-clarifications-00.txt, February 22, draft-ietf-krb-wg-kerberos-clarifications-00.txt, February 22,
2002. Work in progress. 2002. Work in progress.
[Kerb1510] [Kerb1510]
Kohl, J., and C. Neuman, "The Kerberos Network Authentication Kohl, J., and C. Neuman, "The Kerberos Network Authentication
Service (V5)", RFC 1510, September 1993. Service (V5)", RFC 1510, September 1993.
[RC5] [RC5]
Baldwin, R, and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-Pad, and Baldwin, R, and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-Pad, and
RC5-CTS Algorithms", RFC 2040, October 1996. RC5-CTS Algorithms", RFC 2040, October 1996.
[Schneier96] [Schneier96]
Schneier, B., "Applied Cryptography Second Edition", John Wiley & Schneier, B., "Applied Cryptography Second Edition", John Wiley &
Sons, New York, NY, 1996. ISBN 0-471-12845-7. Sons, New York, NY, 1996. ISBN 0-471-12845-7.
Editor's address Editor's address
Kenneth Raeburn Kenneth Raeburn
Massachusetts Institute of Technology Massachusetts Institute of Technology
77 Massachusetts Avenue 77 Massachusetts Avenue
Cambridge, MA 02139 Cambridge, MA 02139
raeburn@mit.edu raeburn@mit.edu
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 28 change blocks. 
58 lines changed or deleted 89 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/