Subject: Updated DISCUSS on IPv6 Node Requirements

From: [email-masked]
Date: Thu, 27 May 2004 18:57:50 +0300

Hi all, 

Russ Housley has updated his DISCUSS to be the following (Russ see question
in on point 2 below):

1) I had many, many comments on section 8.3.  My comments were longer
  than the section itself.  Given that, I decided to provide replacement
  text instead of the comments.  The basis of most of these changes is
  alignment with draft-ietf-ipsec-esp-ah-algorithms-01, which is has just
  been forwarded to the IESG by the IPsec WG.  Here is my proposed text:

    Current IPsec RFCs specify the support of transforms and algorithms
    for use with AH and ESP: NULL encryption, DES-CBC, HMAC-SHA-1-96,
    and HMAC-MD5-96.  However, "Cryptographic Algorithm Implementation
    Requirements For ESP And AH" [CRYPTREQ] contains the  current set
    of mandatory to implement algorithms for ESP and AH.  It also
    specifies algorithms that should be implemented because they
    are likely to be promoted to mandatory at some future time.  IPv6
    nodes SHOULD conform to the requirements in [CRYPTREQ] as well as
    the requirements specified below.

    Since ESP encryption and authentication are both optional, support for
    the NULL encryption algorithm [RFC-2410] and the NULL authentication
    algorithm [RFC-2406] MUST be provided to maintain consistency with
    the way these services are negotiated. However, while authentication
    and encryption can each be NULL, they MUST NOT both be NULL.  The
    NULL encryption algorithm is also useful for debugging.

    The DES-CBC encryption algorithm [RFC-2405] SHOULD NOT be supported
    within ESP.  Security issues related to the use of DES are discussed
    in [DESDIFF], [DESINT], [DESCRACK].  DES-CBC is still listed as
    required by the existing IPsec RFCs, but updates to these RFCs will
    be published soon.  DES provides 56 bits of protection, which is no
    longer considered sufficient.

    The use of HMAC-SHA-1-96 algorithm [RFC-2404] within AH and ESP MUST
    be supported.  The use of HMAC-MD5-96 algorithm [RFC-2403] within AH
    and ESP MAY also be supported.

    The 3DES-CBC encryption algorithm [RFC-2451] does not suffer from the
    same security issues as DES-CBC, and the 3DES-CBC algorithm within
    ESP MUST MUST be supported to ensure interoperability.
   
    The AES-128-CBC algorithm [RFC-3602] MUST also be supported within
    ESP.  AES-128 is expected to be a widely available, secure, and 
    efficient algorithm.  While AES-128-CBC is not required by the
    current IPsec RFCs, it is expected to become required in the future.

-> Resolution: I think that the text is fine, I will update the document
   accordingly

-> Question to Russ - how to handle IKEv1 vs. IKEv2?  What would be a 
   reasonble reference here?

2) In section 8.4, one of my previous comments was rejected without
  explanation.  I said:  "I am uncomfortable with support for IKE being
  a MAY.  It ought to be a SHOULD."  While I understand that an 
  Informational document is an inappropriate vehicle to impose this
  requirement, the deployment benefits can be pointed out.
  
  I believe that the 1st paragraph of section 8.4 needs further explanation.
  A security association is  identified by a triple consisting of a Security
  Parameter Index (SPI), an IP Destination Address, and a security protocol
  identifier (either AH or ESP).  So, manual key management involves a
  bit more than inserting the same cryptographic key in communicating peers.
  This document should not specify how that is done, but it should indicate
  that it needs to be done.

-> Resolution: I could update the text from MAY to a SHOULD, does the WG
   feel this is reasonable?  

3) Comment:

  The first paragraph of the Introduction says: "... all IPv6 nodes can be
  expected to implement the mandatory requirements listed in this document."
  How can this be true unless it is published on the Standards Track or as
  a BCP?  Perhaps it out to say that it summarizes the requirements from
  other published Standards Track documents to put them all in one place.

  The second paragraph of the Introduction does not sound like something
  that ought to be said in an Informational RFC.

-> I will prepare text to fix this.

4) Section 4.5 requires all hosts to support IPv6 Stateless Address
  Autoconfiguration as defined in RFC 2462.  It ought so say that support
  for static addresses is okay too.

-> Resolution: this is reasonable, I will update the text.

What I need from the WG is sign-off on point 2 above.  I will submit the
rest of the text for review either tonight or first thing tomorrow AM.

John

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Russ Housley <[email-masked]>
Date: Thu, 27 May 2004 13:16:09 -0400

At 11:57 AM 5/27/2004, [email-masked] wrote:
>   [snip]

IKEv2 is still not final.  It should be done in a month or so if you want 
to have your document blocked on the normative reference.

>-> Resolution: I could update the text from MAY to a SHOULD, does the WG

Steve Bellovin and I have been asked to provide text.  Working on it ...

Russ

---

From: Jari Arkko <[email-masked]>
Date: Fri, 28 May 2004 15:44:29 +0300

Hi John and Russ,

> -> Resolution: I think that the text is fine, I will update the document

I think the text from Russ is good!

>   that it needs to be done.

Ok.

> -> Resolution: I could update the text from MAY to a SHOULD, does the WG

I am sympathetic to having mandatory security
requirements. And I also agree that key management
is a practical necessity with IPsec.

(A bit about the background why the requirement was
originally a MAY. One question is whether there's
some IPv6 function that specifically requires IKE.
I can't recall any, and there's even been some
migration to non-IPsec solutions in the recent
times (e.g. SEND). So a requirement to support IKE is
more of a function to the users of the stack than
a technical need from IPv6 point of view. But I may
have easily missed some RFC that requires it.)

In any case, I believe the key issue is what you
Russ said below in another context: "Perhaps it
ought to say that it summarizes the requirements
from other published Standards Track documents to put
them all in one place." I've been trying to track down
this requirement from the other RFCs, and the closest
thing that I got is in RFC 2401, which says " All IPv6
systems MUST comply with all requirements of the Security
Architecture document. ...(snip)... This document requires
support for both manual and automatic distribution of keys.
It specifies a specific public-key based approach ...".
I'm a bit confused by the "required" and then "an approach" --
are you thinking that these map to a SHOULD?

Nevertheless, we need to move this document along. I'm
OK with the SHOULD.

>   other published Standards Track documents to put them all in one place.

Yes. Ok.

> -> Resolution: this is reasonable, I will update the text.

Ok.

--Jari