[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

(IPng) Modifications to the ESP I-D (long)




I propose the following changes to the current version of the IPv6
Encapsulating Security Payload I-D [draft-ietf-ipngwg-esp-0a.txt]. I
acknowledge that the exact phrasing of the change is a matter for the editor
to decide. I provide suggested wording only to make clear the substantive
changes I am suggesting. In addition, I am open to other proposals, such as
the one suggested by Russ Housley, that would allow the use of in-band
keying with IPv6. I am sending this out now so that we have at least one
concrete proposal to discuss in Danvers.

page 4, para. 2, section 3.1 - change to read :

           A 32-bit pseudo-random value identifying the security association
      for this datagram.  If no security association has been established,
      the value of this field shall be 0x00000000. If in-band keying is
      employed, this field shall be 0x00000001. The set of SAID values
      in the range 0x00000002 through 0x000000FF are reserved for future
      use.  A security association is normally one-way.  An authenticated
      communications session between two hosts will normally have two SAIDs
      in use (one in each direction).

Reason for this change - To indicate in-band keying requires an SAID that is
not a legal pre-established value. I chose the value 1 arbitrarily and would
be open to some other value that is now reserved.

page 4, para. 4, section 3.1 - change to read :

        Senders to a multicast group may share a common SAID for all
      communications if all communications are authenticated using the same
      security configuration parameters (e.g. algorithm, key, security
      classification level, etc.).  In this case, the receiver only knows
      that the message came from a host knowing the security association
      data for the group and cannot authenticate which member of the group
      sent the datagram.  Multicast groups may also use a separate SAID for
      each sender.  In any event, the combination of Destination Address,
      optional fields within the synchronization data and the
      SAID is used to determine the correct security association data.  If
      each sender is keyed separately and asymmetric algorithms are used,
      data origin authentication is also a provided service.

Reason for this change - The presence of the optional in-band keying fields
within the synchronization data would be additional information necessary to
determine the correct security association data.

page 5, para. 5, section 3.1 - change to read :

        Each SAID value, optional fields within the synchronization data and
      the destination address imply the key(s) used to encrypt and decrypt the
      encrypted portion of the ESP payload, the sensitivity level (e.g.
      Secret, Unclassified) of the user data in the ESP payload, the
      encryption algorithm being used, the block size (if any) of the
      encryption algorithm, the authentication algorithm being used (if
      separate from the encryption algorithm), the block size (if any) of
      the authentication algorithm, and the presence/absence and size of a
      cryptographic synchronisation or initialisation vector field at the
      start of the encrypted portion of the ESP (if no such field is
      present, then the size is of course zero).

Reason for this change - same as those given in the previous callout.

page 5, para. 5, section 3.1 - change to read :

        The sending host uses the sending userid and destination host to
      select an appropriate Security Association (and hence SAID value).
      The receiving host uses the combination of SAID value, optional fields
      within the synchronization data, and originating address to distinguish
      the correct association.

Reason for this change - same as those givin in the previous two callouts.
Also, the last sentence is removed since it is redundant.

page 5, para. 6, section 3.1 - change to read :

        This field is present only for algorithms which require a
      cryptographic synchronisation field for each packet and for
      carrying in-band keying information, if present.  The value of
      this field is arbitrary.  The length of this field is variable, though
      for any given algorithm it has a particular known length.  It is
      considered to be plaintext in this document, though most users will
      not be able to make sense of its contents.  Its presence or absence
      are constant for all secure datagrams of any given SAID
      value.  The ESP specification includes this field so that the payload
      specification will be independent of the cryptographic algorithm that
      is being used by the communicating systems.  If present, the field
      contains cryptographic synchronisation data, such as a DES
      Initialisation Vector, for whichever algorithm is in use [ISO92b]
      or it contains in-band keying data. An ESP implementation will normally
      use the Security Association Identifier value for the payload being
      processed to determine whether this field is present and to determine
      the field's size and use if present.

Reason for this change - The text indicates that the synchronization data
may carry in-band keying data.

page 5, after para. 6, section 3.1 - add the following text :

   When the SAID value indicates in-band keying, the synchronization data
   field carries Key Management method specific information, In that
   case the format of the Encapsulating Security Payload is as follows :

     +--------------+---------------+----------------+--------------+
     |              Security Association Identifier (=0x00...1)     |
     +--------------+---------------+----------------+--------------+
     |Key Management|              Key Management Info              |
     |     ID       |                                               |
     +--------------+-----------------+----------------+------------+
     |               Key Management Info (variable length)          |
     +--------------+---------------+----------------+--------------+
     |                         Encrypted Data                       |
     +--------------+---------------+----------------+--------------+

  The key management ID specifies the format of the remaining data in the
  Encapsulating Security Payload. Key management IDs are allocated by the
  Internet Assigned Numbers Authority (IANA). The remaining information in the
  synchronization data is formated according to rules specific to
  the indicated Key Management protocol. Each Key Management protocol
  is defined in a separate RFC.

Reason for the change - This additional format information is necessary
to support in-band keying within the ESP. It allows the specification of
new in-band key management protocols as they are developed by only
specifying a Key Management ID and leaving the format of the remaining
information to be specified in a separate RFC.

page 7, para. 2, section 4.1 - change to read :

     The receiver strips off the cleartext IPv6 header and cleartext
   optional IPv6 payloads (if any) and discards them.  It then uses the
   combination of Destination Address, optional information within the
   synchronization data and SAID value to obtain the correct decryption
   key to use for this packet.  Then, it decrypts the ESP using the
   session key that has been established for this traffic.

Reason for this change - The presence of the optional in-band keying fields
within the synchronization data would be additional information necessary to
determine the correct decryption key.

page 8, para. 2, section 4.2 - change to read :

     The receiver processes the cleartext IPv6 header and cleartext
   optional IPv6 headers (if any) and temporarily stores pertinent
   information (e.g. source and destination addresses, Flow ID, Routing
   Header).  It then decrypts the ESP using the session key that has been
   established for this traffic, using the combination of the destination
   address, optional information within the synchronzation data and the
   packet's Security Association Identifier (SAID) to locate the correct key.

Reasons for this change - same as those given in the previous callout.

page 10, para. 4, section 7 - change to read :

     If user-to-user keying is not in use, then the algorithm in use
   should not be vulnerable to any kind of Chosen Plaintext attack.
   A Chosen Plaintext attack on DES is described in [BS93].  Use of
   user-to-user keying is one way to preclude any sort of
   Chosen Plaintext attack and to generally make cryptanalysis more
   difficult. Another is to change the session key with sufficient
   frequency that deprives the cryptoanalyst of enough plaintext/
   ciphertext pairs to carry out an effective attack.

Reasons for this change - Since user-to-user keying is only one way to
address problems arising from cryptoanalytic attacks, alternative
methods should be mentioned.

Dan Nessett
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
Unsubscribe:	unsubscribe ipng		 (as message body, not subject)
Direct all administrative requests to majordomo@sunroof.eng.sun.com


----- End Included Message -----