--- 1/draft-ietf-ipsecme-ikev2-null-auth-03.txt 2015-02-19 23:14:55.020532725 -0800 +++ 2/draft-ietf-ipsecme-ikev2-null-auth-04.txt 2015-02-19 23:14:55.044533312 -0800 @@ -1,19 +1,19 @@ Network Working Group V. Smyslov Internet-Draft ELVIS-PLUS Intended status: Standards Track P. Wouters -Expires: August 1, 2015 Red Hat - January 28, 2015 +Expires: August 24, 2015 Red Hat + February 20, 2015 The NULL Authentication Method in IKEv2 Protocol - draft-ietf-ipsecme-ikev2-null-auth-03 + draft-ietf-ipsecme-ikev2-null-auth-04 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 August 1, 2015. + This Internet-Draft will expire on August 24, 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 @@ -101,21 +101,21 @@ authentication of the initiator. 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 an Man-in-the-Middle + 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. 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 @@ -157,50 +157,51 @@ 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. If NULL Authentication is in use and an anonymity is a concern then - ID_NULL SHOULD be used in Identification payload. In some cases - there may be good reasons to use non-null identities (and ID Types - other than ID_NULL) with NULL Authentication. The identities may be - used for logging, troubleshooting or in scenarios when authentication - takes place out of band after the IKE SA is created (like in - [AUTOVPN]). In any case, when NULL Authentication is employed, the - content of Identification payload MUST NOT be used for any trust and - policy checking in IKE_AUTH exchange. + ID_NULL SHOULD be used in the Identification payload. Some examples + of acceptable cases to use a non-null identity type and value with + NULL Authentication are logging, troubleshooting or in scenarios + where authentication takes place out of band after the IKE SA is + created (like in [AUTOVPN]). The content of the Identification + payload MUST NOT be used for any trust and policy checking in + IKE_AUTH exchange when NULL Authentication is employed (see Section + 2.4 for details). - ID_NULL is primarily intended to be used with the NULL - Authentication, but it MAY also be used in other situations, when the - content of Identification payload does not matter. For example, - ID_NULL can be used when authentication is performed via raw public - keys and the identities are these keys themselves. Another example - is EAP authentication when the client identity in ID payload is not - used. + ID_NULL is primarily intended to be used with NULL Authentication but + could be used in other situations where the content of the + Identification Payload is not used. For example, ID_NULL could be + used when authentication is performed via raw public keys and the + identities are the keys themselves. These alternative uses of + ID_NULL should be described in their own respective documents. The IKEv2 Identification Payload ID Type for ID_NULL is 13. 2.3. INITIAL_CONTACT Notification The identity of a peer using NULL Authentication cannot be used to - distinguish from IKE SAs created by other peers using the NULL - Authentication method. For that reason the INITIAL_CONTACT - notifications MUST be ignored for IKE SAs using NULL Authentication. + find existing IKE SAs created by the same peer, as the peer identity + is not authenticated. For that reason the INITIAL_CONTACT + notifications MUST NOT be used to delete any other IKE SAs based on + the same peer identity without additional verification that the + existing IKE SAs with matching identity are actually stale. - The standard IKE Liveness Check procedure, decribed in Section 2.4 of - [RFC7296], can be used to detect stale IKE SAs created by peers using - NULL Authentication. Inactive unauthenticated IKE SAs should be - checked periodically. Additionally, the event of creating a new + The standard IKE Liveness Check procedure, described in Section 2.4 + of [RFC7296], can be used to detect stale IKE SAs created by peers + using NULL Authentication. Inactive unauthenticated IKE SAs should + be checked periodically. Additionally, the event of creating a new unauthenticated IKE SA can be used to trigger an out-of-order check on existing unauthenticated IKE SAs, possibly limited to identical or close-by IP addresses or to identical identities of the just created IKE SA. Implementations should weight 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. @@ -209,41 +210,39 @@ 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 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 used. If ID_NULL is used with NULL + 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. - If NULL Authentication is supported and allowed, then a special entry - MUST be included in the PAD. This entry MUST contain no - authentication data. It MAY contain a set of constraints for - creating Child SAs as described in Section 4.4.3 of [RFC4301]. When - a peer uses NULL Authentication, regular matching rules for the PAD - MUST be ignored and this special entry MUST be selected regardless of - the peer identity. Likewise, if a peer uses any other authentication - method, then this special entry MUST NOT be selected regardless of - the peer identity and the regular search of the PAD described in - Section 4.4.3.4 of [RFC4301] MUST be performed. + The 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 is just whether this type is used, i.e. no + actual ID matching is done, as ID_NULL contains no identity data. - Implementations SHOULD allow to be configured so, that when a peer - requests NULL Authentication, then regular PAD entries are searched - before selecting the special entry, to ensure that there is no entry, - containing peer's IP address. In this case implementations MUST - reject the IKE_AUTH exchange by sending an AUTHENTICATION_FAILED - notification if such an entry is found. + 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 flag + specifying whether it can be used with NULL authentication or not, + and only those rules explictly having that flag turned on can be used + with unauthenticated connections. 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 @@ -258,32 +257,33 @@ internal NAT and connection tracking. Implementations MAY force unauthenticated IKE peers to single host- to-host IPsec SAs. When using IPv6 it 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. 3. Security Considerations - If authenticated IKE sessions are possible between the peers, then - unauthenticated IKE SHOULD NOT be used, unless implementations make - sure to keep authenticated and unauthenticated IKE sessions separate, - and has policy rules to specify when to use which IKE session. See - [RFC7435] for details. + If authenticated IKE sessions are possible for a certain traffic + selector range between the peers, then unauthenticated IKE SHOULD NOT + be used 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. If both peers use NULL Authentication, the entire key exchange 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 anonimity in case of an active + 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 that 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. @@ -328,27 +328,27 @@ peer. 3.4. Networking topology changes When a host relies on packet filters or firewall software to protect itself, establishing an IKE SA and installing an IPsec SA might accidentally circumvent these packet filters and firewall restrictions, as the encrypted ESP (protocol 50) or ESPinUDP (UDP port 4500) packets do not match the packet filters defined. IKE peers supporting unauthenticated IKE MUST pass all decrypted traffic - through the same packet filters and security mechanisms as plaintext - traffic. + through the same packet filters and security mechanisms as incoming + plaintext traffic. 4. Acknowledgments The authors would like to thank Yaron Sheffer and Tero Kivinen for - their reviews and valuable comments. + their reviews, valuable comments and contributed text. 5. IANA Considerations This document defines a new entry in the "IKEv2 Authentication Method" registry: 13 NULL Authentication This document also defines a new entry in the "IKEv2 Identification Payload ID Types" registry: