[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 02 03 04 05 06 07 08

Network Working Group                                             P Karn
Internet Draft                                                  Qualcomm
                                                             W A Simpson
                                                              DayDreamer
expires in six months                                      November 1995


              The Photuris Session Key Management Protocol
                  draft-ietf-ipsec-photuris-08.txt                        |


Status of this Memo

   This document is a submission to the IP Security Working Group of the
   Internet Engineering Task Force (IETF).  Comments should be submitted
   to the ipsec@ans.net mailing list.

   Distribution of this memo is unlimited.

   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 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
   reference 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)


Abstract

   Photuris is an experimental session-key management protocol intended
   for use with the IP Security Protocols (AH and ESP).






Karn & Simpson           expires in six months                  [Page i]


DRAFT                           Photuris                   November 1995


1.  Introduction

   The ultimate goal of Internet Security is to facilitate direct IP
   connectivity between sensitive hosts and users across the Internet.
   Users will rely on Internet Security to protect the confidentiality
   of the traffic they send across the Internet and depend on it to
   block unauthorized external access to their internal hosts and
   networks.

   Users must have confidence in every Internet Security component,
   including key management.  Without this confidence, users may erect
   barriers that impede legitimate use of the Internet, or forego the
   Internet entirely.

   Internet Security does not place any significance on easily forged IP
   Source addresses.  It relies instead on proof of possession of secret
   knowledge: that is, a cryptographic key.

   However, secure manual distribution and maintainance of these keys is
   often cumbersome and problematic.  User distribution often leads to
   long-lived keys, with concommitant opportunity for compromise of the
   keys.

   A fundamental role of this key management protocol is to verify the
   values exchanged, while ensuring that the resulting key is not known
   by another party.  It has been shown [DOW92] that key exchange must
   be coupled to authentication.  Each party requires assurance that an
   exchanged key is not shared with an imposter.

   Protecting sensitive data on the Internet against compromise --
   either by interception or by unauthorized access -- is necessary, but
   not sufficient.  The computing resources themselves must also be
   protected against malicious attack or sabotage.

   With these criteria in mind, Photuris [Firefly] is designed:

   1. for frequent exchange of short-lived individual session-keys, with
      a minimum of configuration and effort.

   2. to support the use of a variety of authentication methods, and
      facilitate the exchange of many identification types.

   3. to thwart certain types of denial of service attacks on host
      resources.







Karn & Simpson           expires in six months                  [Page 1]


DRAFT                           Photuris                   November 1995


   Design Notes:

      Photuris was based on currently available tools, by experienced
      network protocol designers with an interest in cryptography,
      rather than by cryptographers with an interest in network
      protocols.  This specification is intended to be readily
      implementable without requiring an extensive background in
      cryptography.

      Therefore, only minimal background cryptographic discussion and
      rationale is included in this document.  Although some review has
      been provided by the general cryptographic community, it is
      anticipated that design decisions and tradeoffs will be thoroughly
      analysed in subsequent dissertations and debated for many years to
      come.

      Implementors will find details of cryptographic hashing (such as
      MD5), encryption algorithms and modes (such as DES), digital
      signatures (such as DSS), and other algorithms in [Schneier94].


1.1.  Terminology


   exchange-value   The publically distributable value used to calculate
                    a shared-secret.  As used in this document, refers
                    to a Diffie-Hellman exchange, as opposed to a
                    public-key.

   private-key      A key that is kept secret, and is part of a
                    public/private key-pair.  As used in this document,
                    refers to RSA key pairs.

   public-key       A publically distributable value that is part of a
                    public/private key-pair.  As used in this document,
                    refers to RSA key pairs.

   secret-key       A key that is not publically distributable, and not
                    part of a public/private key-pair.  An example is a
                    user password.

   Security Association
                    A collection of parameters describing the security
                    relationship between two nodes.  These parameters
                    include the identities of the parties, the transform
                    (including algorithm and algorithm mode), the key(s)
                    (such as a session-key, secret-key, or appropriate
                    public/private key-pair), and possibly other



Karn & Simpson           expires in six months                  [Page 2]


DRAFT                           Photuris                   November 1995


                    information such as sensitivity labelling.  For
                    further details, see [RFC-1825].

   Security Parameters Index (SPI)
                    A number that indicates the Security Association.
                    The number is relative to the IP Destination, which
                    is the SPI Owner.

   session-key      A key that is independently derived from a shared-
                    secret by the parties, and used for keying one
                    direction of traffic.  This key is changed
                    frequently.

   shared-secret    As used in this document, the calculated result of
                    the Photuris exchange.

   transform        A cryptographic manipulation of a particular set of
                    data.  As used in this document, refers to certain
                    well-specified methods (which are defined
                    elsewhere).  For example, AH-MD5 [RFC-1828]
                    transforms an IP datagram into a one-way hash, and
                    ESP-DES-CBC [RFC-1829] transforms plaintext to
                    ciphertext and back again.



1.2.  Protocol Description

   The Photuris protocol consists of several simple phases:

   1. A "Cookie" Exchange guards against simple flooding attacks sent
      with bogus IP Sources.

      In addition, supported exchange-schemes are offered for             |
      calculating the shared-secret.

   2. A Value Exchange establishes a shared-secret between the parties.
      The Responder remains stateless until a shared-secret has been
      created.

      In addition, supported attributes are offered for use in the
      Security Associations.

   3. An Identification Exchange identifies the parties to each other,
      and verifies the integrity of values sent in phases 1 and 2.

      The shared-secret provides a basis to generate separate Security
      Association session-keys in each direction, which are in turn used



Karn & Simpson           expires in six months                  [Page 3]


DRAFT                           Photuris                   November 1995


      for conventional authentication or encryption.  Additional
      security attributes are also exchanged as needed.

      This exchange is also encrypted for privacy using another           |
      permutation of the shared-secret.  This protects the identities of
      the parties and hides the security parameter values.

   4. Additional messages may be exchanged to periodically change the
      session-keys, and to establish new or revised security parameters.

      These exchanges are also encrypted for privacy in the same fashion  |
      as above.







































Karn & Simpson           expires in six months                  [Page 4]


DRAFT                           Photuris                   November 1995



   Initiator                            Responder
   =========                            =========
   Cookie_Request                  ->
                                   <-   Cookie_Response
                                           offer schemes
   Exchange_Request                ->
      pick scheme
      offer value
      offer attributes
                                   <-   Exchange_Response
                                           offer value                    *
                                           offer attributes

             (generate shared-secret from exchanged values)

   Identification_Message          ->
      make SPI
      pick SPI attribute(s)                                               |
      identify self
      authenticate
      (make privacy key)                                                  |
      (encrypt)                                                           |
                                   <-   Identification_Message
                                           make SPI
                                           pick SPI attribute(s)          |
                                           identify self
                                           authenticate
                                           make SPI session-key(s)        |
                                           (make privacy key)             |
                                           (encrypt)                      |
      make SPI session-key(s)                                             |

                               (optional)

   Change_Message(s)               ->
      make SPI                                                            |
      pick SPI attribute(s)                                               |
      make SPI session-key(s)                                             |
      make integrity key                                                  |
      authenticate                                                        |
      (encrypt)                                                           |
                                   <-   Change_Message(s)
                                           make SPI                       |
                                           pick SPI attribute(s)          |
                                           make SPI session-key(s)        |
                                           make integrity key             |
                                           authenticate                   |



Karn & Simpson           expires in six months                  [Page 5]


DRAFT                           Photuris                   November 1995


                                           (encrypt)                      |

   Either party may initiate an exchange at any time.  For example, the
   Initiator need not be a "caller" in a telephony link.

   The Initiator is responsible for recovering from all message losses
   by retransmission.

   A Photuris exchange between two parties results in two SPI values
   (one in each direction).  Each SPI is used in creating a separate
   session-key in each direction.

   When both parties initiate Photuris exchanges concurrently, or one
   party initiates more than one Photuris exchange, the Initiator
   Cookies (and UDP Ports) keep the exchanges separate.  This results in
   more than one initial SPI for each Destination.

   To create multiple Security Associations with different parameters,
   the parties may also send Change_Messages.

   There is no requirement that all such outstanding SPIs be used.  The
   sender selects an appropriate SPI for each datagram transmission.


1.3.  Clogging Defense

   To grant access to authorized users regardless of location, it must
   be possible to cheaply detect and discard bogus datagrams.
   Otherwise, an attacker intent on sabotage might rapidly send
   datagrams to exhaust the host's CPU or memory resources.

   Using Internet Security authentication facilities, when a datagram
   does not pass an authentication check, it can be discarded without
   further processing.  This is easily done with manual (null) key
   management between trusted hosts at relatively little cost, given the
   speed of cryptographic hashing functions compared to public-key
   algorithms.

   Unfortunately, such a trusted host will have only a fixed number of
   keys available.  The keys will tend to have long lifetimes.  This
   carries significant security risks.

   Automatic key management is necessary to generate keys between
   parties without prior arrangement.  But, there is a potential
   Achilles heel in the key management protocol.

   Because of their use of CPU-intensive operations such as modular
   exponentiation, key management schemes based on public-key



Karn & Simpson           expires in six months                  [Page 6]


DRAFT                           Photuris                   November 1995


   cryptography are vulnerable to resource clogging attacks.  Although a
   complete defense against such attacks is impossible, Photuris
   features make them much more difficult.

   Cookie Exchange

      Photuris exchanges a "cookie" before initiating any public-key
      operations, thwarting the saboteur from using random IP Source
      addresses.  The simple validation of this cookie uses the same
      level of resources as other Internet Security authentication
      mechanisms.

      This forces the attacker to:

      1) use its own valid IP address, or

      2) gain access to a physical transmission link and appropriate
         those addresses, or

      3) subvert Internet routing for the same purpose.

      The first option allows the target to detect and filter out such
      attacks, and significantly increases the likelihood of identifying
      the attacker.  The latter two options are much more difficult than
      merely sending large numbers of datagrams with randomly chosen IP
      Source addresses from an arbitrary point on the Internet.

      The cookie does not protect against an observer that can copy a
      valid cookie, or an interceptor that can modify or substitute
      another cookie.  However, these attacks are mitigated somewhat
      with time-variant cookies.

   Minimize State

      There is a small amount of state associated with the Photuris
      exchange itself.  This includes the Cookies, Exchange-Values, and
      the computed shared-secret.

      During the initial Cookie Exchange, the Responder does not
      maintain any state for the exchange.  This prevents memory
      resource exhaustion from a simple flooding attack.

      Later exchange phases require saving of state to perform the key
      establishment calculations and identity verification.  An attacker
      that is willing to expose itself to a larger window of detection
      can waste substantial resources repeating all the steps of the
      Photuris process.




Karn & Simpson           expires in six months                  [Page 7]


DRAFT                           Photuris                   November 1995


   Precomputation

      Once exchange state has been established between nodes, repetitive
      exchanges can use many of the same previously computed values.
      This prevents an attacker with more CPU power from easily
      exhausting the target.

   Expiration

      All retained exchange state is subject to periodic expiration
      (typically 10 minutes).  These Exchange LifeTimes are               |
      implementation dependent and are not disclosed in any Photuris      |
      message.

      When an Exchange-Value expires (or is replaced by a newer value),
      all related exchange state is purged.  The periodic expiration and
      purge of exchange state reduces the risk of compromise of keys and
      secrets, and is an important consideration in attaining perfect
      forward secrecy.

      If an attacker has succeeded in overwhelming a target, the target
      will eventually recover as the expired state is purged.


1.4.  Traffic Anonymity

   Although each datagram carries a cleartext IP Destination, the
   ultimate destination can be hidden by "laundering" it through an
   encrypted tunnel.  The IP Source could be hidden in the same manner.
   If the Source has been dynamically allocated, it provides no useful
   information to an eavesdropper.

   This leaves the identifying information that the parties send during
   the Identification Exchange.  One would often like to deny this
   information to an eavesdropper, especially when this would reveal the
   location of a user.

   The identification can be easily protected by encrypting the
   Identification Exchange with the shared-secret just established.
   This keeps a passive eavesdropper from learning the identities of the
   parties, either directly from the certificates or by checking
   signatures against a known database of public keys.

   The scheme is not foolproof.  By posing as the Responder, an active
   attacker could trick the Initiator into revealing its identity.
   However, this active attack is considerably more difficult than
   passive vacuum-cleaner monitoring.  Unless the attacker can steal the
   private/secret key belonging to the Responder, the Initiator will



Karn & Simpson           expires in six months                  [Page 8]


DRAFT                           Photuris                   November 1995


   discover the deception when verifying the Identification Exchange.


1.5.  Security Parameters

   Photuris key management is used to determine a number of parameters
   for each Security Association between the communicating parties.
   This includes the particular authentication and/or encryption
   transforms, and the key(s) used to authenticate, encrypt or decrypt
   the payload.

   The key management implementation usually maintains a table
   containing the several parameters for each concurrent Security
   Association.  The implementation needs to access that security
   parameter table to determine how to process each datagram.

   The Security Parameters Index (SPI) is assigned by the entity
   controlling the IP Destination: the SPI Owner (the receiver).  The
   parties use the combination of SPI and IP Destination to distinguish
   the correct association.

   Each SPI has an associated LifeTime, specified by the SPI owner
   (receiver).  This SPI LifeTime is usually related to the speed of the  |
   link (typically 30 to 300 seconds).  The SPI can also be deleted by
   the SPI Owner using the Change_Message.  Once the SPI has expired or
   been deleted, the parties cease using the SPI, and purge the
   associated state.

   The SPI LifeTime may be shorter or longer than the Exchange LifeTime.  |
   These LifeTimes are not required to be related to each other.

   When an Exchange-Value expires (or is replaced by a newer value), the  |
   derived SPIs are not affected.  This is important to allow traffic to
   continue without interruption during new Photuris exchanges.

   Implementation Notes:

      The method used for SPI assignment is implementation dependent.
      However, selection of a cryptographically random value can help
      prevent attacks that depend on a predicatable sequence of values.

      To prevent resurrection of old SPIs, implementations SHOULD
      remember those deleted or expired SPIs, but mark them as unusable
      until the shared-secret used to create them also expires.







Karn & Simpson           expires in six months                  [Page 9]


DRAFT                           Photuris                   November 1995


1.6.  User Support

   The Photuris exchange results in two kinds of state, each with
   separate LifeTimes.

   1) The small amount of state associated with the Photuris exchange
      itself.  This state may be viewed as between Internet nodes.

   2) The multiple Security Associations that are established.  This
      state may be viewed as from nodes to users.

   Every node requires its own Identification.  When the Photuris
   exchange is node to node, such as single user personal computers or
   unattended firewalls used in virtual private networks, the nodes
   themselves may be viewed as the users.

   Internet Security protects against threats that come from the
   external network, not from mutually hostile users of the nodes
   themselves.                                                            |

   A) A secure multi-user operating system MUST be able to protect its
      resources from hostile users, and protect one hostile user from
      damaging the resources controlled by another hostile user.          |

   B) A secure multi-user operating system MUST incorporate strong        |
      support for user-oriented discretionary access controls.            |

   C) If the operating system has any security vulnerability, such that   |
      internal information may be revealed or the information of one
      user may be inadvertantly disclosed to another user, then there is  |
      no basis for separate user-oriented keying.                         |

   When required for secure multi-user environments, the Photuris
   Identification can be used to provide separate limited authentication
   from each user of one node when communicating with another common
   node.  To provide user-oriented keying, the nodes can initiate
   multiple concurrent Photuris exchanges.  These may provide separate
   user Identification from the Initiator to the Responder in each
   direction.

   Each secure multi-user operating system MUST be capable of separately
   maintaining multiple Identification Exchange SPI values for each
   Value Exchange calculated shared-secret.  It is the responsibility of
   the Source to internally segregate the shared-secret and different
   session-keys provided per Destination, and select an appropriate SPI
   for each datagram transmission.





Karn & Simpson           expires in six months                 [Page 10]


DRAFT                           Photuris                   November 1995


   Implementation Notes:

      Once exchange state has been established between nodes, repetitive
      exchanges can use many of the same previously computed values.

      Successful use of user-oriented keying requires a significant
      level of operating system support.  Use of multi-user segregated    *
      exchanges likely requires added functionality in the transport API
      of the implementation operating system.  Such a mechanism is
      outside the scope of this document.

      It has been suggested that the Photuris exchange could also be
      established between particular application or transport processes
      associated with a user of a node.  Such a mechanism is
      emphatically outside the scope of this document.


1.7.  Multicast Support

   Key management is more difficult in a multicast environment.

   Senders to a multicast group may share common a Security Parameters
   Index, if all communications are using the same security
   configuration parameters.  In this case, the receiver only knows that
   the message came from a node knowing the SPI for the group, and
   cannot authenticate which member of the group sent the datagram.

   Multicast groups may also use a separate SPI value for each Source.
   If each sender is keyed separately and asymmetric algorithms are
   used, data origin authentication is also provided.

      A given Destination is not necessarily in control of the selection
      process.  In the case of multicast groups, a single node or
      cooperating subset of the multicast group may work on behalf of
      the entire group to set up a Security Association.

   It is anticipated that Photuris would be used first to establish a
   distribution SPI and session-key, and that another orthogonal key
   distribution mechanism will use that SPI to send the group keys.
   This is a matter for future research.  Such a mechanism is outside
   the scope of this document.










Karn & Simpson           expires in six months                 [Page 11]


DRAFT                           Photuris                   November 1995


2.  Protocol Details

   The Initiator begins a Photuris exchange when it has:

   1) a datagram that it wishes to send with privacy, and has no current
      Photuris exchange state with the IP Destination.

   2) received the ICMP message Destination Unreachable: Communication
      Administratively Prohibited (Type 3, Code 13).

   3) received the ICMP message Security Failures: Bad SPI (Type 40,      |
      Code 0), that indicates an expired/invalid SPI.

   4) received the ICMP message Security Failures: Need Authentication
      (Type 40, Code 4), that indicates a requirement for
      authentication.

   5) received the ICMP message Security Failures: Need Authorization
      (Type 40, Code 5), that indicates a requirement for a different
      level of authorization.

   6) received an Error_Message indicating that a new Cookie_Request
      should be sent.

   Other needs to initiate a Photuris exchange are likely to be a matter
   for considerable future debate.


2.1.  UDP

   All Photuris messages use the User Datagram Protocol header [RFC-
   768].  The Initiator sends to UDP Destination Port 468.

   When replying to the Initiator, the Responder swaps the IP Source and
   Destination, and the UDP Source and Destination Ports.

   The UDP checksum MUST be correctly calculated when sent.  When a
   message is received with an incorrect UDP checksum, it is silently
   discarded.

   Implementation Note:

      It is expected that installation of Photuris will ensure that UDP
      checksums are enabled for the computer operating system and later
      disabling by operators is prevented.






Karn & Simpson           expires in six months                 [Page 12]


DRAFT                           Photuris                   November 1995


2.2.  Header Format

   All of the messages have a format similar to the following, as
   transmitted left to right in network order (most significant to least
   significant):

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                       Initiator-Cookie                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                       Responder-Cookie                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |
   +-+-+-+-+-+-+-+-+


   Initiator-Cookie  16 octets.

   Responder-Cookie  16 octets.

   Type             one octet.  Each message type has a unique value.

   Further details and differences are elaborated in the individual
   messages.

   Design Note:

      The fixed size of the cookies was chosen for convenience, based on
      the output of commonly available cryptographic hashing functions.
      It is anticipated that this size is likely to be more than
      sufficient to protect against very high bit-rate flooding attacks.


2.3.  Exchange Schemes

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Scheme             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Scheme           two octets.  A unique value indicating the            |
                    exchange-scheme.                                      |

   Selection among several different exchange-schemes is needed to
   enable experimental and proprietary extensions without affecting the



Karn & Simpson           expires in six months                 [Page 13]


DRAFT                           Photuris                   November 1995


   basic protocol.  The target of the exchange (Responder) specifies a
   list of the schemes supported, and the Initiator chooses one that it
   also supports.

   The scheme list includes alternative algorithms and distinguishing
   parameters.  These are mixed in the same list for simplicity.  The
   implementation can easily distinguish between the separate uses of     |
   each supported scheme.  These uses are indicated in the "Exchange      |
   Scheme List" Appendix.

   Design Notes:

      Although exchange-schemes offer great flexibility, only a few       |
      well-chosen algorithms and parameters are specified.  This
      provides opportunity for intensive review by the cryptographic
      community, reduces implementation complexity, and improves
      potential for interoperability.

      Only one exchange-scheme (#2) is required to be supported, and      |
      MUST be present in every Offered-Schemes list.


2.4.  Attributes

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |  Value(s) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type             one octet.  A unique value indicating the kind of     |
                    attribute.                                            |

                    When the Type is zero (padding), no Length field is   |
                    present.                                              |

   Length           one octet.  The size of the Value(s) field in         |
                    octets.                                               |

                    When the Length is zero, no Value(s) field is         |
                    present.                                              |

   Value(s)         Zero or more octets.  Further details are elaborated  |
                    in the "Attribute List" Appendix.                     |

   Selection among several different security parameter attributes is
   needed to enable future implementation changes without affecting the
   basic protocol.  Each party (the sender) offers a list of the
   attributes supported and its peer (the receiver) selects from that



Karn & Simpson           expires in six months                 [Page 14]


DRAFT                           Photuris                   November 1995


   list when making its incoming Security Associations.

   The attribute list includes authentication, compression, encryption,
   identification, and other operational types available for exchange     |
   between the parties.  These are mixed in the same list for
   simplicity.  The implementation can easily distinguish between the
   separate uses of each supported attribute.  These uses are indicated   |
   in the "Attribute List" Appendix.

   Encryption decisions are in the SPI User (sender) direction.  Only
   the sender can determine whether each datagram needs privacy
   protection.  It uses an encryption SPI created by the receiver, in
   addition to an authentication SPI (as needed).  When the sender needs
   privacy protection for a datagram and Photuris exchange state has
   been established, but the potential receiver has no current
   encryption SPI, an Error_Message listing encryption attributes is
   sent and the original datagram is discarded.

   Authentication decisions are in the SPI Owner (receiver) direction.
   Only the receiver can determine that arriving traffic is authentic.
   Its need for authentication is indicated by choosing authentication
   attributes, and/or authenticated encryption attributes, when creating
   each SPI.  It enforces the authentication through the simple
   expedient of dropping all datagrams with missing or invalid
   authentication, and sending an appropriate ICMP Security Failures      |
   message.

   Design Notes:                                                          |

      Although attributes offer great flexibility, only a few well-
      chosen algorithms are specified.  This provides opportunity for
      intensive review by the cryptographic community, reduces
      implementation complexity, and improves potential for
      interoperability.

      Support for some attributes is required (MD5 and DES-CBC), and
      SHOULD be present in every Offered-Attributes list.  Where
      encryption is prohibited in a particular environment, the DES-CBC
      attributes MAY be omitted.

      Since SPI creation is in the receiver direction, but privacy (and
      potentially other) decisions are in the sending direction, a
      message is used from the sender to the receiver to stimulate the
      SPI creation.

      Typically, an encryption method is chosen for the primary
      attribute of the initial SPI in each direction.  If integrity is
      needed, it is recommended that an authentication method be added



Karn & Simpson           expires in six months                 [Page 15]


DRAFT                           Photuris                   November 1995


      as an additional separate SPI.

      When both authentication and encryption attributes are used for     |
      the same SPI, care must be exercised that there is no interaction
      between the algorithms that might reveal some portion of the
      session-key.  There is no known interaction between MD5 and DES-
      CBC.

      When choices are made from the set of Offered-Attributes, it is
      not required that any Security Association include every kind of
      offered attribute in any single SPI, or that a separate SPI be
      created for every offered attribute.  These combinations are
      implementation dependent.

      The authentication, compression, encryption and identification
      mechanisms, as well as the encapsulation mode (if any), need not
      be the same in both directions.


2.5.  Variable Precision Numbers

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Size              |             Value ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Size             two, four, or eight octets.  The number of            |
                    significant bits used in the Value field.  Always
                    transmitted most significant octet first.

                    When the Size is zero, no Value field is present;     |
                    there are no significant bits.  This means "missing"
                    or "null".  It should not be confused with the value
                    zero, which includes an indication of the number of
                    significant bits.

                    When the most significant octet is in the range 0
                    through 254 (0xfe), the field is two octets.  Both
                    octets are used to indicate the size of the Value
                    field, which ranges from 1 to 65,279 significant
                    bits (in 1 to 8,160 octets).

                    When the most significant octet is 255 (0xff), the
                    field is four octets.  The remaining three octets
                    are added to 65,280 to indicate the size of the
                    Value field, which is limited to 16,776,959
                    significant bits (in 2,097,120 octets).




Karn & Simpson           expires in six months                 [Page 16]


DRAFT                           Photuris                   November 1995


                    When the most significant two octets are 65,535
                    (0xffff), the field is eight octets.  The remaining
                    six octets are added to 16,776,960 to indicate the
                    size of the Value field.  This is vastly too long
                    for these UDP messages, but is included for
                    completeness.

   Value            Zero or more octets.  Always transmitted most         |
                    significant octet first.                              |

                    The bits used are right justified within octet
                    boundaries; that is, any unused bits are in the most
                    significant octet.  Unused bits are zero filled.      *

   Shortened forms SHOULD NOT be used when the Value includes a number
   of leading zero significant bits.  The Size SHOULD indicate the
   correct number of significant bits.

   Design Notes:

      Some of the message fields require a value which may vary in the
      number of bits.  These bits may not make up an integral number of
      octets.

      The numbers are assumed to be unsigned.

      The emphasis on significant bits was based on concerns that
      cryptographic lengths and strengths be readily determined.  This
      is in contrast to the usual concern that each number have only one
      unique (shortest) representation.


3.  Cookie Exchange

   The Initiator initializes local state, and sends a Cookie_Request to
   the Responder.

   The Initiator also starts a retransmission timer.  If no
   Cookie_Response is obtained within the time limit, the Cookie_Request
   is retransmitted.  The Initiator-Cookie value in each such
   retransmission to the same IP Destination and UDP Port SHOULD be the
   same.

   On receipt of a Cookie_Request, the Responder determines if there are
   sufficient resources to begin another Photuris exchange.  When too
   many SPI values are already in use for this particular peer, or some
   other resource limit is reached, an Error_Message is sent.




Karn & Simpson           expires in six months                 [Page 17]


DRAFT                           Photuris                   November 1995


   Otherwise, the Responder generates a cookie, and returns it in a
   Cookie_Response.  The Responder-Cookie value in each successive
   response MAY be different.

      Note that the Responder creates no additional state at this time.

   On receipt of a Cookie_Response, the Initiator validates the
   Initiator-Cookie.  Invalid messages are silently discarded.











































Karn & Simpson           expires in six months                 [Page 18]


DRAFT                           Photuris                   November 1995


3.1.  Cookie_Request

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                       Initiator-Cookie                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                       Responder-Cookie                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |
   +-+-+-+-+-+-+-+-+


   Initiator-Cookie  16 octets.  A randomized value that identifies the
                    exchange.  The Initiator will use this value to
                    reject invalid responses.

   Responder-Cookie  16 octets.  Unused, MUST be set to zero when
                    transmitted, and MUST be ignored when received.

   Type             0



3.2.  Cookie_Response

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                       Initiator-Cookie                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                       Responder-Cookie                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Reserved     |  Offered-Schemes ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Initiator-Cookie  16 octets.  Copied from the Cookie_Request.

   Responder-Cookie  16 octets.  A randomized value that identifies the
                    exchange.  The Responder will use this value to
                    reject invalid requests.

   Type             1



Karn & Simpson           expires in six months                 [Page 19]


DRAFT                           Photuris                   November 1995


   Reserved         one octet.  Unused, MUST be set to zero when
                    transmitted, and MUST be ignored when received.

   Offered-Schemes  Two or more octets.  A list of one or more            |
                    exchange-schemes supported by the Responder, in
                    increasing order of preference.

                    Each value is two octets (see "Exchange Scheme List"
                    Appendix).  The end of the list is indicated by the
                    UDP Length.



3.3.  Cookie Generation

   The exact technique by which a Photuris party generates a cookie is
   implementation dependent.  The method chosen must satisfy some basic
   requirements:

   1. The cookie must depend on the specific parties.  This prevents an
      attacker from obtaining a cookie using a real IP address and UDP
      port, and then using it to swamp the victim with requests from
      randomly chosen IP addresses or ports.

   2. It must not be possible for anyone other than the issuing entity
      to generate cookies that will be accepted by that entity.  This
      implies that the issuing entity must use local secret information
      in the generation and subsequent verification of a cookie.  It
      must not be possible to deduce this secret information from any
      particular cookie.

   3. The cookie generation and verification methods must be fast to
      thwart attacks intended to sabotage CPU resources.

   A recommended technique is to calculate a cryptographic hashing
   function (such as MD5) over the IP Source and Destination addresses,
   the UDP Source and Destination ports, and a locally generated secret
   random value.  An incoming cookie can be verified at any time by
   regenerating it locally from values contained in the incoming IP
   datagram and the local secret random value.

   Initiator

      The Initiator secret random value that affects the cookie SHOULD
      change for each new Photuris exchange, and is thereafter
      internally cached on a per Responder basis.  This provides
      improved synchronization and protection against replay attacks.




Karn & Simpson           expires in six months                 [Page 20]


DRAFT                           Photuris                   November 1995


      An alternative is to cache the cookie instead of the secret value.
      Incoming cookies can be compared directly without the
      computational cost of regeneration.

   Responder

      The Responder secret random value MAY remain the same for many
      different Initiators.  Instead, this secret SHOULD be changed
      whenever the Responder Exchange-Value is changed.

      During the initial Cookie Exchange, the Responder regenerates its
      cookie for validation.  The cookie is not cached per Initiator to
      avoid saving state during the initial Cookie Exchange.  Once the
      Exchange_Request is received, both Initiator and Responder cookies
      are cached to identify the exchange.


4.  Value Exchange

   On receipt of a valid Cookie_Response, the Initiator chooses an        |
   appropriate exchange-scheme and Exchange-Value, and sends an
   Exchange_Request.  Later Cookie_Responses from the same Responder are
   silently discarded, until a new Cookie_Request is sent.

   The Initiator also starts a retransmission timer.  If no valid
   Exchange_Response is obtained within the time limit, the same
   Exchange_Request is retransmitted.

   On receipt of an Exchange_Request, the Responder validates the
   Responder-Cookie and the Scheme-Choice.  Whenever an invalid/expired
   cookie or scheme is detected by the Responder, an Error_Message is
   sent, and the message is discarded.

   When a valid Exchange_Request has been received, the Responder         |
   chooses an appropriate Exchange-Value for the indicated scheme, and
   sends an Exchange_Response.

   The Responder keeps a copy of the incoming Exchange_Request values,
   and its Exchange_Response.  If a duplicate Exchange_Request is
   received, it merely resends its previous Exchange_Response, and takes
   no further action.

   Implementation Notes:

      At this time, the Responder begins calculation of the shared-
      secret.  This may take a substantial amount of time.  The
      implementor should ensure that retransmission is not blocked by
      this calculation.  This is not usually a problem, as



Karn & Simpson           expires in six months                 [Page 21]


DRAFT                           Photuris                   November 1995


      retransmission timeouts typically exceed calculation time.


















































Karn & Simpson           expires in six months                 [Page 22]


DRAFT                           Photuris                   November 1995


4.1.  Exchange_Request

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                       Initiator-Cookie                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                       Responder-Cookie                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Reserved     |       Scheme-Choice         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                   Initiator-Exchange-Value                    ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Initiator-Offered-Attributes ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-


   Initiator-Cookie  16 octets.  Copied from the Cookie_Response.

   Responder-Cookie  16 octets.  Copied from the Cookie_Response.

   Type             2

   Reserved         one octet.  For future use; MUST be set to zero when
                    transmitted, and MUST be ignored when received.

   Scheme-Choice    two octets.  A value selected by the Initiator from
                    the list of Offered-Schemes in the Cookie_Response.

   Initiator-Exchange-Value
                    variable precision number.  Provided by the
                    Initiator for calculating a shared-secret between
                    the parties.  The format is indicated by the
                    Scheme-Choice.

                    The field may be any integral number of octets in
                    length, as indicated by its Size field.  It does not
                    require any particular alignment.  The 32-bit
                    alignment shown is for convenience in the
                    illustration.

   Initiator-Offered-Attributes
                    Six or more octets.  A list of three (mandatory) or   |
                    more Security Parameter attributes supported by the



Karn & Simpson           expires in six months                 [Page 23]


DRAFT                           Photuris                   November 1995


                    Initiator, in increasing order of preference.

                    This list includes all attributes supported by the
                    Initiator.  Each Responder "-Choice" selects from
                    this list.

                    The formats are specified in the "Attribute List"
                    Appendix, where mandatory attributes are also
                    specified.  The end of the list is indicated by the
                    UDP Length.

   Design Notes:

      Having the scheme chosen by the Initiator allows the greatest
      protocol flexibility, and follows the requirement that no state be
      kept by the Responder until the shared-secret is calculated.
      Unfortunately, this allows the weakest scheme to be chosen by an
      attacker.

      This is no worse than the alternative: to have the Responder
      choose from weak schemes offered by the Initiator.


4.2.  Exchange_Response

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                       Initiator-Cookie                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                       Responder-Cookie                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |                    Reserved                   |      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                   Responder-Exchange-Value                    ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Responder-Offered-Attributes ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-


   Initiator-Cookie  16 octets.  Copied from the Exchange_Request.

   Responder-Cookie  16 octets.  Copied from the Exchange_Request.




Karn & Simpson           expires in six months                 [Page 24]


DRAFT                           Photuris                   November 1995


   Type             3

   Reserved         Three octets.  For future use; MUST be set to zero    |
                    when transmitted, and MUST be ignored when received.  *

   Responder-Exchange-Value
                    variable precision number.  Provided by the
                    Responder for calculating a shared-secret between
                    the parties.  The format is indicated by the
                    Scheme-Choice.

                    The field may be any integral number of octets in
                    length, as indicated by its Size field.  It does not
                    require any particular alignment.  The 32-bit
                    alignment shown is for convenience in the
                    illustration.

   Responder-Offered-Attributes
                    Six or more octets.  A list of three (mandatory) or   |
                    more Security Parameter attributes supported by the
                    Responder, in increasing order of preference.

                    This list includes all attributes supported by the
                    Responder.  Each Initiator "-Choice" selects from
                    this list.

                    The formats are specified in the "Attribute List"
                    Appendix, where mandatory attributes are also
                    specified.  The end of the list is indicated by the
                    UDP Length.



5.  Identification Exchange                                               *

   On receipt of a valid Exchange_Response, the Initiator begins its
   parallel computation of the shared-secret.  When the Initiator
   completes computation, it sends an Identification_Message to the
   Responder.

   The Initiator also starts a retransmission timer.  If no
   Identification_Message response is obtained within the time limit,
   the same Identification_Message request is retransmitted.

   When the Responder completes its parallel computation of the shared-
   secret, and upon receipt of a valid Identification_Message, it sends
   an Identification_Message to the Initiator.




Karn & Simpson           expires in six months                 [Page 25]


DRAFT                           Photuris                   November 1995


   The Responder keeps a copy of the incoming Identification_Message
   values, and its Identification_Message.  If a duplicate
   Identification_Message is received, it merely resends its previous
   Identification_Message, and takes no further action.

   Whenever an invalid/expired cookie or attribute is detected by the
   receiver, an Error_Message is sent, and the message is discarded.

   Implementation Notes:

      Calculation of the shared-secret by the Initiator and Responder is
      executed in parallel to minimize delay.

      The exchange-scheme, Exchange-Values, and resulting shared-secret   |
      MAY be cached in short-term storage for the Exchange LifeTime.
      When repetitive Photuris exchanges occur between the same parties,  |
      and the Exchange-Values are discovered to be unchanged, the cached
      shared-secret can be used to rapidly generate new session-keys.     |

      The paranoid operator will have a fairly short Exchange LifeTime,   |
      but it SHOULD NOT be zero, to protect against resource clogging     |
      (described earlier).





























Karn & Simpson           expires in six months                 [Page 26]


DRAFT                           Photuris                   November 1995


5.1.  Identification_Message

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                       Initiator-Cookie                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                       Responder-Cookie                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |                    LifeTime                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Security-Parameter-Index                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Identity-Choice        |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   ~                        Identification                         ~      |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                         Verification                          ~      |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Attribute-Choices ...                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                             ... Padding           |  Pad Length   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Initiator-Cookie  16 octets.  Copied from the Exchange_Request.

   Responder-Cookie  16 octets.  Copied from the Exchange_Request.

   Type             4

   LifeTime         three octets.  The number of seconds remaining
                    before the indicated SPI expires.  Must be greater
                    than zero.

   Security-Parameter-Index
                    four octets.  The SPI to be used for incoming
                    communications.

   Identity-Choice  Two or more octets.  An identity attribute is         |
                    selected from the list of Offered-Attributes sent by
                    the peer, and is used to calculate the Verification.



Karn & Simpson           expires in six months                 [Page 27]


DRAFT                           Photuris                   November 1995


                    The field may be any integral number of octets in     *
                    length, as indicated by its Length field.  It does
                    not require any particular alignment.  The 16-bit
                    alignment shown is for convenience in the
                    illustration.                                         |

   Identification   Zero or more octets.  The content is specified by     |
                    the Identity-Choice attribute.

                    The field may be any integral number of octets in
                    length.  It does not require any particular
                    alignment.  The 32-bit alignment shown is for
                    convenience in the illustration.

   Verification     variable precision number.  The content is specified
                    by the Identity-Choice attribute.

                    The field may be any integral number of octets in
                    length, as indicated by its Size field.  It does not
                    require any particular alignment.  The 32-bit
                    alignment shown is for convenience in the
                    illustration.                                         *

   Attribute-Choices
                    Two or more octets.  A list of one or more            |
                    attributes for this SPI, selected from the list of
                    Attributes supported by the peer.

                    The formats are specified in the "Attribute List"
                    Appendix.  The end of the list is indicated by the
                    UDP Length minus the Pad Length and Padding.

   Padding          Zero or more octets.  Prior to encryption, it is      |
                    filled with unspecified implementation dependent
                    (preferably random) values, to align the Pad Length
                    field at a boundary appropriate to the Privacy-       |
                    Method.

                    After decryption, it MUST be ignored.

   Pad Length       one octet.  The size of the Padding field in octets.
                    It does not include the Pad Length fields.  The
                    value typically ranges from 0 to 7, but may be up to
                    255 to permit hiding of the actual data length.

                    This field is always present, even though no          |
                    Privacy-Method is specified or no Padding is
                    required.



Karn & Simpson           expires in six months                 [Page 28]


DRAFT                           Photuris                   November 1995


                    This field is opaque.  That is, the value is set
                    prior to encryption, and is examined only after
                    decryption.



5.2.  Shared-Secret                                                       |

   The shared-secret is used in a number of calculations.  Regardless of  |
   the internal representation of the shared-secret, when used in         |
   calculations it is in the same form as the Value part of a Variable    |
   Precision Number:                                                      |

   -  most significant octet first.                                       |

   -  bits used are right justified within octet boundaries.              |

   -  any unused bits are in the most significant octet.                  |

   -  unused bits are zero filled.                                        |



5.3.  Privacy                                                             *

   This message is encrypted using the Privacy-Method indicated by the    |
   current Scheme-Choice.  It is separate from any encryption specified   |
   for Security Associations (see "Exchange Scheme List" Appendix).

   The fields protected, the length of the Padding (if any), and other    |
   details are described for each Privacy-Method.  See the "Attribute
   List" Appendix for details.

   The Privacy-Method specified key generation cryptographic hash is      |
   used to create a special privacy session-key.  This hash is            |
   calculated over the following concatenated values:

    + the computed shared-secret,
    + the Initiator Cookie,                                               |
    + the Responder Cookie,                                               |
    + the SPI Owner (receiver) Exchange-Value,
    + the SPI User (sender) Exchange-Value,
    + the computed shared-secret again.                                   *

   Since the order of the Exchange-Value fields is different in each      |
   direction, the resulting privacy session-key will usually be
   different in each direction.                                           |




Karn & Simpson           expires in six months                 [Page 29]


DRAFT                           Photuris                   November 1995


   Implementation Notes:                                                  |

      This Privacy-Method is used to protect both                         |
      Identification_Messages and Change_Messages.                        |

      The chosen algorithm need not provide integrity, as sufficient      |
      integrity is provided by the Identity Verification.


5.4.  Identity Verification                                               |

   The two parties now verify the identities received.  The indicated     |
   Identity-Choice method is calculated over the following concatenated   |
   values:

    + the computed shared-secret,
    + the Offered-Schemes,
    + the SPI Owner (receiver) Exchange-Value,
    + the SPI User (sender) Exchange-Value,
    + the SPI Owner (receiver) Offered-Attributes,
    + the SPI User (sender) Offered-Attributes,
    + the Type, LifeTime and SPI,
    + the Identification (see notes below),
    + the Attribute-Choices following the Verification field,             |
    + the authentication secret-key (if any),
    + the computed shared-secret again.

   Note that the order of the Exchange-Value and Offered-Attribute        |
   fields is different in each direction.  The SPI and Identification     |
   fields are also likely to be different in each direction.

   If identity verification fails, the users are notified, an
   Error_Message is sent, and the Security Association is destroyed.

   On success, normal operation begins with the authentication and/or
   encryption of user datagrams.

   Implementation Notes:

      Any authenticated and/or encrypted user datagrams received before
      the completion of identity verification can be placed on a queue
      pending completion of this step.  If verification succeeds, the
      queue is processed as though the datagrams had arrived subsequent
      to the verification.  If verification fails, the queue is
      discarded.

      The exact details of the Identification that are included in the
      verification calculation are dependent on the Identity-Choice.



Karn & Simpson           expires in six months                 [Page 30]


DRAFT                           Photuris                   November 1995


      See the "Attribute List" Appendix for details.

      Each party may wish to keep their own trusted databases, such as
      the Pretty Good Privacy (PGP) web of trust, and accept only those
      identities found there.  Failure to find the Identification in
      either an internal or external database results in the same
      Error_Message as failure of the verification computation.

      As previously noted, the purpose of verification is to protect
      against an insertion or modification attack.  To provide anonymity
      for mobile nodes, the identity is not coupled with or restricted
      to any particular IP address.

      Each party implements local policy that determines what access, if
      any, is granted to the holder of a particular identity.  For
      example, the party might allow anonymous FTP, but prohibit Telnet.
      Such policy considerations are outside the scope of this document.


5.5.  Session-Key Computation

   Each Security Association SPI has one or more session-keys.  These     |
   keys are generated based on the attributes of the Security             |
   Association.  See the "Attribute List" Appendix for details.           |

   The Attribute-Choice specified key generation cryptographic hash is    |
   used to create a SPI session-key for that particular attribute.  This  |
   hash is calculated over the following concatenated values:

    + the computed shared-secret,
    + the Initiator Cookie,                                               |
    + the Responder Cookie,                                               |
    + the SPI Owner (receiver) Identity Verification,
    + the SPI User (sender) Identity Verification,
    + the SPI,                                                            *
    + the computed shared-secret again.

   Since the order of the Identity Verification fields is different in    |
   each direction, and the SPI is likely to be different in each          |
   direction, the resulting session-key will usually be different in
   each direction.

   Implementation Notes:                                                  |

      Inclusion of the Cookie and Verification fields together with the   |
      SPI allows reuse of the same Exchange-Values and resulting          |
      shared-secret among several parties and multiple users of the same
      node without generating the same session-keys.                      |



Karn & Simpson           expires in six months                 [Page 31]


DRAFT                           Photuris                   November 1995


      When both authentication and encryption attributes are used for     |
      the same SPI, and such attributes use different key generation      |
      hashing algorithms, there may be multiple session-keys associated   |
      with the same SPI.















































Karn & Simpson           expires in six months                 [Page 32]


DRAFT                           Photuris                   November 1995


6.  Other Message Types

   The need for these messages has been indicated in previous processing
   descriptions.  Details of use follow each message.


6.1.  Change_Message

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                       Initiator-Cookie                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                       Responder-Cookie                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |                    LifeTime                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Security-Parameter-Index                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |      *
   ~                         Verification                          ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Attribute-Choices ...                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                             ... Padding           |  Pad Length   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Initiator-Cookie  16 octets.  Copied from the Exchange_Request.

   Responder-Cookie  16 octets.  Copied from the Exchange_Request.

   Type             5

   LifeTime         three octets.  The number of seconds remaining
                    before the indicated SPI expires.  The value zero
                    indicates deletion of the indicated SPI.

   Security-Parameter-Index
                    four octets.  The SPI to be used for incoming
                    communications.  This may be a new SPI value (for
                    creation), or an existing SPI value (for deletion).
                    The value zero indicates all old SPIs for this IP
                    Destination (typically used for deletion).            *




Karn & Simpson           expires in six months                 [Page 33]


DRAFT                           Photuris                   November 1995


   Verification     variable precision number.  The calculation of the    *
                    value is described in the Verification section.

                    The field may be any integral number of octets in
                    length, as indicated by its Size field.  It does not
                    require any particular alignment.  The 32-bit
                    alignment shown is for convenience in the
                    illustration.                                         *

   Attribute-Choices
                    Two or more octets.  A list of one or more            |
                    attributes for this SPI, selected from the list of
                    Attributes supported by the peer.

                    The formats are specified in the "Attribute List"
                    Appendix.  The end of the list is indicated by the
                    UDP Length minus the Pad Length and Padding.

   Padding          Zero or more octets.  Prior to encryption, it is      |
                    filled with unspecified implementation dependent
                    (preferably random) values, to align the Pad Length
                    field at a boundary appropriate to the Privacy-       |
                    Method.

                    After decryption, it MUST be ignored.

   Pad Length       one octet.  The size of the Padding field in octets.
                    It does not include the Pad Length fields.  The
                    value typically ranges from 0 to 7, but may be up to
                    255 to permit hiding of the actual data length.

                    This field is always present, even though no          |
                    Privacy-Method is specified or no Padding is
                    required.

                    This field is opaque.  That is, the value is set
                    prior to encryption, and is examined only after
                    decryption.

   At any time after completion of the Identification Exchange, either
   party can send a Change_Message.  The message has effect in only one
   direction, from the SPI Owner to the SPI User.

   This message is required to be encrypted for privacy in the same       |
   fashion specified for the Identification_Messages.

   Whenever an invalid/expired cookie or attribute is detected by the
   receiver, an Error_Message is sent, and the message is discarded.



Karn & Simpson           expires in six months                 [Page 34]


DRAFT                           Photuris                   November 1995


6.1.1.  Creation

   This message can be used to create a new Security Association.
   Frequently, this message is used to create a separate authentication
   SPI when the initial SPI was used for encryption.

   In addition, this message allows more rapid SPI creation for high
   bandwidth applications.  The messages flow in the opposite direction
   from the primary traffic flow.

   The new session-keys are calculated in the same fashion as the         |
   Identification_Message.  Since the SPI value is always different than
   any previous SPI during the lifetime of the shared-secret, the         |
   resulting session-keys will necessarily be different from all others
   used in the same direction.

   When the peer's cookie or public-value has expired, it will send an
   Error_Message response.

   When the peer finds that too many SPI values are already in use for
   this party, or some other resource limit is reached, it will send an
   Error_Message response.

   No retransmission timer is necessary.  Success is indicated by the
   peer use of the new SPI.

   Should all creation attempts fail, eventually the peer will find that
   all existing SPIs have expired, and will begin the Photuris exchange
   again from the Cookie_Request.


6.1.2.  Deletion

   This message can be used to delete existing Security Associations.
   This is especially useful when all associations need deletion, such
   as when the application that needed them terminates.

   No retransmission timer is necessary.  This message is advisory, to
   reduce the number of ICMP Security Failures messages.

   Should any deletion attempts fail, the peer will learn that the
   deleted SPIs are invalid through the normal ICMP Security Failures
   messages, and will begin the Photuris exchange again from the
   Cookie_Request.







Karn & Simpson           expires in six months                 [Page 35]


DRAFT                           Photuris                   November 1995


6.1.3.  Modification

   This message cannot be used to modify existing Security Associations,
   such as lengthen an existing SPI LifeTime, resurrect an expired SPI,   *
   or add or remove an Attribute-Choice.

   On receipt, such an otherwise valid message is silently discarded.


6.1.4.  Privacy                                                           |

   This message is encrypted in the same fashion specified for the        |
   Identification_Messages.                                               |


6.1.5.  Integrity Verification

   This message is authenticated using the Validity-Method indicated by   |
   the current Scheme-Choice.  It is separate from any authentication     |
   specified for Security Associations (see "Exchange Scheme List"        |
   Appendix).

   The Validity-Method specified cryptographic hash is calculated over    |
   the following concatenated values:

    + the computed shared-secret,
    + the Initiator Cookie,                                               |
    + the Responder Cookie,                                               |
    + the SPI Owner (receiver) Identity Verification,
    + the SPI User (sender) Identity Verification,
    + the Type, LifeTime and SPI,                                         |
    + the Attribute-Choices following the Verification field,             |
    + the computed shared-secret again.

   Note that the order of the Identity Verification fields is different   |
   in each direction.

   If the verification fails, the users are notified, and an
   Error_Message is sent, without adding or deleting any Security
   Associations.  On success, normal operation begins with the
   authentication and/or encryption of user datagrams.

   Implementation Notes:

      Unlike the computationally intensive Identification Exchange, this  |
      message requires independent verification of integrity when not     |
      inherently provided by the Privacy-Method, to prevent malicious     |
      forgery of Security Attributes.                                     |



Karn & Simpson           expires in six months                 [Page 36]


DRAFT                           Photuris                   November 1995


      The Verification value is calculated prior to encryption for
      privacy, and verified after decryption.

      The Verification value is different from the SPI session-key that   *
      is created.  However, the initial octets of the concatenated
      values are the same, and the implementor may save some calculation
      effort when the generating methods are the same.

      As usual, the Cookies are checked first before performing           |
      decryption and checking the Verification.  This Verification re-    |
      checks the Cookies again.  Separate external and internal
      verification of the expected Cookies prevents clogging by replay
      of earlier Change_Messages.






































Karn & Simpson           expires in six months                 [Page 37]


DRAFT                           Photuris                   November 1995


6.2.  Error_Message

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                       Initiator-Cookie                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                       Responder-Cookie                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |  Attributes-Needed ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-


   Initiator-Cookie  16 octets.  Copied from the offending message.

   Responder-Cookie  16 octets.  Copied from the offending message.

   Type             7

   Code             Indicates the problem:

                      0   implementation error
                      1   invalid/expired
                      2   resource limit
                      3   verification failure
                      4   need attributes


   Attributes-Needed
                    variable.  A list of zero or more attributes (for
                    Code 4).

                    The formats are specified in the "Attribute List"
                    Appendix.  The end of the list is indicated by the
                    UDP Length.

   Issued in response to Photuris state loss or other problems.  The
   message has effect in only one direction.  No retransmission timer is
   necessary.

   This message is not encrypted for privacy in the fashion described
   for the Identification_Message.

   The receiver checks the Cookies for validity.  Invalid messages are
   silently discarded.




Karn & Simpson           expires in six months                 [Page 38]


DRAFT                           Photuris                   November 1995


6.2.1.  Implementation Error

   This Error_Message Code is sent when a scheme or an attribute is
   received which was not offered, or is not allowed for the feature
   specified.

   When this Code is received, the implementation SHOULD log the
   occurance, and notify an operator as appropriate.


6.2.2.  Invalid/Expired

   This Error_Message Code is sent when certain Photuris messages are
   received (as indicated in their accompanying description), and the
   receiver's cookie is invalid or the associated public-value has
   expired.

   When this Code is received, which was not itself discarded for
   invalid/expired Cookies, the shared-secret and other state between
   the parties is purged, and a new Cookie_Request is sent instead.

   However, existing SPIs are not deleted.  They expire normally, and
   are purged sometime later.


6.2.3.  Resource Limit

   This Error_Message Code is sent when a Cookie_Request or
   Change_Message is received, and too many SPI values are already in
   use for that peer, or some other Photuris resource is unavailable.

   When this Code is received, the party SHOULD NOT instantiate another
   SPI until it has deleted an existing SPI, or waited for a cached SPI
   entry to expire.


6.2.4.  Verification Failure

   This Error_Message Code is sent when an Identification_Message or
   Change_Message is received, and verification fails.

   When this Code is received, the implementation SHOULD log the
   occurance, and notify an operator as appropriate.








Karn & Simpson           expires in six months                 [Page 39]


DRAFT                           Photuris                   November 1995


6.2.5.  Need Attributes

   This Error_Message Code is sent when a party needs particular
   attributes for a datagram (such as encryption), and the peer has not
   yet created a Security Association (SPI) that has those attributes.
   The missing attributes are included in the Error_Message.

   When this Code is received, the party SHOULD send a Change_Message
   that includes the necessary attributes.










































Karn & Simpson           expires in six months                 [Page 40]


DRAFT                           Photuris                   November 1995


7.  Public Value Exchanges

   Photuris is based on public-key cryptography, specifically Diffie-
   Hellman key exchange.  Exchange of D-H Exchange-Values based on        |
   private/secret values results in a mutual shared-secret between the
   parties.  This shared-secret can be used on its own, or to generate a
   series of session-keys for authentication and encryption of
   subsequent traffic.

   Widespread deployment and use of an Internet Security protocol is
   possible without public-key cryptography.  For example, Kerberos
   [RFC-1510] can generate host-pair keys for use in Internet Security,
   much as it now generates session-keys for use by encrypted telnet and
   other "kerberized" applications.

   The Kerberos model has some widely recognized drawbacks.  Foremost is
   the requirement for a highly available on-line Key Distribution
   Center (KDC), with a database containing every principal's secret-
   key.  This carries significant security risks.

   Public-key cryptography enables decentralization.  Entities generate
   session-keys without real-time communication with any other party.

   This draft assumes familiarity with the Diffie-Hellman public-key
   algorithm.  A good description can be found in [Schneier94].


7.1.  Perfect Forward Secrecy

   Many security breaches in cryptographic systems have been facilitated
   by designs that generate traffic-encrypting keys (or their
   equivalents) well before they are needed, and then keep them around
   longer than necessary.  This creates many opportunities for
   compromise, especially by insiders.  A carefully designed public-key
   system can avoid this problem.

   The rule is to avoid using any long-lived keys (such as an RSA key-
   pair) to encrypt session-keys or actual traffic.  Such keys should be
   used solely for authentication purposes.

   All keys for traffic encryption should be randomly generated
   immediately before use, and then destroyed immediately after use, so
   that they cannot be recovered.  The keys should not be based on the
   values of any previous keys, or any other long-lived stored
   information.

   The Photuris exchange messages can provide perfect forward secrecy,
   as defined by Diffie [Diffie90], using a combination of Diffie-



Karn & Simpson           expires in six months                 [Page 41]


DRAFT                           Photuris                   November 1995


   Hellman (for key exchange) and authentication, as follows:

   1. Agree on a shared-secret using the Diffie-Hellman algorithm.

   2. Authenticate the Diffie-Hellman exchanges.  This authenticates the
      parties to each other, thwarting the "man in the middle" active
      attack against Diffie-Hellman.

   When the shared-secret generated in step 1 is eventually destroyed,
   it is unrecoverable.

   Theft of the private/secret key used to sign the exchanges in step 2
   would allow the thief to impersonate the party in future
   conversations, but it would not decode any past traffic that might
   have been recorded.


7.2.  Modular Exponentiation Groups

   The original Diffie-Hellman technique specified modular
   exponentiation.  An Exchange-Value is generated using a generator      |
   (g), raised to a private/secret exponent (x), modulo a prime (p).

      (g**x) mod p

   When two of these values are exchanged between parties, the parties
   can calculate a shared-secret value between themselves.

   Each modular exponentiation prime (p) must have the property that
   both p and (p-1)/2 are prime.  A small set of such recommended strong
   primes for use as Photuris moduli are specified.

   The prime moduli used will be well-known, and embedded in the
   implementations.  Use of a very limited number of moduli has one
   minor and two very significant advantages:

   Overhead

      Trivially avoids sending the full modulus.

   Prime and Generator Pair Selection

      Discovery of strong primes is extremely computationally intensive,
      and practically impossible for commercially available processors
      to find in a reasonable interactive time.  Verification can take
      hours or days.

      The generator (g) should be chosen such that the secret exponents



Karn & Simpson           expires in six months                 [Page 42]


DRAFT                           Photuris                   November 1995


      will generate all possible public exponential values, evenly
      distributed throughout the range, without cycling through a
      smaller subset.  Such a generator is called a "primitive root"
      (which is trivial to find when p is strong).

      When the strong prime and generator pair are well chosen, the
      difficulty of a discrete log attack is maximized.  By choosing the
      pairs in advance, analysis of the pair characteristics is
      possible.  This analysis can promote confidence in the security of
      the implementations.

   Precomputation

      Each party can precompute the D-H Exchange-Value.                   |

      A background process can periodically destroy the old values,
      generate a new random secret exponent, and recalculate the          |
      Exchange-Value.  This limits the exposure of both the secret
      exponent and shared-secret, as past secrets are not kept for
      possible discovery by a future intrusion, protecting earlier
      communications.  Also, the secret exponent currently in use is
      less likely to be anticipated, as the element of random timing is
      introduced.

      Since these operations involve several time-consuming modular
      exponentiations, moving them to the "background" substantially
      speeds up the apparent execution speed of the Photuris protocol.
      It also reduces CPU loading sufficiently to allow a single
      public/private key-pair to be used in several closely spaced
      Photuris executions, when creating Security Associations with
      several different hosts over a short period of time.

      Other precomputation suggestions are described in [BGMW93].


7.2.1.  Moduli Strengths

   The cryptographic strength (resistance to discovery of the shared-
   secret) of modular exponentiation directly depends on the length of
   the prime moduli.  Unfortunately, considerable additional length is
   needed for a few more bits of strength.

   The difficulty of finding the calculated shared-secret has long been
   presumed to be the same complexity as factoring an integer of the
   same size which is the product of two large primes:

      e ** ((ln p)**1/2 * (ln (ln p))**1/2)




Karn & Simpson           expires in six months                 [Page 43]


DRAFT                           Photuris                   November 1995


   More recent work (number field sieve) estimates that for large
   numbers the strength may approach an equivalent of:

      e ** (1.93 * (ln p)**1/3 * (ln (ln p))**2/3)

   This is significantly smaller, and raises questions about how much
   longer modular exponentiation will be a viable key exchange
   technique.

   There is another long-term problem with use of well-known moduli.
   The discrete logarithms for small(-ish) primes in the modulus field
   need only be calculated once, and the results can be combined to
   easily determine all past recorded shared-secret exchanges and all
   subsequent shared-secrets.

   Design Notes:

      The pessimistic estimates given for modular exponentiation in the   |
      "Exchange Scheme List" Appendix are based on the number field       |
      sieve.                                                              |

      The number field sieve formula is still theoretical.  Experimental
      results can be used to estimate a time constant that should be
      applied to the formula in order to fit the formula to actual
      execution times.                                                    |

      The relevant data point for this document is that a 400-bit number
      can be factored in 250 MIPS years; this result is recent (circa
      1995).  This yields an estimate of the time constant at roughly
      1.5 * 10**-15 MIPS years.

      These calculations yield an estimate of 30,000 MIPS years for       |
      512-bit moduli.  Current processing power could produce the         |
      discrete logarithm tables for any well-known 512-bit modulus in     |
      about a year.  This is unacceptable.                                |

      The estimate rises to 2.5*10**11 MIPS years for 1024-bit moduli.    |
      This is considered sufficient to be infeasable to compute the
      discrete logarithm tables for any single well-known moduli within
      a decade.

      Ideally, cooperating parties will also use their own moduli.        |
      Additional well-known moduli can be added at any time.  Should any
      particular moduli be compromised, a vast number of alternatives
      may be easily substituted.






Karn & Simpson           expires in six months                 [Page 44]


DRAFT                           Photuris                   November 1995


7.2.2.  Exponent Selection

   The cryptographic strength of the shared-secret is also dependent on   |
   the work factor of solving for the randomly chosen secret exponents.
   Revealing the exponent(s) of either party will unravel the shared-
   secret.  Each party depends upon the other to provide sufficiently
   strong exponents.

   There is surprisingly little guidance in the literature about the
   length of the secret exponents.  The size of these exponents
   dramatically affects the speed of modular exponentiation.  It is
   desirable to use the smallest random exponent that is consistent with
   good security.

   The exponent 0 will generate the public value 1, and exponent 1 will
   generate the public value g mod p.  These exponents do not qualify as
   secret.

   The most conservative advice received to date [Hellman95] is to make
   the random exponents twice as long as the strength required of the
   intended session-key.  This ensures that any space/time "meet in the
   middle" attack on the discrete logarithm problem will be at least as
   complex as a brute-force search on the resulting session-key space.

   Implementation Notes:

      A single modular exponentiation on a 486-66DX2 processor using
      RSAREF and Borland C under MS-DOS took 20 seconds with a 1024-bit
      prime modulus and a 1024-bit random exponent.  This dropped to
      about 1 to 1.5 seconds when the random exponent was shortened to
      128 bits, with the same 1024-bit modulus.

      The size of the exponent is entirely implementation dependent, is
      unknown to the other party, and can be easily changed.


7.3.  Elliptic Curve Groups

   The points on an elliptic curve form a group under addition.  This
   group can be used as the basis for the efficient implementation of
   the Diffie-Hellman operations.  To uniquely specify the computation,
   the implementor must know the finite field for representation of the
   point coordinates, the elliptic curve, and the generator.

   The elliptic curve "addition" formulas are more complicated than
   straight-forward component-wise addition, and the use of finite
   fields further complicates the description of the algorithms.  A good
   reference for a succinct description of elliptic curves with finite



Karn & Simpson           expires in six months                 [Page 45]


DRAFT                           Photuris                   November 1995


   fields is [P1363]; a more general treatment can be found in
   [Menezes].  A treatise on efficient software implementation is in
   [Schroeppel].

      Note that while the literature uses the term "addition" for the
      group operation, it is directly analogous to "multiplication" in
      modular exponentiation groups.  Thus, the analogous term for
      "g**r" is "r*g" (that is, the scalar multiple r of g).

   The generator is specified as the (x,y) coordinates of an elliptic
   curve point, and the representation of x and y is given with respect
   to a finite field.  Multiples of the generator are (x,y) pairs.

   Thus, the Initiator and Responder Exchange-Values are to be
   interpreted as two concatenated bit values in the order (x,y).  The
   lengths of the coordinates are implicit in the specification of the
   field.

   The field representation is uniquely determined by the irreducible
   polynomial specified in the group description.  See the "Exchange
   Scheme List" Appendix for details.

   The principle advantage enjoyed by use of these elliptic curves is
   that calculation times are significantly reduced compared to modular
   exponentiation of the same cryptographic strength.  The advantage of
   elliptic curves becomes more pronounced as the length of the shared-
   secret increases.

   Use of a very limited number of fields has similar advantages to
   those cited for modular exponentiation: reduced overhead, field and
   generator selection, and precomputation of the Exchange-Values.  It    |
   also allows great latitude in code optimization.

   Overhead

      Avoids sending the several polynomial parameters.

   Field Selection

      Discovery of elliptic curves with a large prime divisor is
      extremely computationally intensive, and practically impossible
      for commercially available processors to find in a reasonable
      interactive time.  Verification can take days or weeks.








Karn & Simpson           expires in six months                 [Page 46]


DRAFT                           Photuris                   November 1995


7.3.1.  Field Strengths

   Although analysis is still in early stages, it appears that elliptic
   curves do not suffer some limitations of modular exponentiation.  The
   Diffie-Hellman algorithm, when implemented over elliptic curve
   groups, is not subject to the index calculus attack that leads to the
   equivalence of the difficulty of factoring with the difficulty of
   solving modular exponentiation.

   This means that elliptic curve groups have an overall strength that
   is equal to one half of the log of the group size.  Increasing the
   length of the parameters appears to have a proportional improvement
   in cryptographic strength.


7.3.2.  Exponent Selection

   As in modular exponentiation, the cryptographic strength of the
   shared-secret is also dependent on the work factor of solving for the  |
   randomly chosen secret exponents.  Unlike modular exponentiation, the
   size of the exponents does not dominate the speed of calculating the
   elliptic curve groups.

   The lengths of the randomly chosen secret exponents are usually the    |
   same as the number of bits in the generated keying material.  This is
   twice as long as the resulting overall strength.

























Karn & Simpson           expires in six months                 [Page 47]


DRAFT                           Photuris                   November 1995


A.  Exchange Scheme List

   Up-to-date values for the Exchange Schemes are specified in the most   |
   recent "Assigned Numbers" [RFC-1700].  Implementors wishing a number   |
   indicated as "unassigned" MUST request the number from IANA.  Initial  |
   values are assigned as follows:

   (0)   Reserved.

   (1)   Implementation Optional.  Elliptic curve:

         curve: y^2 + xy = x^3 + 0x7338F
         generator: (0x7B, 0x1C8)
         irreducible polynomial: u^155 + u^62 + 1

         Provides 155 bits of keying material (in 160 bits).  The
         cryptographic strength is currently estimated to be equivalent
         to 155/2 bits.  The x and y coordinates are 155 significant
         bits each (310 bits total).  Exponent lengths are always 155     |
         bits each.

         The Identification_Message and Change_Message Privacy-Method is  |
         DES-CBC-64.                                                      |

         The Change_Message Validity-Method is MD5.                       |

         Supplied by Hilarie Orman <ho@cs.arizona.edu>.

   (2)   Implementation Required.  Modular Exponentiation using a 1024-
         bit strong prime (p), expressed in hex:

            97f6 4261 cab5 05dd  2828 e13f 1d68 b6d3
            dbd0 f313 047f 40e8  56da 58cb 13b8 a1bf
            2b78 3a4c 6d59 d5f9  2afc 6cff 3d69 3f78
            b23d 4f31 60a9 502e  3efa f7ab 5e1a d5a6

            5e55 4313 828d a83b  9ff2 d941 dee9 5689
            fada ea09 36ad df19  71fe 635b 20af 4703
            6460 3c2d e059 f54b  650a d8fa 0cf7 0121
            c747 99d7 5871 32be  9b99 9bb9 b787 e8ab

         The recommended generator (g) for this prime is 2.

         Provides 1024 bits of keying material.  The cryptographic
         strength is currently estimated to be equivalent to 86 bits
         (pessimistic) through 98 bits (optimistic).  Exponent lengths
         of 196 to 256 bits are recommended.                              *




Karn & Simpson           expires in six months                 [Page 48]


DRAFT                           Photuris                   November 1995


         The Identification_Message and Change_Message Privacy-Method is  |
         DES-CBC-64.

         The Change_Message Validity-Method is MD5.                       |

         This prime modulus was randomly generated by a freely available  |
         program written by Phil Karn, verified using the                 |
         mpz_probab_prime() function Miller-Rabin test in the Gnu Math    |
         Package (GMP) version 1.3.2; and also verified with GMP on       |
         other platforms by Wei Dai and Frank A Stevenson, as well as     |
         independently developed test libraries by Eric Young (Miller-    |
         Rabin test), and Rich Schroeppel (complete Elliptic Curve        |
         test).                                                           |

   (3)   Moduli-indices of 3 to 8 are currently reserved, and are         |
         specified in a companion document.                               |

   (9)   Moduli-indices of 9 to 255 are currently unassigned.

   (256) Moduli-indices of 256 to 65535 are available for cooperating     |
         parties to indicate private schemes.






























Karn & Simpson           expires in six months                 [Page 49]


DRAFT                           Photuris                   November 1995


B.  Attribute List

   Up-to-date values for the Attribute Type are specified in the most     |
   recent "Assigned Numbers" [RFC-1700].  Implementors wishing a number
   indicated as "unassigned" MUST request the number from IANA.  Initial
   values are assigned as follows:

      A  I    Type                                                        |
                 0  padding                                               |
                 1  reserved                                              |
      +  +       2  MD2                                                   |
                 3  reserved                                              |
      +  +       4  MD4                                                   |
      *  *       5  MD5                                                   |
      +  +       6  SHA                                                   |
              7-11  unassigned (hashing)                                  |
      +         12  RC2                                                   |
                13  reserved                                              |
      +         14  RC4                                                   |
      +         15  RC5                                                   |
      +         16  DES-CBC, 0-bit IV                                     |
      *         17  DES-CBC, 32-bit IV                                    |
      *         18  DES-CBC, 64-bit IV                                    |
                19  reserved                                              |
      +         20  Triple DES-CBC, 0-bit IV                              |
      +         21  Triple DES-CBC, 32-bit IV                             |
      +         22  Triple DES-CBC, 64-bit IV                             |
                23  reserved                                              |
      +         24  IDEA                                                  |
         +      25  DSS                                                   |
         +      26  PKCS                                                  |
         +      27  DNS-SIG certificate                                   |
         +      28  PGP certificate                                       |
         +      29  X.509 certificate chain                               |
             30-31  unassigned (certificates)                             |
      +         32  Sensitivity Label                                     |
      +         33  VJ Header Compression                                 |
      +         34  LZ77                                                  |
      +         35  Stac LZS                                              |
      +         36  AH-Sequence                                           |
            37-254  unassigned                                            |
      x  x     255  Organizational                                        |

      A     Initiator/Responder Attribute-Choice                          |
         I  Identity-Choice                                               |
         *  mandatory algorithm must be supported                         |
         +  feature must be supported                                     |
            when algorithm optionally supported                           |



Karn & Simpson           expires in six months                 [Page 50]


DRAFT                           Photuris                   November 1995


         x  feature may be supported                                      |
            when algorithm optionally supported                           |

   Attributes that are required to be supported are included in this
   document.  Other attributes are specified in companion documents.      |


   B.1.  Padding                                                          |

      +-+-+-+-+-+-+-+-+
      |     Type      |
      +-+-+-+-+-+-+-+-+


      Type             0                                                  |

      Each attribute may have value fields that are multiple octets.  To
      facilitate processing efficiency, these fields are aligned on       |
      integral modulo 8 octet (64-bit) boundaries.

      Padding is accomplished by insertion of 1 to 7 Type 0 padding       |
      octets before the attribute that needs alignment.

      No padding is used after the final attribute in a list.


   B.2.  MD5                                                              |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      Type             5                                                  |

      Length           0

      The selected Exchange Scheme SHOULD provide at least 64-bits of     |
      cryptographic strength.

      Attribute-Choice                                                    *

         When selected as an Initiator or Responder Attribute-Choice,
         pursuant to [RFC-1828], MD5 is also used as the key generation   |
         cryptographic hash for generating the SPI session-key.  All      |
         128-bits of the generated hash are used for the key.





Karn & Simpson           expires in six months                 [Page 51]


DRAFT                           Photuris                   November 1995


Identity-Choice                                                           |

   When selected as an Identity-Choice, the resulting Verification field
   is 128-bits (18 octets including Size).

   The MD5 hash is calculated as described in "Identity Verification".
   The authentication secret-key (as specified) is selected based on the
   contents of the Identification field.

   The Identification field contains a variable precision number.  Valid
   Identifications and 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.

   Typically, the Identification is a user name, a Fully Qualified
   Domain Name, or an email address which contains a user name and a
   domain name.  Examples include:

      user
      node.site.
      user@node.site.
      rcmd@node.site.

   There is no requirement that the domain name match any of the
   particular IP addresses in use by the parties.

Validity-Method                                                           |

   When selected as a Validity-Method, the resulting Verification field   |
   is 128-bits (18 octets including Size).

   The hash is calculated as described in "Change Verification".  The
   leading shared-secret is not padded to any particular alignment.


B.3.  DES-CBC

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type             16, 17 or 18                                          |

   Length           0

   The selected Exchange Scheme SHOULD provide at least 56-bits of        |



Karn & Simpson           expires in six months                 [Page 52]


DRAFT                           Photuris                   November 1995


   cryptographic strength.                                                |

   Attribute-Choice

      When selected as an Initiator or Responder Attribute-Choice,
      pursuant to [RFC-1829], MD5 is used as the key generation           |
      cryptographic hash for generating the SPI session-key.  The most    |
      significant 64-bits of the generated hash are used for the key.     |
      The least significant bit of each octet is ignored (or set to       |
      parity).

Privacy-Method                                                            |

   When selected as a Privacy-Method, MD5 is used as the key generation   |
   cryptographic hash for generating the privacy session-key.  The most   |
   significant 64-bits of the generated hash are used for the key.  The   |
   least significant bit of each octet is ignored (or set to parity).

   The 64-bit Initialization Vector (IV) is set to the Type, LifeTime,    *
   and SPI fields.  Encryption begins with the next field, and continues
   to the end of the data indicated by the UDP Length.






























Karn & Simpson           expires in six months                 [Page 53]


DRAFT                           Photuris                   November 1995


B.4.  Organizational

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |              OUI
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          ...      |     Kind      |  Value(s) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type             255

   Length           >= 4                                                  |

                    When the Length is four, no Value(s) field is         |
                    present.

   OUI              three octets.  The vendor's Organizationally Unique
                    Identifier, assigned by IEEE 802 (see [RFC-1700] for
                    contact details).  The bits within the octet are in
                    canonical order, and the most significant octet is
                    transmitted first.

   Kind             one octet.  Indicates a sub-type for the OUI.  There
                    is no standardization for this field.  Each OUI
                    implements its own values.

   Value(s)         Zero or more octets.  The details are implementation  |
                    specific.

   Some implementors might not need or want to publish their proprietary
   algorithms and attributes.  This OUI mechanism is available to
   specify these without encumbering the IANA with proprietary number
   requests.


















Karn & Simpson           expires in six months                 [Page 54]


DRAFT                           Photuris                   November 1995


C.  Scenarios

   Herewith are a few simplified examples of exchanges.  These are not
   intended to be overly inclusive.  There are opportunities for
   optimization, many of which are indicated in Implementation Notes in
   the main text.


C.1.  Virtual Private Network

   An administrator has two networks, and wishes all traffic between
   them to be encrypted.  The boundary routers are 1.0.0.1 and 2.0.0.2.

   The commands to tunnel and encrypt are added.  In the former router,

      route addp 2.0.0.0/8 tunnel 2.0.0.2
      secure 2.0.0.2

   and in the latter router,

      route addp 1.0.0.0/8 tunnel 1.0.0.1
      secure 1.0.0.1

   In each router, the lazy administrator uses the same username and
   password,

      user "root" "abracadabra"

   When the first datagram arrives at router 1.0.0.1 destined for node
   2.2.2.2, the routing table indicates that it should be encapsulated
   for 2.0.0.2.  However, the more specific routing table entry for
   2.0.0.2 indicates that security is required.  None is currently
   available, so the encapsulated datagram is tossed in the bit-bucket,
   and a Photuris exchange is initiated instead.

   Router 1.0.0.1 selects a random number (0x1111) and a UDP port
   (4097).  It hashes these together with its IP Source and the IP
   Destination, and saves the hash value as its unique cookie for this
   exchange.  A Cookie_Request is sent to 2.0.0.2 at UDP Port 468
   containing the Initiator_Cookie.

   Router 2.0.0.2 also generates a random number (0x2222) and saves it
   in a global variable.

   When Router 2.0.0.2 receives the Cookie_Request, it hashes the UDP
   Ports (4097 and 468) together with its IP Source, the IP Destination,
   and its global random number, and sends a Cookie_Response.  The reply
   also indicates that only Exchange Scheme 2 is offered.



Karn & Simpson           expires in six months                 [Page 55]


DRAFT                           Photuris                   November 1995


   When Router 1.0.0.1 receives (and validates) the Cookie_Response, it
   generates a second random number with enough bits of strength for the
   strongest attributes supported (default 128-bits: 0x1111...1111), and  |
   calculates an Exchange-Value for Exchange Scheme 2.  An
   Exchange_Request is sent to 2.0.0.2 containing the scheme and value,
   and offering three attributes (MD5, DES-CBC-32, DES-CBC-64).

   When Router 2.0.0.2 receives (and validates) the Exchange_Request, it
   also generates a second random number with enough bits of strength
   for the strongest attributes supported (default 128-bits:
   0x2222...2222), calculates an Exchange-Value for Exchange Scheme 2,    |
   and sends an Exchange_Response.  The reply also indicates that the
   next steps will be encrypted with DES-CBC-64, as well as offering
   three attributes (MD5, DES-CBC-32, DES-CBC-64).

   Router 2.0.0.2 begins calculating the shared-secret.

   When Router 1.0.0.1 receives (and validates) the Exchange_Response,
   it also calculates the shared-secret.

   When Router 1.0.0.1 finishes calculating the shared-secret, it
   generates a third random number for its SPI (0x12345678), and
   indicates an appropriate LifeTime (300 seconds).

   It chooses a set of Attributes (MD5 and DES-CBC-32).  Based on its     |
   Identity-Choice (MD5), Identification (root), and the secret
   (abracadabra), it calculates a hash over the many values exchanged,
   and stores this in the Verification field.

   Then, the Type through SPI fields are used as an Initialization
   Vector, and DES-CBC-64 is used to encrypt the remainder of the
   message after the SPI.  The resulting Identification_Message is sent
   to 2.0.0.2.

   When Router 2.0.0.2 receives (and validates) the
   Identification_Message, and finishes calculating the shared-secret,
   it also generates a third random number for its SPI (0xdeadbeef),
   indicates an appropriate LifeTime (600 seconds), and performs the
   same functions described above.

   In this example, the Identification and secret-key are the same for
   both parties.  Note that even in the face of implementations with
   very poor random number generation yielding the same random numbers
   for both parties at every step, the calculation order of the fields
   is different and the verification result will have a very high
   probability of difference.





Karn & Simpson           expires in six months                 [Page 56]


DRAFT                           Photuris                   November 1995


C.2.  Authenticated Firewall Traversal

   An administrator has one or more networks, and a number of mobile
   users.  It is desirable to restrict access to authorized external
   users.  The boundary router is 3.0.0.3.

   Each user adds commands to tunnel and authenticate.

      route addp 3.0.0.0/8 tunnel 3.0.0.3
      secure 3.0.0.3 authenticate-only

   The administrator gives each user a different username and password,
   together with a separate username and password for the router.  (A
   lazy administrator can simply give one username and password to all
   users for both the user and the router, as described previously.)

      user "wanderer" "FalDaRee"
      user "router"   "FalDaRah"

   The mobile host is assigned a temporary local IP address (4.0.0.4).

   When the first datagram is generated destined for node 3.3.3.3, the
   routing table indicates that it should be encapsulated for 3.0.0.3.
   However, the more specific routing table entry for 3.0.0.3 indicates
   that authentication is required.  None is currently available, so the
   encapsulated datagram is tossed in the bit-bucket, and a Photuris
   exchange is initiated instead.

   The Photuris exchange proceeds as previously described, except that
   two Identifications are involved.  Router 3.0.0.3 may be configured
   with all the usernames permitted, or more likely will access an
   external database of usernames and passwords using a mechanism such
   as RADIUS.

   Even though router 3.0.0.3 includes DES-CBC-32 in its Attribute-
   Choices, the mobile node configuration does not require that every
   datagram be encrypted.  That is, the specific policy of this mobile
   node is that an AH be added whenever traffic is sent to 3.0.0.3, but
   that no ESP is used.

   In this example, the boundary router has no configured policy with
   respect to the mobile node.  This would be difficult, as the actual
   IP address assignment is unpredictable.

   However, a serendipitous SPI has been created by the mobile node.
   When the router prepares to forward a datagram from inside net 3, it
   will discover that the routing table entry for 4.0.0.4 includes a
   security association.  The router implementor could legitimately use



Karn & Simpson           expires in six months                 [Page 57]


DRAFT                           Photuris                   November 1995


   that SPI for AH and/or ESP in the absence of contrary policy
   configuration.

   Therefore, the mobile node must be capable of receiving encapsulated
   authenticated and/or encrypted traffic using its SPI.  It must also
   be capable of receiving unauthenticated and unencrypted traffic.


C.3.  Automated Firewall Bypass

   Although the previous examples may be adequate in early stages of
   deployment, where many nodes have not yet been upgraded to include
   Internet Security, the "ultimate goal" is direct IP connectivity.
   This is particularly required when both nodes are mobile, and there
   are no fixed well-known routers between them.  This will also reduce
   configuration, and facilitate network renumbering.

   Instead of relying on an administrator, the users are empowered to
   select their own usernames and passwords.  They may change them at
   any time with the standard tools provided by their operating systems.
   (A lazy user can simply have one username and password on all
   systems, as described previously.)

      user "myself@LapTop.WhereEver"   "o,WabM,"
      user "myself@DeskTop.WhereEver"  "o,WabD!"

   The user may find it convenient (or be required by the operating
   system) to use a more formal naming syntax (above), simply to keep
   the many accessible systems separate.

   When the LapTop is attempting to access the DeskTop, it may be
   obstructed by an intervening router acting as a firewall.  This is
   indicated by the ICMP message Destination Unreachable: Communication
   Administratively Prohibited (Type 3, Code 13).

   The Photuris exchange proceeds as previously described, except that
   rather than sending to the firewall, the exchange is attempted to the
   actual target system first.  This will work when the firewall is
   capable of passing Photuris datagrams, as well as AH and ESP
   protected datagrams.

   If the implementation continues to receive ICMP messages in response
   to the Cookie_Request, it should abandon the exchange and attempt a
   new Photuris exchange with the intervening router instead.  This may
   be problematic when the router does not have a public-key form of
   signature available, as by definition the user has not configured the
   presence of this router.  Such a mechanism is outside the scope of
   this document.



Karn & Simpson           expires in six months                 [Page 58]


DRAFT                           Photuris                   November 1995


C.4.  Multi-User Access Control

   In certain extremely security conscious environments, all valid users
   sharing a node might not have the same level of authorization.  Each
   user or process requires its own identification and access contol.
   These "Multi-Level Secure" environments require two or more Photuris
   exchanges.

   These exchanges involve 4 or more entities:

      user "myself@SomeWhere"  "mairsydotes"
      user "system@SomeWhere"  "doesydotes"
      user "myself@ElseWhere"  "liddellamsydivy"
      user "system@ElseWhere"  "kiddellydivy"

   The first Photuris exchange might be triggered when sending a
   datagram from SomeWhere to ElseWhere.  The Initiator would naturally
   use the Identification which is associated with the triggering
   transport-level process (myself@SomeWhere).

   Because Photuris is a network-level session key management protocol,
   the Responder Identification will be associated with the operating
   system which is processing the network-level exchange
   (system@ElseWhere).  Thus, the resulting SPI could be described as
   myself-system-SPI:ElseWhere.

   Note that myself-system-SPI:ElseWhere was authenticated by the
   Initiator.  Since authentication policy is in the receiver direction,
   when datagrams arrive at ElseWhere with the given SPI, the access
   policy will be dependent on the Initiator Identification.

   Likewise, when datagrams arrive at SomeWhere with system-myself-
   SPI:SomeWhere, the access policy will be dependent on the Responder
   Identification.  This may not match the authorization level required
   for access.  This is indicated by the ICMP message Security Failures:
   Need Authorization (Type 40, Code 5).

   The Responder in turn becomes the Initiator in a second exchange, and
   delivers the Identification which is associated with the triggering
   transport-level process (myself@ElseWhere), creating myself-system-
   SPI:SomeWhere.  The peer might use its system-wide Identification
   (system@SomeWhere), creating system-myself-SPI:ElseWhere.

   When repetitive Photuris exchanges occur between the same parties,     |
   and the Exchange-Values are discovered to be unchanged, the cached
   shared-secret can be used to rapidly generate new session-keys.

   Only myself-system-SPI:SomeWhere and myself-system-SPI:ElseWhere



Karn & Simpson           expires in six months                 [Page 59]


DRAFT                           Photuris                   November 1995


   provide user-level keying in each direction.  Depending on policy,
   these might be the only SPIs used.


C.5.  Long LifeTime SPIs                                                  |

   In certain minimalist security environments, it may be desirable to    |
   reduce the number of Photuris Exchanges.                               |

   For example, repeated crashes of servers will normally cause the       |
   clients to re-initiate a Photuris Exchange as the system reboots and   |
   comes on-line.  When thousands of nodes are involved, the Photuris     |
   Exchanges may consume a large amount of computation, effectively       |
   lengthening the outage.                                                |

   In addition, when perfect forward secrecy is not needed (such as       |
   authenticated firewall traversal without encryption), there is no      |
   requirement that the SPI session-key LifeTime be kept short, or        |
   limited to a certain amount of data.                                   |

   Instead, the SPI session-keys may be cached in long-term storage.      |
   The size of the Photuris SPI LifeTime is sufficient for weeks or       |
   months of long-term storage (2**24-1 seconds is about half a year).    |

   This depends upon a design feature of Photuris.  The SPI LifeTime is   |
   not related to the Photuris Exchange LifeTime.  That is, any           |
   particular SPI session-key can be stored for long periods of time      |
   without compromising other uses of the same calculated shared-secret.  |

   Implementation Notes:                                                  |

      The careful reader will undoubtedly notice that this scenario is    |
      somewhat tongue-in-cheek.  Repeated crashes of servers might be     |
      fixed by changing to a different vendor....                         |

      The shared-secrets MUST NOT be cached to long-term storage.         |

      Encryption session-keys MUST NOT be cached to long-term storage.    |













Karn & Simpson           expires in six months                 [Page 60]


DRAFT                           Photuris                   November 1995


Security Considerations

   Security issues are the primary topic of this memo.

   The security of Photuris critically depends on the quality of the
   secret random numbers generated by each party.  A poor random number
   generator at either party will compromise the shared-secret produced
   by the algorithm.

   Generating cryptographic quality random numbers on a general purpose
   computer without hardware assistance is a very tricky problem.  In
   general, this requires using a cryptographic hashing function to
   "distill" the entropy from a large number of semi-random external
   events, such as the timing of key strokes.  An excellent discussion
   can be found in [RFC-1750].

   Each Photuris exchange generates a calculated shared-secret.  The
   strength of the shared-secret is essential to the strength of the
   Security Associations.  Discovery of the underlying shared-secret
   would compromise the Security Associations relying upon it.

   Photuris generation of session-keys involves a cryptographic hash
   over the shared-secret.  The shared-secret is itself only indirectly
   used for creating those keys that actually protect session traffic.

   This protects the shared-secret from discovery, and allows repeated
   use of the shared-secret for generating multiple session-keys.
   Discovery of one such key should not reveal related session-keys.

   This use of the calculated shared-secret, for message integrity, for
   privacy, and for creating multiple session-keys by hashing with a new
   SPI, substantially depends on the quality of the chosen cryptographic
   hashing function(s) that generate the keys.  This is mitigated by      |
   carefully organized differences in calculation of the integrity,
   privacy, and SPI session-keys in each direction, and the optional      *
   concealment of the algorithms chosen for each SPI.

   When an interceptor can modify or substitute another SPI, alteration
   of the SPI will interrupt communication, but the attacker will gain
   no additional information.

   The Verification method must not allow "message recovery", to prevent
   determination of the shared-secret or any long-term distributed
   secret-key (where applicable).  More specifically, it should not be
   feasible to compute any of the bits of an authenticated message from
   the verification value.

   In general, where a secret (such as the shared-secret or session-



Karn & Simpson           expires in six months                 [Page 61]


DRAFT                           Photuris                   November 1995


   keys) is involved in any calculation, the algorithms selected should
   not reveal information about the secret, either directly or
   indirectly.

   The modular exponentiation, elliptic curve, and key generation
   algorithms provide a differing number of bits of keying material.  It
   is important to distinguish the characteristics of these bits.

   A. The length of the shared-secret depends on the modulus or field
      size.

   B. The strength of the shared-secret depends on the modulus or field
      selection, and the minimum exponent length used by either party.

   C. The length of the generated keying material depends on the details
      of the key generation algorithm.

   D. The strength of the generated keying material depends on the
      strength of the shared-secret, and is limited by the length of the
      generated keying material itself.

   E. The length of the session-key used by a transform depends on the
      details of the transform.

   F. The strength of the session-key used by a transform depends on the
      strength of the keying material, and is limited by the length of
      the session-key used by the transform itself.

   The length of the shared-secret affects the difficulty of finding
   hash collisions that might reveal the shared-secret.  The lengths of
   the shared-secret and hashing function combinations are considered
   sufficient to provide greater robustness than the cryptographic
   strength of the public-key exchange itself.

   That is, it is likely to be easier to find the underlying shared-
   secret through analysis of the Exchange-Values than to determine       |
   collisions for a particular generated key.

   Use of exponents or a key generation algorithm that produces less
   strength than required for a selected transform results in less
   robust security than would otherwise be expected.

   Different attributes require different levels of session-key
   strength.  Each party should offer exchange-schemes and use exponents  |
   that provide the length and strength required for the strongest
   offered attribute.

   Once an exchange-scheme has been selected, the implementation should



Karn & Simpson           expires in six months                 [Page 62]


DRAFT                           Photuris                   November 1995


   limit attribute choices to those which need no more than the shared-
   secret strength provided.

   It is the responsibility of the implementor to choose a useful set of
   attributes for each Security Association, that provide the best
   tradeoff of security and performance for a given application.  In
   general, when more than one attribute providing the same function is
   offered, the strongest algorithm should be selected.


Acknowledgements

      Thou shalt make no law restricting the size of integers that may
      be multiplied together, nor the number of times that an integer
      may be multiplied by itself, nor the modulus by which an integer
      may be reduced.  [Prime Commandment]

   Phil Karn is principally responsible for the design of the protocol
   phases, particularly the clogging defense, and initial internet
   security protocol implementation experience spanning more than 4
   years.

   William Simpson was responsible for adding attributes, other message
   types, editing and formatting.  All such mistakes are his
   responsibity.

   This protocol was later discovered to have many elements in common
   with the Station-To-Station authentication protocol, described in
   [DOW92].

   Paul C van Oorschot suggested signing both the public exponents and    *
   the session-key, to provide an authentication-only version of
   identity verification.

   Hilarie Orman provided text regarding elliptic curves, and extensive
   review of the protocol details.

   Randall Atkinson, James Hughes, Angelos Keromytis, Brian LaMacchia,
   Cheryl Madson, Perry Metzger, Ron Rivest, Rich Schroeppel, and Bill    |
   Sommerfeld provided useful critiques of earlier versions of this
   document.


References

   [BGMW93]  E. Brickell, D. Gordon, K. McCurley, and D. Wilson, "Fast
            Exponentiation with Precomputation (Extended Abstract)",
            Advances in Cryptology -- EUROCRYPT '92, Lecture Notes in



Karn & Simpson           expires in six months                 [Page 63]


DRAFT                           Photuris                   November 1995


            Computer Science, 658 (1993), Springer-Verlag, 200-207.

   [Diffie90]
            Whitfield Diffie, "Authenticated Key Exchange and Secure
            Interactive Communication", Northern Telecom, Securicom '90,
            Paris France, 16 March 1990.

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

   [Firefly]
            "Photuris" is the latin name for the firefly.  "Firefly" is
            in turn the name for the USA National Security
            Administration's (classified) key exchange protocol for the
            STU-III secure telephone.  Informed speculation has it that
            Firefly is based on very similar design principles.

   [Hellman95]
            Martin Hellman, personal communication.

   [Menezes]
            Alfred J. Menezes, "Elliptic Curve Public Key
            Cryptosystems", Kluwer Academic Publishers, 1993.

   [P1363]  Alfred J. Menezes, Minghua Qu, and Scott A. Vanstone,
            "Standard for RSA, Diffie-Hellman and Related Public Key
            Cryptography", Working Draft of IEEE P1363 Standard, Oct.
            30, 1994.  http://www.rsa.com/pub/p1363/draft/

   [Prime Commandment]
            A derivation of an apocryphal quote from the usenet
            sci.crypt.

   [RFC-768]
            Postel, J., "User Datagram Protocol", STD 6, August 1980.

   [RFC-1510]
            Kohl, J., Neuman, B., "The Kerberos Network Authentication
            Service (V5)", September 1993.

   [RFC-1700]
            Reynolds, J., and Postel, J., "Assigned Numbers", STD 2,
            USC/Information Sciences Institute, October 1994.

   [RFC-1750]
            Eastlake, Crocker & Schiller, "Randomness Recommendations



Karn & Simpson           expires in six months                 [Page 64]


DRAFT                           Photuris                   November 1995


            for Security", December 1994.

   [RFC-1825]
            Atkinson, R., "Security Architecture for the Internet
            Protocol", Naval Research Laboratory, July 1995.

   [RFC-1828]
            Metzger, P., Simpson, W., "IP Authentication using Keyed
            MD5", July 1995.

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

   [Schneier94]
            Schneier, B., "Applied Cryptography", John Wiley & Sons, New
            York, NY, 1994.  ISBN 0-471-59756-2.

   [Schroeppel95]
            R. Schroeppel, H. Orman, S. O'Malley, and O. Spatscheck,
            "Fast Key Exchange with Elliptic Curve Systems", Advances in
            Cryptology -- Crypto '95, Santa Barbara, California, August
            1995.  ftp://ftp.cs.arizona.edu/reports/1995/TR95-03.ps




























Karn & Simpson           expires in six months                 [Page 65]


DRAFT                           Photuris                   November 1995


Author's Address(es)

   Questions about this memo 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 (prefered)


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

      Bill.Simpson@um.cc.umich.edu
          bsimpson@MorningStar.com (prefered)






























Karn & Simpson           expires in six months                 [Page 66]


DRAFT                           Photuris                   November 1995


                           Table of Contents


     1.     Introduction ..........................................    1
        1.1       Terminology .....................................    2
        1.2       Protocol Description ............................    3
        1.3       Clogging Defense ................................    6
        1.4       Traffic Anonymity ...............................    8
        1.5       Security Parameters .............................    9
        1.6       User Support ....................................   10
        1.7       Multicast Support ...............................   11

     2.     Protocol Details ......................................   12
        2.1       UDP .............................................   12
        2.2       Header Format ...................................   13
        2.3       Exchange Schemes ................................   13
        2.4       Attributes ......................................   14
        2.5       Variable Precision Numbers ......................   16

     3.     Cookie Exchange .......................................   17
        3.1       Cookie_Request ..................................   19
        3.2       Cookie_Response .................................   19
        3.3       Cookie Generation ...............................   20

     4.     Value Exchange ........................................   21
        4.1       Exchange_Request ................................   23
        4.2       Exchange_Response ...............................   24

     5.     Identification Exchange ...............................   25
        5.1       Identification_Message ..........................   27
        5.2       Shared-Secret ...................................29
        5.3       Privacy .........................................   29
        5.4       Identity Verification ...........................   30
        5.5       Session-Key Computation .........................   31

     6.     Other Message Types ...................................   33
        6.1       Change_Message ..................................   33
           6.1.1  Creation ........................................   35
           6.1.2  Deletion ........................................   35
           6.1.3  Modification ....................................   36
           6.1.4  Privacy .........................................36
           6.1.5  Integrity Verification ..........................   36
        6.2       Error_Message ...................................   38
           6.2.1  Implementation Error ............................   39
           6.2.2  Invalid/Expired .................................   39
           6.2.3  Resource Limit ..................................   39
           6.2.4  Verification Failure ............................   39
           6.2.5  Need Attributes .................................   40



Karn & Simpson           expires in six months                 [Page ii]

DRAFT                           Photuris                   November 1995


     7.     Public Value Exchanges ................................   41
        7.1       Perfect Forward Secrecy .........................   41
        7.2       Modular Exponentiation Groups ...................   42
           7.2.1  Moduli Strengths ................................   43
           7.2.2  Exponent Selection ..............................   45
        7.3       Elliptic Curve Groups ...........................   45
           7.3.1  Field Strengths .................................   47
           7.3.2  Exponent Selection ..............................   47

     APPENDICES ...................................................   48

     A.     Exchange Scheme List ..................................   48

     B.     Attribute List ........................................   50
           B.1       Padding ......................................51
           B.2       MD5 ..........................................   51
        B.3       DES-CBC .........................................   52
        B.4       Organizational ..................................   54

     C.     Scenarios .............................................   55
        C.1       Virtual Private Network .........................   55
        C.2       Authenticated Firewall Traversal ................   57
        C.3       Automated Firewall Bypass .......................   58
        C.4       Multi-User Access Control .......................   59
        C.5       Long LifeTime SPIs ..............................60

     SECURITY CONSIDERATIONS ......................................   61

     ACKNOWLEDGEMENTS .............................................   63

     REFERENCES ...................................................   63

     AUTHOR'S ADDRESS .............................................66                                          |


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/