rfc2522.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   1. A "Cookie" Exchange guards against simple flooding attacks sent
      with bogus IP Sources or UDP Ports.  Each party passes a "cookie"
      to the other.

      In return, a list of supported Exchange-Schemes are offered by the
      Responder for calculating a shared-secret.

   2. A Value Exchange establishes a shared-secret between the parties.
      Each party passes an Exchange-Value to the other.  These values
      are used to calculate a shared-secret.  The Responder remains
      stateless until a shared-secret has been created.

      In addition, supported attributes are offered by each party for
      use in establishing new Security Parameters.

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

      In addition, the shared-secret provides a basis to generate
      separate session-keys in each direction, which are in turn used
      for conventional authentication or encryption.  Additional
      security attributes are also exchanged as needed.

      This exchange is masked for party privacy protection using a
      message privacy-key based on the shared-secret.  This protects the
      identities of the parties, hides the Security Parameter attribute
      values, and improves security for the exchange protocol and
      security transforms.

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



Karn & Simpson                Experimental                      [Page 3]

RFC 2522                   Photuris Protocol                  March 1999


      These exchanges are also masked for party privacy protection in
      the same fashion as above.

   The sequence of message types and their purposes are summarized in
   the diagram below.  The first three phases (cookie, exchange, and
   identification) must be carried out in their entirety before any
   Security Association can be used.

   Initiator                            Responder
   =========                            =========
   Cookie_Request                 ->
                                   <-   Cookie_Response
                                           offer schemes
   Value_Request                  ->
      pick scheme
      offer value
      offer attributes
                                   <-   Value_Response
                                           offer value
                                           offer attributes

             [generate shared-secret from exchanged values]


   Identity_Request               ->
      make SPI
      pick SPI attribute(s)
      identify self
      authenticate
      make privacy key(s)
      mask/encrypt message
                                   <-   Identity_Response
                                           make SPI
                                           pick SPI attribute(s)
                                           identify self
                                           authenticate
                                           make privacy key(s)
                                           mask/encrypt message

               [make SPI session-keys in each direction]











Karn & Simpson                Experimental                      [Page 4]

RFC 2522                   Photuris Protocol                  March 1999



   SPI User                             SPI Owner
   ========                             =========
   SPI_Needed                     ->
      list SPI attribute(s)
      make validity key
      authenticate
      make privacy key(s)
      mask/encrypt message
                                   <-   SPI_Update
                                           make SPI
                                           pick SPI attribute(s)
                                           make SPI session-key(s)
                                           make validity key
                                           authenticate
                                           make privacy key(s)
                                           mask/encrypt message

   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.


1.3.  Security Parameters

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

   The SPI is assigned by the entity controlling the IP Destination: the
   SPI Owner (receiver).  The parties use the combination of IP
   Destination, IP (Next Header) Protocol, and SPI to distinguish the
   correct Security Association.

   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 SPIs with different parameters, the parties may
   also send SPI_Updates.

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




Karn & Simpson                Experimental                      [Page 5]

RFC 2522                   Photuris Protocol                  March 1999


   Implementation Notes:

      The method used for SPI assignment is implementation dependent.
      The only requirement is that the SPI be unique for the IP
      Destination and IP (Next Header) Protocol.

      However, selection of a cryptographically random SPI value can
      help prevent attacks that depend on a predicatable sequence of
      values.  The implementor MUST NOT expect SPI values to have a
      particular order or range.


1.4.  LifeTimes

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

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

   2) The SPI LifeTimes of the individual SPIs that are established.
      This state may be viewed as between users and nodes.

   The SPI LifeTimes 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), any
   unexpired derived SPIs are not affected.  This is important to allow
   traffic to continue without interruption during new Photuris
   exchanges.


1.4.1.  Exchange LifeTimes

   All retained exchange state of both parties has an associated
   Exchange LifeTime (ELT), and is subject to periodic expiration.  This
   depends on the physical and logistical security of the machine, and
   is typically in the range of 10 minutes to one day (default 30
   minutes).

   In addition, during a Photuris exchange, an Exchange TimeOut (ETO)
   limits the wait for the exchange to complete.  This timeout includes
   the packet round trips, and the time for completing the
   Identification Exchange calculations.  The time is bounded by both
   the maximum amount of calculation delay expected for the processing
   power of an unknown peer, and the minimum user expectation for



Karn & Simpson                Experimental                      [Page 6]

RFC 2522                   Photuris Protocol                  March 1999


   results (default 30 seconds).

   These Exchange LifeTimes and TimeOuts are implementation dependent
   and are not disclosed in any Photuris message.  The paranoid operator
   will have a fairly short Exchange LifeTime, but it MUST NOT be less
   than twice the ETO.

   To prevent synchronization between Photuris exchanges, the
   implementation SHOULD randomly vary each Exchange LifeTime within
   twice the range of seconds that are required to calculate a new
   Exchange-Value.  For example, when the Responder uses a base ELT of
   30 minutes, and takes 10 seconds to calculate the new Exchange-Value,
   the equation might be (in milliseconds):

      1790000 + urandom(20000)

   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 previously
   calculated shared-secret can be used to rapidly generate new
   session-keys.


1.4.2.  SPI LifeTimes

   Each SPI has an associated LifeTime, specified by the SPI owner
   (receiver).  This SPI LifeTime (SPILT) is usually related to the
   speed of the link (typically 2 to 30 minutes), but it MUST NOT be
   less than thrice the ETO.

   The SPI can also be deleted by the SPI Owner using the SPI_Update.
   Once the SPI has expired or been deleted, the parties cease using the
   SPI.

   To prevent synchronization between multiple Photuris exchanges, the
   implementation SHOULD randomly vary each SPI LifeTime.  For example,
   when the Responder uses a base SPILT of 5 minutes, and 30 seconds for
   the ETO, the equation might be (in milliseconds):

      285000 + urandom(30000)

   There is no requirement that a long LifeTime be accepted by the SPI
   User.  The SPI User might never use an established SPI, or cease
   using the SPI at any time.

   When more than one unexpired SPI is available to the SPI User for the
   same function, a common implementation technique is to select the SPI



Karn & Simpson                Experimental                      [Page 7]

RFC 2522                   Photuris Protocol                  March 1999


   with the greatest remaining LifeTime.  However, selecting randomly
   among a large number of SPIs might provide some defense against
   traffic analysis.

   To prevent resurrection of deleted or expired SPIs, SPI Owners SHOULD
   remember those SPIs, but mark them as unusable until the Photuris
   exchange shared-secret used to create them also expires and purges
   the associated state.

   When the SPI Owner detects an incoming SPI that has recently expired,
   but the associated exchange state has not yet been purged, the
   implementation MAY accept the SPI.  The length of time allowed is
   highly dependent on clock drift and variable packet round trip time,
   and is therefore implementation dependent.


1.5.  Random Number Generation

   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].






















Karn & Simpson                Experimental                      [Page 8]

RFC 2522                   Photuris Protocol                  March 1999


2.  Protocol Details

   The Initiator begins a Photuris exchange under several circumstances:

   -  The Initiator has a datagram that it wishes to send with
      confidentiality, and has no current Photuris exchange state with
      the IP Destination.  This datagram is discarded, and a
      Cookie_Request is sent instead.

   -  The Initiator has received the ICMP message [RFC-1812] Destination
      Unreachable: Communication Administratively Prohibited (Type 3,
      Code 13), and has no current Photuris exchange state with the ICMP
      Source.

   -  The Initiator has received the ICMP message [RFC-2521] Security
      Failures: Bad SPI (Type 40, Code 0), that matches current Photuris
      exchange state with the ICMP Source.

   -  The Initiator has received the ICMP message [RFC-2521] Security
      Failures: Need Authentication (Type 40, Code 4), and has no
      current Photuris exchange state with the ICMP Source.

   -  The Initiator has received the ICMP message [RFC-2521] Security
      Failures: Need Authorization (Type 40, Code 5), that matches
      current Photuris exchange state with the ICMP Source.

   When the event is an ICMP message, special care MUST be taken that
   the ICMP message actually includes information that matches a
   previously sent IP datagram.  Otherwise, this could provide an
   opportunity for a clogging attack, by stimulating a new Photuris
   Exchange.


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.