Final editing instructions for ikev2 document

["Theodore Ts'o" <tytso@mit.edu>]

Hi Charlie,

My apologies for the delaying in getting this document to you.  I had a
loss of state problem myself --- a literal hard drive accident that
caused me to lose all recent mail and other files on my hard drive since
my last backup.  (Which unfortunately was far too long ago....)

Anyway, I believe these are the final changes that need to be made to
the IKEv2 document based on discussions on the IPSEC mailing list after
wg last call.  After these changees are made and a new I-D submitted to
the secretariat, we should be ready to hand this off to the AD's for
progressing to IETF last call.  (And the angels started singing
Hallelujah....)

						- Ted


1)  EAP non-kg security considerations

In section 2.16, in the second to last paragraph, which currently
reads:

    For EAP methods that create a shared key as a side effect of
    authentication, that shared key MUST be used by both the Initiator
    and Responder to generate an AUTH payload using the syntax for shared
    secrets specified in section 2.15. The shared key generated during an
    IKE exchange MUST NOT be used for any other purpose. For EAP methods
    that do not establish a shared key, there will be no AUTH payloads in
    the final messages.

Delete the last sentence, ("For EAP methods that do not establish...")
and add the following paragraph:

EAP methods that do not establish a shared key SHOULD NOT be used, as
they are subject a number of man-in-the-middle attacks if these EAP
methods are used in other protocols that do not use a
server-authenticated tunnel.  Please see the Security Considerations
section for more details.  If EAP methods that do not generate a
shared key are used, there will be no AUTH payloads in the final
messages.

In the security considerations section, replace the last paragraph
with the following text:

When using an EAP authentication method that does not generate a shared
key for protecting a subsequent AUTH payload, certain man-in-the-middle
and server impersonation attacks are possible.[EAPMITM]  These
vulnerabilities occur when EAP is also used in protocols which are not
protected within a secure tunnel.  Since EAP is a general-purpose
authentication protocol, which is often used to provide single-signon
facilities, a deployed IPSEC solution which relies on an EAP
authentication method that does not generate a shared key (also known as
a non-key-generating EAP method) can become compromised due to the
deployment of an entirely unrelated application that also happens to use
that same non-key-generating EAP method, but in an unprotected fashion.
Note that this vulnerability is not limited to just EAP, but can occur
in other scenarios where an authenticatoin infrastructure is reused.
For example, if the EAP mechanism used by IKEv2 utilizes a token
authenticator, and the enterprise deploys a non-encrypted web form which
accepts the input from the token authenticator, a man-in-the-middle
attacker could impersonate the web server, intercept the token
authentication exchange, and use it to initiate an IKEv2 connection.
For this reason, use of non-key-generating EAP methods SHOULD be avoided
where possible.  Where they are used, it is extremely important that all
usages of these EAP methods SHOULD utilize a protected tunnel, where the
initiator validates the responder's certificate before initiating the
EAP exchange.  Implementors SHOULD describe the vulnerabilities of using
non-key-generating EAP methods in the documentation of their
implementations so that the administrators deploying IPSEC solutions are
aware of these dangers.

Add the following reference:

[EAPMITM]   N. Asokan, Valtteri Nierni, and Kaisa Nyberg,
         "Man-in-the-Middle in Tunneled Authentication Protocols",
         http://eprint.iacr.org/2002/163, November 11, 2002.

----------------------------------------------------

2.  Rekeying clarifications

 From David Black's note of August 20, 2003:

Subject: RE: The remaining IKEv2 issues - #64
To: Charlie_Kaufman@notesdev.ibm.com

Charlie,

As part of this (unless I missed it), please add sentences
to make the following points:

- IKEv2 deliberately allows parallel SAs with the same traffic
         selectors between common endpoints.  One of the purposes of
         this is to support traffic QoS differences among the SAs;
         see Section 4.1 of RFC 2983 (informative reference).
- Hence unlike IKEv1, given two endpoints, traffic selectors need
         not uniquely identify an SA between those endpoints.
- Therefore the IKEv1 rekeying heuristic (use of same traffic
         selectors as an existing SA indicates rekeying, so existing
         SA should be deleted shortly after new one is up) SHOULD NOT
         be used, as it will result in unintended SA deletion.

This may help avoid some surprises arising from implementation code
reuse.

Also, [RFC2401bis] needs to be added to the list of normative references.

--------------------------------------------

3.  ECN clarifications:

Replace the text of section 2.24 with the following, per suggested
the rewording from David Black:

When IPsec tunnels behave as originally specified in [RFC 2401], ECN usage
is not appropriate for the outer IP headers because tunnel decapsulation
processing discards ECN congestion indications to the detriment of the
network.  ECN support for IPsec tunnels for IKEv1-based IPsec requires
multiple  operating modes and negotiation (see [RFC 3168]).  IKEv2
simplifies this situation requiring that ECN be usable in the outer IP
headers of all tunnel-mode IPsec SAs created by IKEv2.  Specifically,
tunnel encapsulators and decapsulators for all tunnel-mode Security
Associations (SAs) created by IKEv2 MUST support the ECN full-functionality
option for tunnels specified in [RFC3168] and MUST implement the tunnel
encapsulation and decapsulation processing specified in [RFC2401bis] to
prevent discarding of ECN congestion indications.

NB: [RFC 2401] reference is informative, [RFC 3168] and [2401bis] are
normative.

----------------------------------

4.  Nat traversal clarification.

In section 2.23, Nat Traversal reads:

       There are cases where a NAT box decides to remove mappings that
       are still alive (for example, the keepalive interval is too long,
       or the NAT box is rebooted). To recover in these cases, hosts that
       are not behind a NAT SHOULD send all packets (including retried
       packets) to the IP address and port from the last valid
       authenticated packet from the other end. A host not behind a NAT
                                                       ^^^ typo, delete
       SHOULD NOT do this because it opens a DoS attack possibility. Any
       authenticated IKE packet or any authenticated IKE encapsulated ESP
                                                     ^^^ typo, 
						replace with UDP
       packet can be used to detect that the IP address or the port has
       changed.

--------------------------------------

5.  Friends don't let friends use ASN.1

In section 3.6, certificate payload, the description of the ASN.1 for
a certificate bundle is ambiguous.

       Hash and URL of PKIX bundle (13) contains a 20 octet SHA-1 hash of
       a PKIX certificate bundle followed by a variable length URL the
       resolves to the BER encoded certificate bundle itself. The bundle
       is a BER encoded SEQUENCE of certificates and CRLs.

Use the following ASN.1 definition suggested by Nicholas Williams

    DEFINITION EXPLICIT TAGS ::=
    BEGIN

    IMPORTS Certificate, CertificateList FROM PKIX1Explicit93

    CertificateOrCRL ::= CHOICE {
        cert [0] Certificate,
        crl  [1] CertificateList
    }

    CertificateBundle ::= SEQUENCE OF CertificateOrCRL
    END