- 1 - IPSEC Working Group Ashar Aziz INTERNET-DRAFT Tom Markson Hemma Prafullchandra Sun Microsystems, Inc. Expires in six months August 1, 1996 Encoding of an Unsigned Diffie-Hellman Public Value Status of this Memo This document is a submission to the IETF Internet Protocol Security (IPSEC) Working Group. Comments are solicited and should be addressed to to the working group mailing list (ipsec@ans.net) or to the authors. This document is an Internet-Draft. 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 draft documents are valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. draft-ietf-ipsec-skip-udh-01.txt [Page 1] INTERNET-DRAFT SKIP-UDH August 1, 1996 Abstract It is useful to be able to communicate public keys in the absence of a certificate hierarchy and a signature infrastructure. This document describes a method by which certificates which communicate Diffie- Hellman public values and parameters may be encoded and securely named. draft-ietf-ipsec-skip-udh-01.txt [Page 2] INTERNET-DRAFT SKIP-UDH August 1, 1996 1. Unsigned Public Keys In public key cryptography, certificates provide a binding between an entity's name and their public key. The signature on the certificate provides this binding. However, certificates tend to be difficult to implement and usually require infrastructure to verify signatures. This infrastructure and certificates, in general, are not in wide use on the Internet. Instead of explicitly binding a name to a public value using a signature, the name may be derived directly from the public key. This can be done by defining the name of the certificate to be the message digest of the public key. Although the public value is distributed in an unsigned manner, there is still a strong binding between a name and the public value, given the collision resistance properties of a message digest. The entity's names need to be securely distributed out of band. This distribution of keys has a number of advantages over conventional signed certificates: no infrastructure is required to use Unsigned Public Keys. No signature algorithm needs to be supported. No complex encoding of certificates is required. A disadvantage of this method is that the name must be securely (but not secretly) communicated to anyone using the key. Since the name is the hash value of the public key, it is a cryptic string of hexadecimal digits which is not user-friendly. The encoding does not specify the hash algorithm used to generate the name. The hash algorithm must be transferred out of band. This may be done by creating a "certificate type" that includes this information. One valid certificate type is "MD5 of Hashed DH Public Key". 2. Encoding of an Unsigned DH public value This encoding scheme is used to authenticate/distribute a DH public value, for cases where the entity's name is the message digest of the public value. draft-ietf-ipsec-skip-udh-01.txt [Page 3] INTERNET-DRAFT SKIP-UDH August 1, 1996 The following is how the public value is encoded for purposes of message digest computation and distribution in the network. All values are in network order. All variable-length fields must begin with a non-zero byte. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Not Valid Before | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Not Valid After | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PrimeLen | Prime (p) (variable length) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Prime (p) (variable length) | GenLen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Generator (g) (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PublicValueLen | Public Value (variable length)~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Public Value (g^i mod p) (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ "Not Valid Before" is the time at which the public value becomes valid. It is in NTP time format [3] (the Integer portion). "Not Valid After" is the time at which the public value expires. It is in NTP [3] time format (the Integer portion). PrimeLen is Length of the DH Prime (p) in bytes. Prime contains the binary representation of the DH prime with most significant byte first. GenLen is the length of the Generator (g) in bytes. Generator is the binary representation of generator with most significant byte first. PublicValueLen is the Length of the Public Value (g^i mod p) in bytes. PublicValue is the binary representation of the DH public value with most significant byte first. The Name associated with the public key and parameters is the cryptographic hash of the above encoding. draft-ietf-ipsec-skip-udh-01.txt [Page 4] INTERNET-DRAFT SKIP-UDH August 1, 1996 3. Verification of the Unsigned Public Value Verification of the Encoding in this instance means verifying that the message digest of the entire encoding (as specified above) is the same as the (securely known) name of the entity. When using this instead of signed certificates, certificate verification MUST be done by performing the message digest computation. 4. Security Considerations The unsigned DH public value can ONLY be used when entities are named using the message digest of their DH public value, AND these names are securely communicated. Unsigned DH public values MUST NOT be used instead of signed DH certificates when entities are named using something other than the message digest of their public value, since this opens up the possibility of an intruder-in-the-middle attack described in [1]. In order to use other naming schemes, signed certificates such as X.509, Secure DNS, PGP, etc. should be used. Acknowledgements We would like to thank all of the people who helped make this draft possible. Jeff Schiller originally suggested using the hash of the public key as the Entity's name. Bill Danielson, Marc Dye, Colin Plumb, Rich Skrenta and Ben Stoltz for reviewing this draft and providing constructive suggestions. References [1] Aziz, A., "Simple Key Management for Internet Protocols", (I-D draft-ietf-ipsec-skip-06.txt), Work in Progress [2] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, April 1992 [3] Mills, D.,"Network Time Protocol", RFC 1305, March 1992 draft-ietf-ipsec-skip-udh-01.txt [Page 5] INTERNET-DRAFT SKIP-UDH August 1, 1996 Author's Address(es) Ashar Aziz Sun Microsystems, Inc. M/S PAL1-550 2550 Garcia Avenue Mountain View, CA 94043 Email: ashar.aziz@eng.sun.com Alternate email address: ashar@incog.com Tom Markson Sun Microsystems, Inc. M/S PAL1-550 2550 Garcia Avenue Mountain View, CA 94043 Email: markson@incog.com Alternate email address: markson@eng.sun.com Hemma Prafullchandra Sun Microsystems, Inc. M/S PAL1-550 2550 Garcia Avenue Mountain View, CA 94043 Email: hemma@eng.sun.com Alternate email address: hemma@incog.com draft-ietf-ipsec-skip-udh-01.txt [Page 6] CONTENTS Status of this Memo.................................. 1 Abstract............................................. 2 1. Unsigned Public Keys................................. 3 2. Encoding of an Unsigned DH public value.............. 3 3. Verification of the Unsigned Public Value............ 5 4. Security Considerations.............................. 5 Acknowledgements..................................... 5 References........................................... 5 Author's Address(es)................................. 6 - i -