--- 1/draft-ietf-ipsecme-ikev2-null-auth-05.txt 2015-04-20 09:14:55.000154748 -0700 +++ 2/draft-ietf-ipsecme-ikev2-null-auth-06.txt 2015-04-20 09:14:55.028155430 -0700 @@ -1,19 +1,19 @@ Network Working Group V. Smyslov Internet-Draft ELVIS-PLUS -Intended status: Standards Track P. Wouters -Expires: September 27, 2015 Red Hat - March 26, 2015 +Updates: 4301 (if approved) P. Wouters +Intended status: Standards Track Red Hat +Expires: October 22, 2015 April 20, 2015 The NULL Authentication Method in IKEv2 Protocol - draft-ietf-ipsecme-ikev2-null-auth-05 + draft-ietf-ipsecme-ikev2-null-auth-06 Abstract This document specifies the NULL Authentication method and the ID_NULL Identification Payload ID Type for the IKEv2 Protocol. This allows two IKE peers to establish single-side authenticated or mutual unauthenticated IKE sessions for those use cases where a peer is unwilling or unable to authenticate or identify itself. This ensures IKEv2 can be used for Opportunistic Security (also known as Opportunistic Encryption) to defend against Pervasive Monitoring @@ -27,21 +27,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 27, 2015. + This Internet-Draft will expire on October 22, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -64,21 +64,22 @@ 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 3.1. Audit trail and peer identification . . . . . . . . . . . 8 3.2. Resource management and robustness . . . . . . . . . . . . 8 3.3. IKE configuration selection . . . . . . . . . . . . . . . 9 3.4. Networking topology changes . . . . . . . . . . . . . . . 9 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 6.2. Informative References . . . . . . . . . . . . . . . . . . 12 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 + Appendix A. Update of PAD processing in RFC4301 . . . . . . . . . 13 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction The Internet Key Exchange Protocol version 2 (IKEv2), specified in [RFC7296], provides a way for two parties to perform an authenticated key exchange. While the authentication methods used by the peers can be different, there is no method for one or both parties to remain unauthenticated and anonymous. This document extends the authentication methods to support unauthenticated and anonymous IKE sessions. @@ -102,24 +103,24 @@ o Two peers without any trust relationship wish to defend against widespread pervasive monitoring attacks as described in [RFC7258]. Without a trust relationship, the peers cannot authenticate each other. Opportunistic Security [RFC7435] states that unauthenticated encrypted communication is preferred over cleartext communication. The peers want to use IKE to setup an unauthenticated encrypted connection, that gives them protection against pervasive monitoring attacks. An attacker that is able and willing to send packets can still launch a Man-in-the-Middle - attack to obtain access to the decrypted communication. This case - uses a fully unauthenticated key exchange. + attack to obtain a copy of the unencrypted communication. This + case uses a fully unauthenticated key exchange. - To meet these needs this document introduces the NULL Authentication + To meet these needs, this document introduces the NULL Authentication method, and the ID_NULL ID type. This allows an IKE peer to explicitly indicate that it is unwilling or unable to certify its identity. 1.1. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. @@ -139,26 +140,27 @@ 2.1. Authentication Payload NULL Authentication still requires a properly formed AUTH payload to be present in the IKE_AUTH exchange messages, as the AUTH payload cryptographically links the IKE_SA_INIT exchange messages with the other messages sent over this IKE SA. When using NULL Authentication, the content of the AUTH payload is computed using the syntax of pre-shared secret authentication, - described in Section 2.15 of [RFC7296]. The values SK_pi and SK_pr - are used as shared secrets for the content of the AUTH payloads - generated by the initiator and the responder respectively. Note that - this is identical to how the content of the two last AUTH payloads is - generated for the non-key-generating EAP methods (see Section 2.16 of - [RFC7296] for details). + described in Section 2.15 of [RFC7296]. The value of SK_pi for the + initiator and SK_pr for the responder is used as the shared secret + for the content of the AUTH payload. Implementers should note this + means that authentication keys used by the two peers are different in + each direction. This is identical to how the content of the two last + AUTH payloads is generated for the non-key-generating EAP methods + (see Section 2.16 of [RFC7296] for details). The IKEv2 Authentication Method value for NULL Authentication is 13. 2.2. Identification Payload When a remote peer is not authenticated, any ID presented in the Identification Data field of the ID payload cannot be validated. To avoid the need of sending a bogus ID Type with placeholder data, this specification defines a new ID Type, ID_NULL. The Identification Data field of the ID payload for this ID Type MUST be empty. @@ -203,47 +205,48 @@ Implementations should weigh the resource consumption of sending Liveness Checks against the memory usage of possible orphaned IKE SAs. Implementations may choose to handle situations with thousands of unauthenticated IKE SAs differently from situations with very few such SAs. 2.4. Interaction with Peer Authorization Database (PAD) Section 4.4.3 of [RFC4301] defines the Peer Authorization Database (PAD), which provides the link between Security Policy Database (SPD) - and the IKEv2. The PAD contains an ordered list of records, with + and the IKEv2. The PAD contains an ordered list of records with peers' identities along with corresponding authentication data and Child SA authorization data. When the IKE SA is being established the PAD is consulted to determine how the peer should be authenticated and what Child SAs it is authorized to create. When using NULL Authentication, the peer identity is not authenticated and cannot be trusted. If ID_NULL is used with NULL Authentication, there is no ID at all. The processing of PAD - described in Section 4.4.3.4 of [RFC4301] must be updated. + described in Section 4.4.3 of [RFC4301] is updated for NULL + Authentication as follows. - NULL authentication needs to be added as one of supported - authentication methods. This method does not have any authentication - data. To add support for ID_NULL, it needs to be included into the - list of ID types, specified in Section 4.4.3.1 of [RFC4301]. The - matching rule for ID_NULL consists only of whether this type is used, - i.e. no actual ID matching is done, as ID_NULL contains no identity - data. + NULL authentication is added as one of supported authentication + methods. This method does not have any authentication data. ID_NULL + is included into the list of allowed ID types. The matching rule for + ID_NULL consists only of whether this type is used, i.e. no actual ID + matching is done, as ID_NULL contains no identity data. - Section 4.4.3.3 of the [RFC4301] describes how the IKE ID is matched - against the SPD entries. When using the NULL authentication method - those matching rules MUST include matching of a new flag in the SPD - entry specifying whether unauthenticated users are allowed to use - that entry. I.e. each SPD entry needs to be augmented to have a flag - specifying whether it can be used with NULL authentication or not, - and only those rules that explictly have that flag turned on can be - used with unauthenticated connections. + When using the NULL authentication method those matching rules MUST + include matching of a new flag in the SPD entry specifying whether + unauthenticated users are allowed to use that entry. I.e. each SPD + entry needs to be augmented to have a flag specifying whether it can + be used with NULL authentication or not, and only those rules that + explicitly have that flag turned on can be used with unauthenticated + connections. + + The specific updates of text in Section 4.4.3 of [RFC4301] are listed + in Appendix A. 2.5. Traffic Selectors Traffic Selectors and narrowing allow two IKE peers to mutually agree on a traffic range for an IPsec SA. An unauthenticated peer must not be allowed to use this mechanism to steal traffic that an IKE peer intended to be for another host. This is especially problematic when supporting anonymous IKE peers behind NAT, as such IKE peers build an IPsec SA using their pre-NAT IP address that are different from the source IP of their IKE packets. A rogue IKE peer could use malicious @@ -252,23 +255,22 @@ all anonymous IKE peers from each other and itself and only allow it access to itself and possibly its intended network ranges. One method to achieve this is to always assign internal IP addresses to unauthenticated IKE clients, as described in Section 2.19 of [RFC7296]. Implementations may also use other techniques, such as internal NAT and connection tracking. Implementations MAY force unauthenticated IKE peers to single host- to-host IPsec SAs. When using IPv6 this is not always possible, so - in this case implementations MUST be able to assign full /64 address - block to the peer as described in [RFC5739], even if it is not - authenticated. + implementations MUST be able to assign full /64 address block to the + peer as described in [RFC5739], even if it is not authenticated. 3. Security Considerations If authenticated IKE sessions are possible for a certain traffic selector range between the peers, then unauthenticated IKE SHOULD NOT be allowed for that traffic selector range. When mixing authenticated and unauthenticated IKE with the same peer, policy rules should ensure the highest level of security will be used to protect the communication between the two peers. See [RFC7435] for details. @@ -277,25 +279,25 @@ becomes unauthenticated. This makes the IKE session vulnerable to active Man-in-the-Middle Attacks. Using an ID Type other than ID_NULL with the NULL Authentication Method may compromise the client's anonymity in case of an active MITM attack. IKE implementations without NULL Authentication have always performed mutual authentication and were not designed for use with unauthenticated IKE peers. Implementations might have made - assumptions remote peers are identified. With NULL Authentication - these assumptions are no longer valid. Furthermore, the host itself - might have made trust assumptions or may not be aware of the network - topology changes that resulted from IPsec SAs from unauthenticated - IKE peers. + assumptions that remote peers are identified. With NULL + Authentication these assumptions are no longer valid. Furthermore, + the host itself might have made trust assumptions or may not be aware + of the network topology changes that resulted from IPsec SAs from + unauthenticated IKE peers. 3.1. Audit trail and peer identification With NULL Authentication an established IKE session is no longer guaranteed to provide a verifiable (authenticated) entity known to the system or network. Implementers that implement NULL Authentication should ensure their implementation does not make any assumptions that depend on IKE peers being "friendly", "trusted" or "identifiable". @@ -388,20 +390,67 @@ [AUTOVPN] Sheffer, Y. and Y. Nir, "The AutoVPN Architecture", Work in Progress, draft-sheffer-autovpn-00, February 2014. [DDOS-PROTECTION] Nir, Y., "Protecting Internet Key Exchange (IKE) Implementations from Distributed Denial of Service Attacks", draft-ietf-ipsecme-ddos-protection-00 (work in progress), October 2014. +Appendix A. Update of PAD processing in RFC4301 + + This appendix lists the specific updates of the text in Section 4.4.3 + of [RFC4301] that should be followed when implementing NULL + Authentication. + + A new item is added to the list of supported ID types in Section + 4.4.3.1 + + o NULL ID (matches ID type only) + + and the following text is added at the end of the section: + + Added text: + The NULL ID type is defined as having no data. For this name type + the matching function is defined as comparing the ID type only. + + A new item is added to the list of authentication data types in + Section 4.4.3.2 + + - NULL authentication + + and the next paragraph is updated as follows: + + Old: + For authentication based on an X.509 certificate [...] For + authentication based on a pre-shared secret, the PAD contains the + pre-shared secret to be used by IKE. + + New: + For authentication based on an X.509 certificate [...] For + authentication based on a pre-shared secret, the PAD contains the + pre-shared secret to be used by IKE. For NULL authentication the + PAD contains no data. + + In addition the following text is added at the end of Section 4.4.3.4 + + Added text: + When using the NULL authentication method implementations MUST + make sure that they do not mix authenticated and not-authenticated + SPD rules, i.e. implementations need to keep them separately, for + example by adding flag in SPD to tell whether NULL authentication + can be used or not for the entry. I.e. each SPD entry needs to be + augmented to have a flag specifying whether it can be used with + NULL authentication or not, and only those rules that explictly + have that flag set can be used with unauthenticated connections. + Authors' Addresses Valery Smyslov ELVIS-PLUS PO Box 81 Moscow (Zelenograd) 124460 Russian Federation Phone: +7 495 276 0211 Email: svan@elvis.ru