home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_i / draft-ietf-ipsec-skip-udh-01.txt < prev    next >
Text File  |  1996-08-02  |  10KB  |  418 lines
  1.  
  2.                            - 1 -
  3.  
  4.  
  5.  
  6. IPSEC Working Group                             Ashar Aziz
  7. INTERNET-DRAFT                                  Tom Markson
  8.                                                 Hemma Prafullchandra
  9.                                                 Sun Microsystems, Inc.
  10.  
  11. Expires in six months                           August 1, 1996
  12.  
  13.  
  14.  
  15.  
  16.  
  17.           Encoding of an Unsigned Diffie-Hellman Public Value
  18.                    <draft-ietf-ipsec-skip-udh-01.txt>
  19.  
  20.  
  21.  
  22. Status of this Memo
  23.  
  24. This document is a submission to the IETF Internet Protocol Security
  25. (IPSEC) Working Group. Comments are solicited and should be addressed to
  26. to the working group mailing list (ipsec@ans.net) or to the authors.
  27.  
  28. This document is an Internet-Draft.  Internet Drafts are working
  29. documents of the Internet Engineering Task Force (IETF), its areas, and
  30. its working Groups. Note that other groups may also distribute working
  31. documents as Internet Drafts.
  32.  
  33. Internet-Drafts draft documents are valid for a maximum of six months
  34. and may be updated, replaced, or obsoleted by other documents at any
  35. time. It is inappropriate to use Internet-Drafts as reference material
  36. or to cite them other than as "work in progress."
  37.  
  38. To learn the current status of any Internet-Draft, please check the
  39. "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
  40. Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  41. munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  42. ftp.isi.edu (US West Coast).
  43.  
  44. Distribution of this memo is unlimited.
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54. draft-ietf-ipsec-skip-udh-01.txt                    [Page 1]
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61.  
  62. INTERNET-DRAFT            SKIP-UDH            August 1, 1996
  63.  
  64.  
  65.  
  66. Abstract
  67.  
  68. It is useful to be able to communicate public keys in the absence of a
  69. certificate hierarchy and a signature infrastructure.  This document
  70. describes a method by which certificates which communicate Diffie-
  71. Hellman public values and parameters may be encoded and securely named.
  72.  
  73.  
  74.  
  75.  
  76.  
  77.  
  78.  
  79.  
  80.  
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. draft-ietf-ipsec-skip-udh-01.txt                    [Page 2]
  115.  
  116.  
  117.  
  118.  
  119.  
  120.  
  121.  
  122. INTERNET-DRAFT            SKIP-UDH            August 1, 1996
  123.  
  124.  
  125.  
  126. 1.  Unsigned Public Keys
  127.  
  128. In public key cryptography, certificates provide a binding between an
  129. entity's name and their public key.  The signature on the certificate
  130. provides this binding.  However, certificates tend to be difficult to
  131. implement and usually require infrastructure to verify signatures.  This
  132. infrastructure and certificates, in general, are not in wide use on the
  133. Internet.  Instead of explicitly binding a name to a public value using
  134. a signature, the name may be derived directly from the public key. This
  135. can be done by defining the name of the certificate to be the message
  136. digest of the public key.
  137.  
  138. Although the public value is distributed in an unsigned manner, there is
  139. still a strong binding between a name and the public value, given the
  140. collision resistance properties of a message digest. The entity's names
  141. need to be securely distributed out of band.
  142.  
  143. This distribution of keys has a number of advantages over conventional
  144. signed certificates:  no infrastructure is required to use Unsigned
  145. Public Keys.  No signature algorithm needs to be supported. No complex
  146. encoding of certificates is required.
  147.  
  148. A disadvantage of this method is that the name must be securely (but not
  149. secretly) communicated to anyone using the key.  Since the name is the
  150. hash value of the public key, it is a cryptic string of hexadecimal
  151. digits which is not user-friendly.
  152.  
  153. The encoding does not specify the hash algorithm used to generate the
  154. name.  The hash algorithm must be transferred out of band.  This may be
  155. done by creating a "certificate type" that includes this information.
  156. One valid certificate type is "MD5 of Hashed DH Public Key".
  157.  
  158.  
  159. 2.  Encoding of an Unsigned DH public value
  160.  
  161. This encoding scheme is used to authenticate/distribute a DH public
  162. value, for cases where the entity's name is the message digest of the
  163. public value.
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.  
  171.  
  172.  
  173.  
  174. draft-ietf-ipsec-skip-udh-01.txt                    [Page 3]
  175.  
  176.  
  177.  
  178.  
  179.  
  180.  
  181.  
  182. INTERNET-DRAFT            SKIP-UDH            August 1, 1996
  183.  
  184.  
  185.  
  186. The following is how the public value is encoded for purposes
  187. of message digest computation and distribution in the network.
  188. All values are in network order. All variable-length fields
  189. must begin with a non-zero byte.
  190.  
  191.      0                   1                   2                   3
  192.      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
  193.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  194.     |                   Not Valid Before                            |
  195.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  196.     |                   Not Valid After                             |
  197.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  198.     |            PrimeLen           | Prime (p)   (variable length) ~
  199.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  200.     ~  Prime (p)  (variable length) |            GenLen             |
  201.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  202.     | Generator (g) (variable length)                               |
  203.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  204.     |        PublicValueLen         | Public Value (variable length)~
  205.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  206.     ~  Public Value (g^i mod p)    (variable length)                |
  207.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  208.  
  209.  
  210. "Not Valid Before" is the time at which the public value becomes valid.
  211. It is in NTP time format [3] (the Integer portion). "Not Valid After" is
  212. the time at which the public value expires. It is in NTP [3] time format
  213. (the Integer portion).
  214.  
  215. PrimeLen is Length of the DH Prime (p) in bytes.  Prime contains the
  216. binary representation of the DH prime with most significant byte first.
  217. GenLen is the length of the Generator (g) in bytes. Generator is the
  218. binary representation of generator with most significant byte first.
  219. PublicValueLen is the Length of the Public Value (g^i mod p) in bytes.
  220. PublicValue is the binary representation of the DH public value with
  221. most significant byte first.
  222.  
  223. The Name associated with the public key and parameters is the
  224. cryptographic hash of the above encoding.
  225.  
  226.  
  227.  
  228.  
  229.  
  230.  
  231.  
  232.  
  233.  
  234. draft-ietf-ipsec-skip-udh-01.txt                    [Page 4]
  235.  
  236.  
  237.  
  238.  
  239.  
  240.  
  241.  
  242. INTERNET-DRAFT            SKIP-UDH            August 1, 1996
  243.  
  244.  
  245.  
  246. 3.  Verification of the Unsigned Public Value
  247.  
  248. Verification of the Encoding in this instance means verifying that the
  249. message digest of the entire encoding (as specified above) is the same
  250. as the (securely known) name of the entity. When using this instead of
  251. signed certificates, certificate verification MUST be done by performing
  252. the message digest computation.
  253.  
  254.  
  255. 4.  Security Considerations
  256.  
  257. The unsigned DH public value can ONLY be used when entities are named
  258. using the message digest of their DH public value, AND these names are
  259. securely communicated. Unsigned DH public values MUST NOT be used
  260. instead of signed DH certificates when entities are named using
  261. something other than the message digest of their public value, since
  262. this opens up the possibility of an intruder-in-the-middle attack
  263. described in [1]. In order to use other naming schemes, signed
  264. certificates such as X.509, Secure DNS, PGP, etc.  should be used.
  265.  
  266.  
  267. Acknowledgements
  268.  
  269. We would like to thank all of the people who helped make this draft
  270. possible.
  271.  
  272. Jeff Schiller originally suggested using the hash of the public key as
  273. the Entity's name.
  274.  
  275. Bill Danielson, Marc Dye, Colin Plumb, Rich Skrenta and Ben Stoltz for
  276. reviewing this draft and providing constructive suggestions.
  277.  
  278.  
  279. References
  280.  
  281. [1] Aziz, A., "Simple Key Management for Internet Protocols", (I-D
  282.     draft-ietf-ipsec-skip-06.txt), Work in Progress
  283.  
  284. [2] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, April 1992
  285.  
  286. [3] Mills, D.,"Network Time Protocol", RFC 1305, March 1992
  287.  
  288.  
  289.  
  290.  
  291.  
  292.  
  293.  
  294. draft-ietf-ipsec-skip-udh-01.txt                    [Page 5]
  295.  
  296.  
  297.  
  298.  
  299.  
  300.  
  301.  
  302. INTERNET-DRAFT            SKIP-UDH            August 1, 1996
  303.  
  304.  
  305.  
  306. Author's Address(es)
  307.  
  308.      Ashar Aziz
  309.      Sun Microsystems, Inc.
  310.      M/S PAL1-550
  311.      2550 Garcia Avenue
  312.      Mountain View, CA 94043
  313.  
  314.      Email: ashar.aziz@eng.sun.com
  315.      Alternate email address: ashar@incog.com
  316.  
  317.      Tom Markson
  318.      Sun Microsystems, Inc.
  319.      M/S PAL1-550
  320.      2550 Garcia Avenue
  321.      Mountain View, CA 94043
  322.  
  323.      Email: markson@incog.com
  324.      Alternate email address: markson@eng.sun.com
  325.  
  326.      Hemma Prafullchandra
  327.      Sun Microsystems, Inc.
  328.      M/S PAL1-550
  329.      2550 Garcia Avenue
  330.      Mountain View, CA 94043
  331.  
  332.      Email: hemma@eng.sun.com
  333.      Alternate email address: hemma@incog.com
  334.  
  335.  
  336.  
  337.  
  338.  
  339.  
  340.  
  341.  
  342.  
  343.  
  344.  
  345.  
  346.  
  347.  
  348.  
  349.  
  350.  
  351.  
  352.  
  353.  
  354. draft-ietf-ipsec-skip-udh-01.txt                    [Page 6]
  355.  
  356.  
  357.  
  358.  
  359.  
  360.  
  361.  
  362.  
  363.  
  364.  
  365.  
  366.                                 CONTENTS
  367.  
  368.  
  369.     Status of this Memo..................................  1
  370.  
  371.     Abstract.............................................  2
  372.  
  373. 1.  Unsigned Public Keys.................................  3
  374.  
  375. 2.  Encoding of an Unsigned DH public value..............  3
  376.  
  377. 3.  Verification of the Unsigned Public Value............  5
  378.  
  379. 4.  Security Considerations..............................  5
  380.  
  381.     Acknowledgements.....................................  5
  382.  
  383.     References...........................................  5
  384.  
  385.     Author's Address(es).................................  6
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394.  
  395.  
  396.  
  397.  
  398.  
  399.  
  400.  
  401.  
  402.  
  403.  
  404.  
  405.  
  406.  
  407.  
  408.  
  409.  
  410.  
  411.  
  412.  
  413.  
  414.                            - i -
  415.  
  416.  
  417.  
  418.