Network Working Group                                  P Karn [Qualcomm]
Internet Draft                                  W A Simpson [DayDreamer]
expires in six months                                          July 1997


               Photuris: Extended Schemes and Attributes
                 draft-simpson-photuris-schemes-03.txt


Status of this Memo

   This document is an Internet-Draft.  Internet Drafts are working doc-
   uments of the Internet Engineering Task Force (IETF), its Areas, and
   its Working Groups.  Note that other groups may also distribute work-
   ing 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 not appropriate to use Internet Drafts as refer-
   ence material, or to cite them other than as a ``working draft'' or
   ``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)
      ds.internic.net (US East Coast)
      ftp.isi.edu (US West Coast)
      munnari.oz.au (Pacific Rim)

   Distribution of this memo is unlimited.

Abstract

   Photuris is a session-key management protocol.  Extensible Exchange-
   Schemes are provided to enable future implementation changes without
   affecting the basic protocol.

   Additional authentication attributes are included for use with the IP
   Authentication Header (AH).

   Additional confidentiality attributes are included for use with the
   IP Encapsulating Security Protocol (ESP).






Karn & Simpson            expires in six months                 [Page i]


DRAFT                    Schemes and Attributes                July 1997


1.  Additional Exchange-Schemes

   The packet format and basic facilities are already defined for Pho-
   turis [RFC-zzzz].

   These optional Exchange-Schemes are specified separately, and no sin- |
   gle implementation is expected to support all of them.

   This document defines the following values:

   (3)   Implementation Optional.  Any modulus (p) with a recommended
         generator (g) of 3.  When the Exchange-Scheme Size is non-zero, |
         the modulus is contained in the Exchange-Scheme Value field in
         the list of Offered-Schemes.

         An Exchange-Scheme Size of zero is invalid.                     |

         The Key-Generation-Function is "MD5 Hash".

         The Privacy-Method is "Simple Masking".

         The Validity-Method is "MD5-KMpKp Check".

         This combination of features requires a modulus with at least   +
         64-bits of cryptographic strength.

   (4)   Implementation Optional.  Any modulus (p) with a recommended
         generator (g) of 2.  When the Exchange-Scheme Size is non-zero, |
         the modulus is contained in the Exchange-Scheme Value field in
         the list of Offered-Schemes.

         When the Exchange-Scheme Size field is zero, includes by refer- |
         ence all of the moduli specified in the list of Offered-Schemes |
         for Scheme #2.                                                  |

         The Key-Generation-Function is "MD5 Hash".

         The Privacy-Method is "DES-CBC over Mask".

         The Validity-Method is "MD5-KMpKp Check".

         This combination of features requires a modulus with at least   +
         64-bits of cryptographic strength.

   (5)   Implementation Optional.  Any modulus (p) with a recommended
         generator (g) of 5.  When the Exchange-Scheme Size is non-zero, |
         the modulus is contained in the Exchange-Scheme Value field in
         the list of Offered-Schemes.



Karn & Simpson            expires in six months                 [Page 1]


DRAFT                    Schemes and Attributes                July 1997


         An Exchange-Scheme Size of zero is invalid.                     |

         The Key-Generation-Function is "MD5 Hash".

         The Privacy-Method is "Simple Masking".

         The Validity-Method is "MD5-KMpKp Check".

         This combination of features requires a modulus with at least   +
         64-bits of cryptographic strength.

   (6)   Implementation Optional.  Any modulus (p) with a recommended
         generator (g) of 3.  When the Exchange-Scheme Size is non-zero, |
         the modulus is contained in the Exchange-Scheme Value field in
         the list of Offered-Schemes.

         When the Exchange-Scheme Size field is zero, includes by refer- |
         ence all of the moduli specified in the list of Offered-Schemes |
         for Scheme #3.                                                  |

         The Key-Generation-Function is "MD5 Hash".

         The Privacy-Method is "DES-CBC over Mask".

         The Validity-Method is "MD5-KMpKp Check".

         This combination of features requires a modulus with at least   +
         64-bits of cryptographic strength.

   (7)   Implementation Optional.  Any modulus (p) with a variable gen-
         erator (g).  When the Exchange-Scheme Size is non-zero, the     |
         pair [g,p] is contained in the Exchange-Scheme Value field in
         the list of Offered-Schemes.  Each is encoded in a separate     +
         Variable Precision Number (VPN).  The generator VPN is followed +
         by (concatenated to) the modulus VPN, and the result is nested  +
         inside the Exchange-Scheme Value field.                         +

         An Exchange-Scheme Size of zero is invalid.

         The Key-Generation-Function is "MD5 Hash".                      |

         The Privacy-Method is "Simple Masking".

         The Validity-Method is "MD5-KMpKp Check".

         This combination of features requires a modulus with at least   +
         64-bits of cryptographic strength.                              +




Karn & Simpson            expires in six months                 [Page 2]


DRAFT                    Schemes and Attributes                July 1997


         When more than one modulus is specified for a given kind of     +
         Scheme, the Size of the modulus MUST be unique, independent of  +
         the Size of the generator.

   (8)   Implementation Optional.  Any modulus (p) with a recommended
         generator (g) of 2.  When the Exchange-Scheme Size is non-zero, |
         the modulus is contained in the Exchange-Scheme Value field in
         the list of Offered-Schemes.

         When the Exchange-Scheme Size field is zero, includes by refer- |
         ence all of the moduli specified in the list of Offered-Schemes |
         for Schemes #2 and #4.                                          |

         The Key-Generation-Function is "SHA1 Hash".

         The Privacy-Method is "DES-EDE3-CBC over Mask".

         The Validity-Method is "SHA1-KMpKp Check".

         This combination of features requires a modulus with at least   +
         112-bits of cryptographic strength.

   (10)  Implementation Optional.  Any modulus (p) with a recommended
         generator (g) of 5.  When the Exchange-Scheme Size is non-zero, |
         the modulus is contained in the Exchange-Scheme Value field in
         the list of Offered-Schemes.

         When the Exchange-Scheme Size field is zero, includes by refer- |
         ence all of the moduli specified in the list of Offered-Schemes |
         for Scheme #5.                                                  |

         The Key-Generation-Function is "MD5 Hash".

         The Privacy-Method is "DES-CBC over Mask".

         The Validity-Method is "MD5-KMpKp Check".

         This combination of features requires a modulus with at least   +
         64-bits of cryptographic strength.

   (12)  Implementation Optional.  Any modulus (p) with a recommended
         generator (g) of 3.  When the Exchange-Scheme Size is non-zero, |
         the modulus is contained in the Exchange-Scheme Value field in
         the list of Offered-Schemes.

         When the Exchange-Scheme Size field is zero, includes by refer- |
         ence all of the moduli specified in the list of Offered-Schemes |
         for Schemes #3 and #6.                                          |



Karn & Simpson            expires in six months                 [Page 3]


DRAFT                    Schemes and Attributes                July 1997


         The Key-Generation-Function is "SHA1 Hash".

         The Privacy-Method is "DES-EDE3-CBC over Mask".

         The Validity-Method is "SHA1-KMpKp Check".

         This combination of features requires a modulus with at least   +
         112-bits of cryptographic strength.

   (14)  Implementation Optional.  Any modulus (p) with a variable gen-
         erator (g).  When the Exchange-Scheme Size is non-zero, the     |
         pair [g,p] is contained in the Exchange-Scheme Value field in
         the list of Offered-Schemes.  Each is encoded in a separate     +
         Variable Precision Number (VPN).  The generator VPN is followed +
         by (concatenated to) the modulus VPN, and the result is nested  +
         inside the Exchange-Scheme Value field.                         +

         When the Exchange-Scheme Size field is zero, includes by refer- +
         ence all of the moduli specified in the list of Offered-Schemes +
         for Scheme #7.

         The Key-Generation-Function is "MD5 Hash".                      |

         The Privacy-Method is "DES-CBC over Mask".

         The Validity-Method is "MD5-KMpKp Check".

         This combination of features requires a modulus with at least   +
         64-bits of cryptographic strength.                              +

         When more than one modulus is specified for a given kind of     +
         Scheme, the Size of the modulus MUST be unique, independent of  +
         the Size of the generator.

   (20)  Implementation Optional.  Any modulus (p) with a recommended
         generator (g) of 5.  When the Exchange-Scheme Size is non-zero, |
         the modulus is contained in the Exchange-Scheme Value field in
         the list of Offered-Schemes.

         When the Exchange-Scheme Size field is zero, includes by refer- |
         ence all of the moduli specified in the list of Offered-Schemes |
         for Schemes #5 and #10.                                         |

         The Key-Generation-Function is "SHA1 Hash".

         The Privacy-Method is "DES-EDE3-CBC over Mask".

         The Validity-Method is "SHA1-KMpKp Check".



Karn & Simpson            expires in six months                 [Page 4]


DRAFT                    Schemes and Attributes                July 1997


         This combination of features requires a modulus with at least   +
         112-bits of cryptographic strength.

   (28)  Implementation Optional.  Any modulus (p) with a variable gen-
         erator (g).  When the Exchange-Scheme Size is non-zero, the     |
         pair [g,p] is contained in the Exchange-Scheme Value field in
         the list of Offered-Schemes.  Each is encoded in a separate     +
         Variable Precision Number (VPN).  The generator VPN is followed +
         by (concatenated to) the modulus VPN, and the result is nested  +
         inside the Exchange-Scheme Value field.                         +

         When the Exchange-Scheme Size field is zero, includes by refer- +
         ence all of the moduli specified in the list of Offered-Schemes +
         for Schemes #7 and #14.

         The Key-Generation-Function is "SHA1 Hash".                     |

         The Privacy-Method is "DES-EDE3-CBC over Mask".

         The Validity-Method is "SHA1-KMpKp Check".

         This combination of features requires a modulus with at least   +
         112-bits of cryptographic strength.                             +

         When more than one modulus is specified for a given kind of     +
         Scheme, the Size of the modulus MUST be unique, independent of  +
         the Size of the generator.



2.  Additional Key-Generation-Function
2.1.  SHA1 Hash

   SHA1 [FIPS-180-1] is used as a pseudo-random-function for generating
   the key(s).  The key(s) begin with the most significant bits of the
   hash.  SHA1 is iterated as needed to generate the requisite length of
   key material.

   When an individual key does not use all 160-bits of the last hash,    |
   any remaining unused (least significant) bits of the last hash are
   discarded.  When combined with other uses of key generation for the
   same purpose, the next key will begin with a new hash iteration.









Karn & Simpson            expires in six months                 [Page 5]


DRAFT                    Schemes and Attributes                July 1997


3.  Additional Privacy-Methods
3.1.  DES-CBC over Mask

   As described in [RFC-zzzz] "Privacy-Key Computation", sufficient pri- |
   vacy-key material is generated to match the message length, beginning
   with the next field after the SPI, and including the Padding.  The
   message is masked by XOR with the privacy-key.

   Then, the Key-Generation-Function is iterated to generate a DES key.  |
   The most significant 64-bits (8 bytes) of the generated hash are used
   for the privacy-key, and the remainder are discarded.  Although
   extremely rare, the 64 weak, semi-weak, and possibly weak keys
   [Schneier95, pages 280-282] are discarded.  The Key-Generation-       |
   Function is iterated until a valid key is obtained.

   The least significant bit of each key byte is ignored (or set to par-
   ity when the implementation requires).

   Message encryption begins with the next field after the SPI, and con-
   tinues to the end of the data indicated by the UDP Length.


3.2.  DES-EDE3-CBC over Mask

   This is "Triple DES" outer-CBC EDE encryption (and DED decryption)
   with three 56-bit keys [KR96].

   As described in [RFC-zzzz] "Privacy-Key Computation", sufficient pri- |
   vacy-key material is generated to match the message length, beginning
   with the next field after the SPI, and including the Padding.  The
   message is masked by XOR with the privacy-key.

   Then, the Key-Generation-Function is iterated (at least) three times  |
   to generate the three DES keys.  The most significant 64-bits (8
   bytes) of each generated hash are used for each successive privacy-
   key, and the remainder are discarded.  Each key is examined sequen-
   tially, in the order used for encryption.  A key that is identical to
   a previous key MUST be discarded.  Although extremely rare, the 64
   weak, semi-weak, and possibly weak keys [Schneier95, pages 280-282]
   MUST be discarded.  The Key-Generation-Function is iterated until a   |
   valid key is obtained before generating the next key.

   In all three keys, the least significant bit of each key byte is
   ignored (or set to parity when the implementation requires).

   Message encryption begins with the next field after the SPI, and con-
   tinues to the end of the data indicated by the UDP Length.




Karn & Simpson            expires in six months                 [Page 6]


DRAFT                    Schemes and Attributes                July 1997


4.  Additional Validity-Method
4.1.  SHA1-KMpKp Check

   As described in [RFC-zzzz] "Validity Verification", the SHA1
   [FIPS-180-1] hash is calculated over the concatenation of

      SHA1( key, data, datafill, key, sha1fill )

   where the key is the computed shared-secret.

   The leading key is not padded to any particular alignment.

   The datafill uses the same pad-with-length technique defined for
   sha1fill.  This padding and length is implicit, and does not appear
   in the datagram.  The datafill length includes only the leading key
   and data.

   The resulting Verification field is a 160-bit Variable Precision Num-
   ber (22 bytes including Size).


5.  Additional Attributes

   The attribute format and basic facilities are already defined for
   Photuris [RFC-zzzz].

   These optional attributes are specified separately, and no single
   implementation is expected to support all of them.

   This document defines the following values:

     Use    Type
      I       4  SHA1-KMpKp Symmetric Identification
      X       6  SHA1-KpMpKp Authentication
      E       8  DES-CBC Encryption
      E       9  DES Decryption
      E      11  XOR

      A  AH-only Attribute-Choice
      E  ESP-only Attribute-Choice
      I  Identity-Choice
      X  dependent on list location









Karn & Simpson            expires in six months                 [Page 7]


DRAFT                    Schemes and Attributes                July 1997


5.1.  SHA1-KMpKp Symmetric Identification

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Attribute   |    Length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Attribute        4

   Length           0

   When selected as an Identity-Choice, the immediately following Iden-
   tification field contains an unstructured Variable Precision Number.
   Valid Identifications and symmetric secret-keys are preconfigured by
   the parties.

   There is no required format or content for the Identification value.
   The value may be a number or string of any kind.  See [RFC-zzzz] "Use
   of Identification and Secrets" for details.

   The authentication symmetric secret-key (as specified) is selected
   based on the contents of the Identification field.  All implementa-
   tions MUST support at least 62 bytes.  The selected symmetric secret-
   key SHOULD provide at least 80-bits of cryptographic strength.

   As described in [RFC-zzzz] "Identity Verification", the SHA1
   [FIPS-180-1] hash is calculated over the concatenation of:

      SHA1( key, data, datafill, key, sha1fill )

   where the key is the computed shared-secret.

   The leading key is not padded to any particular alignment.

   The datafill uses the same pad-with-length technique defined for
   sha1fill.  This padding and length is implicit, and does not appear
   in the datagram.  The datafill length includes only the leading key
   and data.

   The resulting Verification field is a 160-bit Variable Precision Num-
   ber (22 bytes including Size).

   For both identity verification and session-key calculation, the
   authentication symmetric secret-key is used as the calculation
   secret-key.






Karn & Simpson            expires in six months                 [Page 8]


DRAFT                    Schemes and Attributes                July 1997


5.2.  SHA1-KpMpKp Authentication

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Attribute   |    Length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Attribute        6

   Length           0

   May be selected as an AH or ESP Attribute-Choice, pursuant to
   [RFC-1852] et sequitur.  The selected Exchange-Scheme SHOULD provide  |
   at least 80-bits of cryptographic strength.

   As described in [RFC-zzzz] "Session-Key Computation", the most sig-   |
   nificant 384-bits (48 bytes) of the Key-Generation-Function itera-    |
   tions are used for the key.

   Profile:

      When negotiated with Photuris, the transform differs slightly from
      [RFC-1852].

      The form of the authenticated message is:

         SHA1( key, keyfill, datagram, datafill, key, sha1fill )

      where the key is the SPI session-key.

      The additional datafill protects against the attack described in
      [PO96].  This is also filled to the next 512-bit boundary, using
      the same pad-with-length technique defined for SHA1.  This padding
      and length is implicit, and does not appear in the datagram.  The
      datafill length includes only the leading key and data.
















Karn & Simpson            expires in six months                 [Page 9]


DRAFT                    Schemes and Attributes                July 1997


5.3.  DES-CBC Encryption

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Attribute   |    Length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Attribute        8

   Length           0

   May be selected as an ESP Attribute-Choice, pursuant to [RFC-1829] et
   sequitur.  The selected Exchange-Scheme SHOULD provide at least       |
   56-bits of cryptographic strength.

   As described in [RFC-zzzz] "Session-Key Computation", the most sig-
   nificant 64-bits (8 bytes) of the Key-Generation iteration are used
   for the key, and the remainder are discarded.  Although extremely
   rare, the 64 weak, semi-weak, and possibly weak keys [Schneier95,
   pages 280-282] MUST be discarded.  The Key-Generation-Function is     |
   iterated until a valid key is obtained.

   The least significant bit of each key byte is ignored (or set to par-
   ity when the implementation requires).

   Profile:

      When negotiated with Photuris, the transform differs slightly from
      [RFC-1829].

      The 32-bit Security Parameters Index (SPI) field is followed by a
      32-bit Sequence Number (SN).

      The 64-bit CBC IV is generated from the 32-bit Security Parameters
      Index (SPI) field followed by (concatenated with) the 32-bit
      Sequence Number (SN) field.  Then, the bit-wise complement of the
      32-bit Sequence Number (SN) value is XOR'd with the first 32-bits
      (SPI):

         (SPI ^ -SN) || SN

      The padding values begin with the value 1, and count up to the
      number of padding bytes (zero relative).  For example, if the
      plaintext length is 41, the padding values are 1, 2, 3, 4, 5, and
      the following PadLength is 5.

      After decryption, if the padding bytes are not the correct values
      for the PadLength, then the payload is discarded, and a



Karn & Simpson            expires in six months                [Page 10]


DRAFT                    Schemes and Attributes                July 1997


      "Decryption Failed" error is indicated, as described in [RFC-
      xxxx].


5.4.  DES Decryption

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Attribute   |    Length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Attribute        9

   Length           0

   May be selected as an ESP Attribute-Choice, pursuant to [RFC-1851] et
   sequitur.  The combination

      "DES-CBC Encryption",
      "DES Decryption",
      "DES-CBC Encryption",

   indicates "Triple DES" outer-CBC EDE encryption (and DED decryption)
   with three keys [KR96].  The selected Exchange-Scheme SHOULD provide  |
   at least 112-bits of cryptographic strength.

   As described in [RFC-zzzz] "Session-Key Computation", the Key-        |
   Generation-Function is iterated (at least) three times to generate
   the three independent keys, in the order used for encryption.  The    |
   most significant 64-bits (8 bytes) of each iteration are used for
   each successive key, and the remainder are discarded.  Each key is
   examined sequentially, in the order used for encryption.  A key that
   is identical to a previous key MUST be discarded.  Although extremely
   rare, the 64 weak, semi-weak, and possibly weak keys [Schneier95,
   pages 280-282] MUST be discarded.  The Key-Generation-Function is     |
   iterated until a valid key is obtained before generating the next
   key.

   In all three keys, the least significant bit of each key byte is
   ignored (or set to parity when the implementation requires).

   Profile:

      When negotiated with Photuris, the transform differs slightly from
      [RFC-1851].

      The 32-bit Security Parameters Index (SPI) field is followed by a
      32-bit Sequence Number (SN).



Karn & Simpson            expires in six months                [Page 11]


DRAFT                    Schemes and Attributes                July 1997


      The 64-bit CBC IV is generated from the 32-bit Security Parameters
      Index (SPI) field followed by (concatenated with) the 32-bit
      Sequence Number (SN) field.  Then, the bit-wise complement of the
      32-bit Sequence Number (SN) value is XOR'd with the first 32-bits
      (SPI):

         (SPI ^ -SN) || SN

      The padding values begin with the value 1, and count up to the
      number of padding bytes (zero relative).  For example, if the
      plaintext length is 41, the padding values are 1, 2, 3, 4, 5, and
      the following PadLength is 5.

      After decryption, if the padding bytes are not the correct values
      for the PadLength, then the payload is discarded, and a "Decryp-
      tion Failed" error is indicated, as described in [RFC-xxxx].


5.5.  XOR Whitening

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Attribute   |    Length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Attribute        11

   Length           0

   May be selected as an ESP Attribute-Choice, pursuant to [RFC-yyyy] et
   sequitur.  The combination

      "XOR",
      "DES-CBC Encryption",
      "XOR",

   indicates "DESX" encryption with three keys [KR96].  The selected     |
   Exchange-Scheme SHOULD provide at least 104-bits of cryptographic
   strength.

   As described in [RFC-zzzz] "Session-Key Computation", the Key-        |
   Generation-Function is iterated (at least) three times to generate
   the three independent keys, in the order used for encryption.  The    |
   most significant 64-bits (8 bytes) of each iteration are used for
   each successive key, and the remainder are discarded.

   Note that this attribute may appear multiple times in the same ESP    -
   attribute list, both before and after an encryption transform.  For



Karn & Simpson            expires in six months                [Page 12]


DRAFT                    Schemes and Attributes                July 1997


   example,

      "XOR",
      "DES-CBC Encryption",
      "XOR",
      "DES Decryption",
      "XOR",
      "DES-CBC Encryption",
      "XOR",

   would be one possible combination with Triple DES.


Security Considerations

   The "whitening" of the plaintext before DES encryption is intended to
   obscure the relation of the number of parties and SPIs active between
   two IP nodes.  The combination of a randomized secret mask with the
   CBC IV generates a different initial encrypted block for every SPI
   creation message.

   This obscurement is less effective when the SPI and SPILT are invari-
   ant or are not created for a particular exchange direction.  The num-
   ber of parties could be revealed by the number of exchanges with dif-
   ferences in the initial encrypted blocks.


Acknowledgements

   Phil Karn was principally responsible for the design of party privacy
   protection, and provided much of the design rationale text (now
   removed to a separate document).

   William Simpson designed the packet formats, and additional Exchange- |
   Schemes, editing and formatting.  All such mistakes are his responsi-
   bity.

   Use of encryption for privacy protection is also found in the Sta-
   tion-To-Station authentication protocol [DOW92].

   Bart Preneel and Paul C van Oorschot in [PO96] suggested adding
   padding between the data and trailing key when hashing for authenti-
   cation.

   Niels Provos developed the first implementation with multiple schemes +
   and multiple moduli per scheme (circa July 1997).





Karn & Simpson            expires in six months                [Page 13]


DRAFT                    Schemes and Attributes                July 1997


References

   [DOW92]  Whitfield Diffie, Paul C van Oorshot, and Michael J Wiener,
            "Authentication and Authenticated Key Exchanges", Designs,
            Codes and Cryptography, v 2 pp 107-125, Kluwer Academic Pub-
            lishers, 1992.

   [FIPS-180-1]
            "Secure Hash Standard", National Institute of Standards and
            Technology, U.S. Department Of Commerce, April 1995.

            Also known as: 59 Fed Reg 35317 (1994).

   [KR96]   Kaliski, B., and Robshaw, M., "Multiple Encryption: Weighing
            Security and Performance", Dr. Dobbs Journal, January 1996.

   [PO96]   Bart Preneel, and Paul C van Oorshot, "On the security of
            two MAC algorithms", Advances in Cryptology -- Eurocrypt
            '96, Lecture Notes in Computer Science 1070 (May 1996),
            Springer-Verlag, pages 19-32.

   [RFC-1829]
            Karn, P., Metzger, P., Simpson, W., "The ESP DES-CBC Trans-
            form", July 1995.

   [RFC-1850]
            Karn, P., Metzger, P., Simpson, W., "The ESP Triple DES
            Transform", September 1995.

   [RFC-1851]
            Metzger, P., Simpson, W., "IP Authentication using Keyed
            SHA", September 1995.

   [RFC-xxxx]
            Karn, P., and Simpson, W., "ICMP Security Failures Mes-
            sages", draft-simpson-icmp-ipsec-fail-02.txt, work in
            progress.

   [RFC-yyyy]
            Simpson, W., Baldwin, R., "The ESP DES-XEX3-CBC Transform",
            draft-ietf-ipsec-ciph-desx-00.txt, work in progress.

   [RFC-zzzz]
            Karn, P., and Simpson, W., "Photuris: Session Key Management
            Protocol", draft-simpson-photuris-13.txt, work in progress.






Karn & Simpson            expires in six months                [Page 14]


DRAFT                    Schemes and Attributes                July 1997


Contacts

   Comments about this document should be discussed on the
   photuris@majordomo.soscorp.com mailing list.

   Questions about this document can also be directed to:

      Phil Karn
      Qualcomm, Inc.
      6455 Lusk Blvd.
      San Diego, California  92121-2779

          karn@qualcomm.com
          karn@unix.ka9q.ampr.org (preferred)


      William Allen Simpson
      DayDreamer
      Computer Systems Consulting Services
      1384 Fontaine
      Madison Heights, Michigan  48071

          wsimpson@UMich.edu
          wsimpson@GreenDragon.com (preferred)
          bsimpson@MorningStar.com


























Karn & Simpson            expires in six months                [Page 15]