rfc2522.txt

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

      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 retransmission
      timeouts typically exceed calculation time.





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


4.0.4.  Receive Value_Response

   The Initiator validates the pair of Cookies, the Exchange-Value, and
   the Offered-Attributes.

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

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

   -  Once a valid message has been received, later Value_Responses with
      both matching cookies are also silently discarded, until a new
      Cookie_Request is sent.

   When the message is valid, the Initiator begins its parallel
   computation of the shared-secret.

   When the Initiator completes computation, it sends an
   Identity_Request to the Responder.





























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


4.1.  Value_Request

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                       Initiator-Cookie                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                       Responder-Cookie                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Message    |    Counter    |         Scheme-Choice         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                   Initiator-Exchange-Value                    ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Initiator-Offered-Attributes ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-


   Initiator-Cookie  16 bytes.  Copied from the Cookie_Response.

   Responder-Cookie  16 bytes.  Copied from the Cookie_Response.

   Message          2

   Counter          1 byte.  Copied from the Cookie_Response.

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

                    Only the Scheme is specified; the Size will match
                    the Initiator-Exchange-Value, and the Value(s) are
                    implicit.

   Initiator-Exchange-Value
                    Variable Precision Integer.  Provided by the
                    Initiator for calculating a shared-secret between
                    the parties.  The Value format is indicated by the
                    Scheme-Choice.

                    The field may be any integral number of bytes 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.




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


   Initiator-Offered-Attributes
                    4 or more bytes.  A list of Security Parameter
                    attributes supported by the Initiator.

                    The contents and usage of this list are further
                    described in "Offered Attributes List".  The end of
                    the list is indicated by the UDP Length.



4.2.  Value_Response

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


   Initiator-Cookie  16 bytes.  Copied from the Value_Request.

   Responder-Cookie  16 bytes.  Copied from the Value_Request.

   Message          3

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

   Responder-Exchange-Value
                    Variable Precision Integer.  Provided by the
                    Responder for calculating a shared-secret between
                    the parties.  The Value format is indicated by the
                    current Scheme-Choice specified in the
                    Value_Request.

                    The field may be any integral number of bytes in



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


                    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
                    4 or more bytes.  A list of Security Parameter
                    attributes supported by the Responder.

                    The contents and usage of this list are further
                    described in "Offered Attributes List".  The end of
                    the list is indicated by the UDP Length.



4.3.  Offered Attribute List

   This list includes those attributes supported by the party that are
   available to the other party.  The attribute formats are specified in
   the "Basic Attributes".

   The list is composed of two or three sections: Identification-
   Attributes, Authentication-Attributes, and (optional) Encapsulation-
   Attributes.  Within each section, the attributes are ordered from
   most to least preferable.

   The first section of the list includes methods of identification.  An
   Identity-Choice is selected from this list.

   The second section of the list begins with "AH-Attributes" (#1).  It
   includes methods of authentication, and other operational types.

   The third section of the list begins with "ESP-Attributes" (#2).  It
   includes methods of authentication, compression, encryption, and
   other operational types.  When no Encapsulation-Attributes are
   offered, the "ESP-Attributes" attribute itself is omitted from the
   list.

   Attribute-Choices are selected from the latter two sections of the
   list.

   Support is required for the "MD5-IPMAC" (#5) attribute for both
   "Symmetric Identification" and "Authentication" and they SHOULD be
   present in every Offered-Attributes list.







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


   Implementation Notes:

      For example,

         "MD5-IPMAC" (Symmetric Identification),
         "AH-Attributes",
         "MD5-IPMAC" (Authentication).

      Since the offer is made by the prospective SPI User (sender),
      order of preference likely reflects the capabilities and
      engineering tradeoffs of a particular implementation.

      However, the critical processing bottlenecks are frequently in the
      receiver.  The SPI Owner (receiver) may express its needs by
      choosing a less preferable attribute.

      The order may also be affected by operational policy and requested
      services for an application.  Such considerations are outside the
      scope of this document.

      The list may be divided into additional sections.  These sections
      will always follow the ESP-Attributes section, and are
      indistinguishable from unrecognized attributes.

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
























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


5.  Identification Exchange

   Initiator                            Responder
   =========                            =========
   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]

   The exchange of messages is ordered, although the formats and
   meanings of the messages are identical in each direction.  The
   messages are easily distinguished by the parties themselves, by
   examining the Message and Identification fields.

   Implementation Notes:

      The amount of time for the calculation may be dependent on the
      value of particular bits in secret values used in generating the
      shared-secret or identity verification.  To prevent analysis of
      these secret bits by recording the time for calculation, sending
      of the Identity_Messages SHOULD be delayed until the time expected
      for the longest calculation.  This will be different for different
      processor speeds, different algorithms, and different length
      variables.  Therefore, the method for estimating time is
      implementation dependent.

      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.







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


5.0.1.  Send Identity_Request

   The Initiator chooses an appropriate Identification, the SPI and
   SPILT, a set of Attributes for the SPI, calculates the Verification,
   and masks the message using the Privacy-Method indicated by the
   current Scheme-Choice.

   The Initiator also starts a retransmission timer.  If no valid
   Identity