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

(IPng) Proposed modifications to IPv6 Security Architecture I-D (long)


I propose the following changes to the current version of the IPv6 Security
Architecture I-D [draft-ietf-ipngwg-sec-00.txt]. At those places where text
is to be changed (as opposed to being simply deleted), I provide a suggested
wording. Of course, 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.

Page 6, first para., section 4 - delete the text "IPv6 is not
   intended to support so-called "in-band" key management, where the key
   management data is carried in a distinct IPv6 header.  Instead it will
   primarily use so-called "out-of-band" key management, where the key
   management data will be carried by an upper layer protocol such as UDP
   or TCP on some specific port number.  This permits clear decoupling of
   the key management mechanism from the other security mechanisms, and
   thereby permits one to substitute new and improved key management
   methods without having to modify the implementations of the other
   security mechanisms.  This is clearly wise given the long history of
   subtle flaws in published key management protocols. [NS78, NS81] What
   follows in this section is a brief discussion of a few alternative
   approaches to key management."

Reasons for this change - There is no significant justification for
   prohibiting the use of in-band key management. This text was added after
   debate began on whether in-band key management should be allowed and
   before any resolution of that question.

page 6-7, para. 2, section 4.3 - modify the text : 'When host-to-host
   keying is used and mutually suspicious users
   exist, it is possible for user A to determine the host-to-host key via
   well known methods, such as a Chosen Plaintext attack.  Once user A
   has improperly obtained the key in use, user A can then either read
   user B's encrypted traffic or forge traffic from user B.  When
   user-to-user keying is used, this kind of attack from one user onto
   another user's traffic is not possible.  Hence, support for
   user-to-user keying must be present in all IPv6 implementations, as is
   described in the "IPv6 Key Management Requirements" section below.'

   to read 

  'When host-to-host keying is used and mutually suspicious users
   exist, it is theoretcially possible for user A to determine the host-to-host    key via well known methods, such as a Known or Chosen Plaintext attack.
   These methods require a very large amount of plaintext/ciphertext pairs,
   the best method known in the public literature requiring 2^43 such
   data pairs. Conservatively, one may not feel comfortable using the same
   key to encrypt more than around 2^32 plaintexts. If user A
   has improperly obtained the key in use, user A can then either read user
   B's encrypted traffic or forge traffic from user B. This threat may be
   thwarted by either changing the encrypting key well before the required
   amount of text has been encrypted or by using user-to-user keying. Hence,
   support for user-to-user keying may be present in an IPv6 implementation,
   as is described in the "IPv6 Key Management Requirements" section below.'

Reasons for this change - User-to-user keying may be useful in some situations,
   but given the state-of-the-art in cryptanalysis, more efficient and
   convenient methods exist for addressing the rationale for it given in
   the existing I-D. Rekeying the communications key well before the
   amount of ciphertext generated approaches the necessary volume is an
   attractive alternative. Requiring IPv6 implementations to support
   user-to-user keying is onerous and unnecessary.

page 8, 2nd para., section 4.5 - - modify the text : 'All IPv6 implementations
   MUST support manual key management.  All
   IPv6 implementations SHOULD support an Internet standard key
   management protocol once the latter is defined.  All IPv6
   implementations MUST permit the configuration and use of user-to-user
   keying for traffic originating at that system and MAY additionally
   permit the configuration of host-to-host keying for traffic
   originating at that system as an added feature to make manual key
   distribution easier and give the system administrator more
   flexibility.'

   to read

   'All IPv6 implementations MUST support manual key management.  All
   IPv6 implementations SHOULD support an Internet standard key
   management protocol once the latter is defined.  All IPv6
   implementations MAY permit the configuration and use of user-to-user
   keying for traffic originating at that system and MAY additionally
   permit the configuration of host-to-host keying for traffic
   originating at that system as an added feature to make manual key
   distribution easier and give the system administrator more
   flexibility.'

Reasons for this change - see reasons given above.

Regards,

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