[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Final editing instructions for ikev2 document
Folks,
Apologies if you've addressed this elsewhere, but with regard to the
IKE spec, how do you want to handle the new issues brought up as we
discuss 2401bis?
- Issue 86 --> Mobility Header Type as selector
- Issue DD --> anti-replay notification support
- Issue 68 --> VPNs with overlapping IP address ranges --
add some form of VPN subscriber ID as an IKE payload value
- Issue ?? --> Add ICMP message type as selector (This will be
part of the ICMP handling issue that we're in the process of
writing.)
Do these need to get resolved before the IKE RFC goes to IETF last call?
Thank you,
Karen
>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