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

(IPng) Suggested modifications to the AH I-D (long)

I propose the following changes to the current version of the IPv6
Authentication Header I-D [draft-ietf-ipngwg-sec-00.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 3, 1st para., section 2 - modify to read -

     'Key management is an important part of the IPv6 security
   architecture. IPv6 tries to decouple the key management mechanisms
   from the security protocol mechanisms.  The only coupling between
   the key management protocol and the security protocol is with the
   Security Association Identifier (SAID) and with optional fields within
   the authentication data, which are described in more detail below.
   This decoupling permits several different key management mechanisms
   to be used.  More importantly, it permits the key management protocol
   to be changed or corrected without unduly impacting the security
   protocol implementations.'

Reasons for this change - to support in-band keying, the coupling between
the security protocol and the key management protocol could also depend
on data carried by the packet in the authentication field.

page 4, para. 1, section titled "Security Association Identifier (SAID) - 
modify 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).  The combination of SAID value, optional
      fields within the authentication data, and destination address uniquely
      identifies the security association.  The destination address may, of
      course, be a multicast group address.

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 6, para. 1, section 4 - modify the first sentence to read :

        When not carrying in-band data, the authentication data is usually
   calculated using a message digest algorithm (e.g. MD5) either encrypting
   that message digest or keying the message digest directly.

Reason for this change - the conditional at the beginning of the sentence
clarifies that the authentication data field may carry additional key
management specific information.

page 7, after para. 6, section 4 - insert the following text.

  'When the SAID value indicates in-band keying, the format of the
   authentication header is as follows :

     | Next Payload | Length          |  RESERVED                   |
     |              Security Association Identifier (=0x00...1)     |
     |Key Management|              Key Management Info              |
     |     ID       |                                               |
     |             Key Management Info (variable length)            |

  The key management ID specifies the format of the remaining data in the
  Authentication Header. Key management IDs are allocated by the Internet
  Assigned Numbers Authority (IANA). The remaining information in the
  authentication data field 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 AH. 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. 1, section 5 - modify to read 

     Implementations that claim conformance or compliance with this
   specification MUST fully implement the option described here,
   and MUST support the use of keyed MD5 as described in Appendix A of
   this document.  Either host-to-host manual key distribution or user-
   to-user manual key distribution MAY be used with this option.
   Support for other authentication algorithms is not mandatory to
   comply or conform with this specification.  Implementors
   should consult the most recent version of the IAB Official Standards
   document for further guidance on the status of this document.
Reason for the change - Requiring all implementations to support user-to-user
key distribution is onerous and unnecessary. Threats against encrypted
communications based on widely know cryptanalytic techniques, such as
differential or linear cryptanalysis can be thwarted by judicious rekeying
of the communications key variables. User-to-user key distribution is
another way to achieve protection in this regard, but is difficult to
implement for some key management schemes.

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