for (8byteblock in s) {
}
;; for loop terminated
tempkey = key_correction(add_parity_bits(tempstring));
;; tempkey
;; `\xc1\x1f8h\x8a\xc8m\x2f’ (length 8 bytes)
;; c1 1f 38 68 8a c8 6d 2f
;; 11000001 00011111 00111000 01101000 10001010 11001000
;; 01101101 00101111
key = key_correction(DES-CBC-check(s,tempkey));
;; key
;; `\xcb\xc2\x2f\xae\x23R\x98\xe3’ (length 8 bytes)
;; cb c2 2f ae 23 52 98 e3
;; 11001011 11000010 00101111 10101110 00100011 01010010
;; 10011000 11100011
;; string_to_key key:
;; `\xcb\xc2\x2f\xae\x23R\x98\xe3’ (length 8 bytes)
;; cb c2 2f ae 23 52 98 e3
A.3. DES3 DR and DK
These tests show the derived-random and derived-key values for the
des3-hmac-sha1-kd encryption scheme, using the DR and DK functions
defined in section 6.3.1. The input keys were randomly generated;
the usage values are from this specification.
key: dce06b1f64c857a11c3db57c51899b2cc1791008ce973b92
usage: 0000000155
DR: 935079d14490a75c3093c4a6e8c3b049c71e6ee705
DK: 925179d04591a79b5d3192c4a7e9c289b049c71f6ee604cd
key: 5e13d31c70ef765746578531cb51c15bf11ca82c97cee9f2
usage: 00000001aa
DR: 9f58e5a047d894101c469845d67ae3c5249ed812f2
DK: 9e58e5a146d9942a101c469845d67a20e3c4259ed913f207
key: 98e6fd8a04a4b6859b75a176540b9752bad3ecd610a252bc
usage: 0000000155
DR: 12fff90c773f956d13fc2ca0d0840349dbd39908eb
DK: 13fef80d763e94ec6d13fd2ca1d085070249dad39808eabf
key: 622aec25a2fe2cad7094680b7c64940280084c1a7cec92b5
usage: 00000001aa
DR: f8debf05b097e7dc0603686aca35d91fd9a5516a70
DK: f8dfbf04b097e6d9dc0702686bcb3489d91fd9a4516b703e
key: d3f8298ccb166438dcb9b93ee5a7629286a491f838f802fb
usage: 6b65726265726f73 ("kerberos")
DR: 2270db565d2a3d64cfbfdc5305d4f778a6de42d9da
DK: 2370da575d2a3da864cebfdc5204d56df779a7df43d9da43
key: c1081649ada74362e6a1459d01dfd30d67c2234c940704da
usage: 0000000155
DR: 348056ec98fcc517171d2b4d7a9493af482d999175
DK: 348057ec98fdc48016161c2a4c7a943e92ae492c989175f7
key: 5d154af238f46713155719d55e2f1f790dd661f279a7917c
usage: 00000001aa
DR: a8818bc367dadacbe9a6c84627fb60c294b01215e5
DK: a8808ac267dada3dcbe9a7c84626fbc761c294b01315e5c1
key: 798562e049852f57dc8c343ba17f2ca1d97394efc8adc443
usage: 0000000155
DR: c813f88b3be2b2f75424ce9175fbc8483b88c8713a
DK: c813f88a3be3b334f75425ce9175fbe3c8493b89c8703b49
key: 26dce334b545292f2feab9a8701a89a4b99eb9942cecd016
usage: 00000001aa
DR: f58efc6f83f93e55e695fd252cf8fe59f7d5ba37ec
DK: f48ffd6e83f83e7354e694fd252cf83bfe58f7d5ba37ec5d
A.4. DES3string_to_key
These are the keys generated for some of the above input strings for
triple-DES with key derivation as defined in section 6.3.1.
salt: "ATHENA.MIT.EDUraeburn"
passwd: "password"
key: 850bb51358548cd05e86768c313e3bfef7511937dcf72c3e
salt: "WHITEHOUSE.GOVdanny"
passwd: "potatoe"
key: dfcd233dd0a43204ea6dc437fb15e061b02979c1f74f377a
salt: "EXAMPLE.COMbuckaroo"
passwd: "penny"
key: 6d2fcdf2d6fbbc3ddcadb5da5710a23489b0d3b69d5d9d4a
salt: "ATHENA.MIT.EDUJuri" + s-caron(U+0161) + "i"
+ c-acute(U+0107)
passwd: eszett(U+00DF)
key: 16d5a40e1ce3bacb61b9dce00470324c831973a7b952feb0
salt: "EXAMPLE.COMpianist"
passwd: g-clef(U+1011E)
key: 85763726585dbc1cce6ec43e1f751f07f1c4cbb098f40b19
A.5. Modified CRC-32
Below are modified-CRC32 values for various ASCII and octet strings.
Only the printable ASCII characters are checksummed, without a C-
style 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 separated here to emphasize that they are octet values and
not 32-bit numbers, which will be the most convenient form for
manipulation in some implementations. The bit and byte order used
internally for such a number is irrelevant; the octet sequence
generated is what is important.)
mod-crc-32("foo") = 33 bc 32 73
mod-crc-32("test0123456789") = d6 88 3e b8
mod-crc-32("MASSACHVSETTS INSTITVTE OF TECHNOLOGY") = f7 80 41 e3
mod-crc-32(8000) = 4b 98 83 3b
mod-crc-32(0008) = 32 88 db 0e
mod-crc-32(0080) = 20 83 b8 ed
mod-crc-32(80) = 20 83 b8 ed
mod-crc-32(80000000) = 3b b6 59 ed
mod-crc-32(00000001) = 96 30 07 77
B. Significant Changes from RFC 1510
The encryption and checksum mechanism profiles are new. The old
specification defined a few operations for various mechanisms but
didn’t outline what abstract properties should be required of new
mechanisms, or how to ensure that a mechanism specification is
complete enough for interoperability between implementations. The
new profiles differ from the old specification in a few ways:
Some message definitions in [Kerb1510] could be read as permitting
the initial vector to be specified by the application; the text
was too vague. It is explicitly not permitted in this
specification. Some encryption algorithms may not use
initialization vectors, so relying on chosen, secret
initialization vectors for security is unwise. Also, the
prepended confounder in the existing algorithms is roughly
equivalent to a per-message initialization vector that is revealed
in encrypted form. However, carrying state across from one
encryption to another is explicitly permitted through the opaque
"cipher state" object.
The use of key derivation is new.
Several new methods are introduced, including generation of a key
in wire-protocol format from random input data.
The means for influencing the string-to-key algorithm are laid out
more clearly.
Triple-DES support is new.
The pseudo-random function is new.
The des-cbc-crc, DES string-to-key and CRC descriptions have been
updated to align them with existing implementations.
[Kerb1510] did not indicate what character set or encoding might be
used for pass phrases and salts.
In [Kerb1510], key types, encryption algorithms, and checksum
algorithms were only loosely associated, and the association was not
well described. In this specification, key types and encryption
algorithms have a one-to-one correspondence, and associations between
encryption and checksum algorithms are described so that checksums
can be computed given negotiated keys, without requiring further
negotiation for checksum types.
Notes
[1] Although Message Authentication Code (MAC) or Message Integrity
Check (MIC) would be more appropriate terms for many of the uses
in this document, we continue to use the term checksum for
historical reasons.
[2] Extending CBC mode across messages would be one obvious example
of this chaining. Another might be the use of counter mode, with
a counter randomly initialized and attached to the ciphertext; a
second message could continue incrementing the counter when
chaining the cipher state, thus avoiding having to transmit
another counter value. However, this chaining is only useful for
uninterrupted, ordered sequences of messages.
[3] In the case of Kerberos, the encrypted objects will generally be
ASN.1 DER encodings, which contain indications of their length in
the first few octets.
[4] As of the time of this writing, new modes of operation have been
proposed, some of which may permit encryption and integrity
protection simultaneously. After some of these proposals have
been subjected to adequate analysis, we may wish to formulate a
new simplified profile based on one of them.
[5] It should be noted that the sample vector in appendix B.2 of the
original paper appears to be incorrect. Two independent
implementations from the specification (one in C by Marc
Horowitz, and another in Scheme by Bill Sommerfeld) agree on a
value different from that in [Blumenthal96].
[6] For example, in MIT’s implementation of [Kerb1510], the rsa-md5
unkeyed checksum of application data may be included in an
authenticator encrypted in a service’s key.
[7] Using a variant of the key limits the use of a key to a
particular function, separating the functions of generating a
checksum from other encryption performed using the session key.
The constant 0xF0F0F0F0F0F0F0F0 was chosen because it maintains
key parity. The properties of DES precluded the use of the
complement. The same constant is used for similar purpose in the
Message Integrity Check in the Privacy Enhanced Mail standard.
[8] Perhaps one of the more common reasons for directly performing
encryption is direct control over the negotiation and to select a
"sufficiently strong" encryption algorithm (whatever that means
in the context of a given application). Although Kerberos
directly provides no direct facility for negotiating encryption
types between the application client and server, there are other
means to accomplish similar goals (for example, requesting only
"strong" session key types from the KDC, and assuming that the
type actually returned by the KDC will be understood and
supported by the application server).
Normative References
[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, RFC
2434, October 1998.
[Bellare98] Bellare, M., Desai, A., Pointcheval, D., and P.
Rogaway, "Relations Among Notions of Security for
Public-Key Encryption Schemes". Extended abstract
published in Advances in Cryptology-Crypto 98
Proceedings, Lecture Notes in Computer Science Vol.
1462, H. Krawcyzk ed., Springer-Verlag, 1998.
[Blumenthal96] Blumenthal, U. and S. Bellovin, "A Better Key Schedule
for DES-Like Ciphers", Proceedings of PRAGOCRYPT ’96,
1996.
[CRC] International Organization for Standardization, "ISO
Information Processing Systems - Data Communication -
High-Level Data Link Control Procedure - Frame
Structure," IS 3309, 3rd Edition, October 1984.
[DES77] National Bureau of Standards, U.S. Department of
Commerce, "Data Encryption Standard," Federal
Information Processing Standards Publication 46,
Washington, DC, 1977.
[DESI81] National Bureau of Standards, U.S. Department of
Commerce, "Guidelines for implementing and using NBS
Data Encryption Standard," Federal Information
Processing Standards Publication 74, Washington, DC,
1981.
[DESM80] National Bureau of Standards, U.S. Department of
Commerce, "DES Modes of Operation," Federal
Information Processing Standards Publication 81,
Springfield, VA, December 1980.
[Dolev91] Dolev, D., Dwork, C., and M. Naor, "Non-malleable
cryptography", Proceedings of the 23rd Annual
Symposium on Theory of Computing, ACM, 1991.
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication", RFC 2104,
February 1997.
[KRB5-AES] Raeburn, K., "Advanced Encryption Standard (AES)
Encryption for Kerberos 5", RFC 3962, February 2005.
[MD4-92] Rivest, R., "The MD4 Message-Digest Algorithm", RFC
1320, April 1992.
[MD5-92] Rivest, R., "The MD5 Message-Digest Algorithm ", RFC
1321, April 1992.
[SG92] Stubblebine, S. and V. D. Gligor, "On Message
Integrity in Cryptographic Protocols," in Proceedings
of the IEEE Symposium on Research in Security and
Privacy, Oakland, California, May 1992.
Informative References
[Bellovin91] Bellovin, S. M. and M. Merrit, "Limitations of the
Kerberos Authentication System", in Proceedings of the
Winter 1991 Usenix Security Conference, January, 1991.
[Bellovin99] Bellovin, S. M. and D. Atkins, private communications,
1999.
[EFF-DES] Electronic Frontier Foundation, "Cracking DES: Secrets
of Encryption Research, Wiretap Politics, and Chip
Design", O’Reilly & Associates, Inc., May 1998.
[ESP-DES] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher
Algorithm With Explicit IV", RFC 2405, November 1998.
[GSS-KRB5] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
RFC 1964, June 1996.
[HMAC-TEST] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and
HMAC-SHA-1", RFC 2202, September 1997.
[IPSEC-HMAC] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96
within ESP and AH", RFC 2404, November 1998.
[Kerb] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", Work in
Progress, September 2004.
[Kerb1510] Kohl, J. and C. Neuman, "The Kerberos Network
Authentication Service (V5)", RFC 1510, September
1993.
[RC5] Baldwin, R. and R. Rivest, "The RC5, RC5-CBC, RC5-
CBC-Pad, and RC5-CTS Algorithms", RFC 2040, October
1996.
[RFC1851] Karn, P., Metzger, P., and W. Simpson, "The ESP Triple
DES Transform", RFC 1851, September 1995.
[Schneier96] Schneier, B., "Applied Cryptography Second Edition",
John Wiley & Sons, New York, NY, 1996. ISBN 0-471-
12845-7.
Editor’s Address
Kenneth Raeburn
Massachusetts Institute of Technology
77 Massachusetts Avenue
Cambridge, MA 02139
EMail: raeburn@mit.edu
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the IETF’s procedures with respect to rights in IETF Documents can
be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.