rfc2522.txt

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

3.0.4.  Receive Cookie_Response

   The Initiator validates the Initiator-Cookie, and the Offered-
   Schemes.

   -  When an invalid/expired Initiator-Cookie is detected, the message
      is silently discarded.

   -  When the variable length Offered-Schemes do not match the UDP
      Length, or all Offered-Schemes are obviously defective and/or
      insufficient for the purposes intended, the message is silently
      discarded; the implementation SHOULD log the occurance, and notify
      an operator as appropriate.

   -  Once a valid message has been received, later Cookie_Responses
      with matching Initiator-Cookies are also silently discarded, until
      a new Cookie_Request is sent.

   When the message is valid, an Exchange-Scheme is chosen from the list
   of Offered-Schemes.

   This Scheme-Choice may affect the next Photuris message sent.  By
   default, the next Photuris message is a Value_Request.

   Implementation Notes:

      Only the Initiator-Cookie is used to identify the exchange.  The
      Counter and Responder-Cookie will both be different from the
      Cookie_Request.

      Various proposals for extensions utilize the Scheme-Choice to
      indicate a different message sequence.  Such mechanisms are
      outside the scope of this document.



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


3.1.  Cookie_Request

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                       Initiator-Cookie                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                       Responder-Cookie                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Message    |    Counter    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Initiator-Cookie  16 bytes.  A randomized value that identifies the
                    exchange.  The value MUST NOT be zero.  See "Cookie
                    Generation" for details.

   Responder-Cookie  16 bytes.  Identifies a specific previous exchange.
                    Copied from a previous Cookie_Response.

                    When zero, no previous exchange is specified.

                    When non-zero, and the Counter is zero, contains the
                    Initiator-Cookie of a previous exchange.  The
                    specified party is requested to be the Responder in
                    this exchange, to retain previous party pairings.

                    When non-zero, and the Counter is also non-zero,
                    contains the Responder-Cookie of a previous
                    exchange.  The specified party is requested to be
                    the Responder in this exchange, to retain previous
                    party pairings.

   Message          0

   Counter          1 byte.  Indicates the number of previous exchanges.

                    When zero, the Responder-Cookie indicates the
                    Initiator of a previous exchange, or no previous
                    exchange is specified.

                    When non-zero, the Responder-Cookie indicates the
                    Responder to a previous exchange.  This value is set
                    to the Counter from the corresponding
                    Cookie_Response or from a Resource_Limit.




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


3.2.  Cookie_Response

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                       Initiator-Cookie                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                       Responder-Cookie                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Message    |    Counter    |  Offered-Schemes ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Initiator-Cookie  16 bytes.  Copied from the Cookie_Request.

   Responder-Cookie  16 bytes.  A randomized value that identifies the
                    exchange.  The value MUST NOT be zero.  See "Cookie
                    Generation" for details.

   Message          1

   Counter          1 byte.  Indicates the number of the current
                    exchange.  Must be greater than zero.

   Offered-Schemes  4 or more bytes.  A list of one or more Exchange-
                    Schemes supported by the Responder, ordered from
                    most to least preferable.  See the "Basic Exchange-
                    Schemes" for details.

                    Only one Scheme (#2) is required to be supported,
                    and SHOULD be present in every Offered-Schemes list.

                    More than one of each kind of Scheme may be offered,
                    but each is distinguished by its Size.  The end of
                    the list is indicated by the UDP Length.














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


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 will 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 use a cryptographic hashing function
   (such as MD5).

   An incoming cookie can be verified at any time by regenerating it
   locally from values contained in the incoming datagram and the local
   secret random value.


3.3.1.  Initiator Cookie

   The Initiator secret value that affects its 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.

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

   It is recommended that the cookie be calculated over the secret
   value, the IP Source and Destination addresses, and the UDP Source
   and Destination ports.








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


   Implementation Notes:

      Although the recommendation includes the UDP Source port, this is
      very implementation specific.  For example, it might not be
      included when the value is constant.

      However, it is important that the implementation protect mutually
      suspicious users of the same machine from generating the same
      cookie.


3.3.2.  Responder Cookie

   The Responder secret value that affects its cookies MAY remain the
   same for many different Initiators.  However, this secret SHOULD be
   changed periodically to limit the time for use of its cookies
   (typically each 60 seconds).

   The Responder-Cookie SHOULD include the Initiator-Cookie.  The
   Responder-Cookie MUST include the Counter (that is returned in the
   Cookie_Response).  This provides improved synchronization and
   protection against replay attacks.

   It is recommended that the cookie be calculated over the secret
   value, the IP Source and Destination addresses, its own UDP
   Destination port, the Counter, the Initiator-Cookie, and the
   currently Offered-Schemes.

   The cookie is not cached per Initiator to avoid saving state during
   the initial Cookie Exchange.  On receipt of a Value_Request
   (described later), the Responder regenerates its cookie for
   validation.

   Once the Value_Response is sent (also described later), both
   Initiator and Responder cookies are cached to identify the exchange.

   Implementation Notes:

      Although the recommendation does not include the UDP Source port,
      this is very implementation specific.  It might be successfully
      included in some variants.

      However, it is important that the UDP Source port not be included
      when matching existing Photuris exchanges for determining the
      appropriate Counter.

      The recommendation includes the Offered-Schemes to detect a
      dynamic change of scheme value between the Cookie_Response and



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


      Value_Response.

      Some mechanism MAY be needed to detect a dynamic change of pre-
      calculated Responder Exchange-Value between the Value_Response and
      Identity_Response.  For example, change the secret value to render
      the cookie invalid, or explicitly mark the Photuris exchange state
      as expired.


4.  Value Exchange

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

             [generate shared-secret from exchanged values]



4.0.1.  Send Value_Request

   The Initiator generates an appropriate Exchange-Value for the
   Scheme-Choice.  This Exchange-Value may be pre-calculated and used
   for multiple Responders.

   The IP Destination for the Responder is examined, and the attributes
   available between the parties are listed in the Offered-Attributes.

   The Initiator also starts a retransmission timer.  If no valid
   Value_Response arrives within the time limit, the same Value_Request
   is retransmitted for the remaining number of Retransmissions.

   When Retransmissions have been exceeded, if a Bad_Cookie or
   Resource_Limit message has been received during the exchange, the
   Initiator SHOULD begin the Photuris exchange again by sending a new
   Cookie_Request.









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


4.0.2.  Receive Value_Request

   The Responder validates the Responder-Cookie, the Counter, the
   Scheme-Choice, the Exchange-Value, and the Offered-Attributes.

   -  When an invalid/expired Responder-Cookie is detected, a Bad_Cookie
      message is sent.

   -  When too many SPI values are already in use for this particular
      peer, or too many concurrent exchanges are in progress, or some
      other resource limit is reached, a Resource_Limit message is sent.

   -  When an invalid Scheme-Choice is detected, or the Exchange-Value
      is obviously defective, or the variable length Offered-Attributes
      do not match the UDP Length, the message is silently discarded;
      the implementation SHOULD log the occurance, and notify an
      operator as appropriate.

   When the message is valid, the Responder sets its Exchange timer to
   the Exchange TimeOut, and returns a Value_Response.

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


4.0.3.  Send Value_Response

   The Responder generates an appropriate Exchange-Value for the
   Scheme-Choice.  This Exchange-Value may be pre-calculated and used
   for multiple Initiators.

   The IP Source for the Initiator is examined, and the attributes
   available between the parties are listed in the Offered-Attributes.

   Implementation Notes:

      At this time, the Responder begins calculation of the shared-
      secret.  Calculation of the shared-secret is executed in parallel
      to minimize delay.