idnits 2.17.1 draft-ietf-ipsecme-ikev2-null-auth-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2014) is 3466 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Normative reference to a draft: ref. 'IKEv2' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Smyslov 3 Internet-Draft ELVIS-PLUS 4 Intended status: Standards Track October 22, 2014 5 Expires: April 25, 2015 7 The NULL Authentication Method in IKEv2 Protocol 8 draft-ietf-ipsecme-ikev2-null-auth-01 10 Abstract 12 This document introduces the NULL authentication method for the IKEv2 13 Protocol. This method provides a way to omit peer authentication in 14 the IKEv2. It may be used to preserve anonymity of or in the 15 situations, where no trust relationship exists between the parties. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on April 25, 2015. 34 Copyright Notice 36 Copyright (c) 2014 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 53 2. Using the NULL Authentication Method . . . . . . . . . . . . . 4 54 2.1. Authentication Payload . . . . . . . . . . . . . . . . . . 4 55 2.2. Identity Payload . . . . . . . . . . . . . . . . . . . . . 4 56 2.3. INITIAL_CONTACT Notification . . . . . . . . . . . . . . . 4 57 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 58 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 60 6. Normative References . . . . . . . . . . . . . . . . . . . . . 9 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 1. Introduction 65 The Internet Key Exchange Protocol version 2 (IKEv2), specified in 66 [IKEv2], provides a way for two parties to perform authenticated key 67 exchange. Mutual authentication is mandatory in the IKEv2, so that 68 each party must be authenticated by the other. However the 69 authentication methods, used by the peers, need not be the same. 71 In some situations mutual authentication is undesirable, superfluous 72 or impossible. For example: 74 o User wants to get anonymous access to some server. In this 75 situation he/she should be able to authenticate the server, but to 76 leave out his/her own authentication to preserve anonymity. In 77 this case one-way authentication of the responder is desirable. 79 o Sensor, that sleeps most of the time, but periodically wakes up, 80 makes some measurment (e.g. temperature) and sends the results to 81 some server. The sensor must be authenticated by the server to 82 ensure authenticity of the measurment, but the server need not be 83 authenticated by the sensor. In this case one-way authentication 84 of the initiator is sufficient. 86 o Two peers without any trust relationship want to get some level of 87 security in their communications. Without trust relationship they 88 cannot prevent active Man-in-the-Middle attacks, but it is still 89 possible to prevent passive eavesdropping with opportunistic 90 encryption. In this case they can use unauthenticated key 91 exchange. 93 To meet these needs the document introduces the NULL authentication 94 method, which is a "dummy" method, that provides no authentication. 95 This allows peer to explicitly indicate to the other side that it is 96 unwilling or unable to certify its identity. 98 1.1. Conventions Used in This Document 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 2. Using the NULL Authentication Method 106 In IKEv2 each peer independently selects the method to authenticate 107 itself to the other side. It means that any of the peers may choose 108 to omit its authentication by using the NULL authentication method. 109 If it is not acceptable for the other peer, it MUST return 110 AUTHENTICATION_FAILED notification. Note, that when the initiator 111 uses EAP, the responder MUST NOT use the NULL authentication method 112 (in conformance with the section 2.16 of [IKEv2]). 114 The NULL authentication method affects how the Authentication and the 115 Identity payloads are formed in the IKE_AUTH exchange. 117 2.1. Authentication Payload 119 Despite the fact that the NULL authentication method provides no 120 authentication, the AUTH payload must still be present in the 121 IKE_AUTH exchange messages and must be properly formed, as it 122 cryptographically links the IKE_SA_INIT exchange messages with the 123 other messages sent over this IKE SA. 125 With the NULL authentication method the content of the AUTH payload 126 MUST be computed using the syntax for pre-shared secret 127 authentication, described in Section 2.15 of [IKEv2]. The values 128 SK_pi and SK_pr MUST be used as shared secrets for the content of the 129 AUTH payloads generated by the initiator and the responder 130 respectively. Note, that this is exactly how the content of the two 131 last AUTH payloads is calculated for non-key generating EAP method 132 (see Section 2.16 of [IKEv2] for details). The value for the the 133 NULL authentication method is . 135 2.2. Identity Payload 137 The NULL authentication method provides no authentication of the 138 party using it. For that reason the Identity payload content cannot 139 be verified by the peer and MUST be ignored by the IKE. 141 This specification defines new ID Type - ID_NULL, which is intended 142 to be used with the NULL authentication method to explicitely 143 indicate anonymity of the peer. This ID Type MUST NOT be used with 144 authentication methods, that provide real authentication. The 145 Identification Data in Identity payload for the ID_NULL type MUST be 146 absent and the ID Type is set to . 148 2.3. INITIAL_CONTACT Notification 150 The identity of the peer which uses the NULL authentication method 151 cannot be used to distinguish betweed IKE SAs created by different 152 peers, because the peers may use the same identity (for example all 153 endpoints which use identity of type ID_NULL). For that reason the 154 INITIAL_CONTACT notification MUST be ignored if it is present by the 155 party using the NULL authentication method. To find out stale IKE 156 SAs in this situation, implementations should perform Liveness Check 157 on all IKE SAs with the same peer idenity as the newly created IKE 158 SA. 160 3. Security Considerations 162 IKEv2 protocol provides mutual authentication of the peers. If one 163 peer uses the NULL authentication method, then this peer cannot be 164 authenticated by the other side, and it makes authentication in IKEv2 165 to be one-way. If both peers use the NULL Authentication method, key 166 exchange becomes unauthenticated, that makes it susceptible to active 167 attacks. For that reason completely unauthenticated IKE SA must be 168 used only if the alternative is to send plaintext. 170 The identity of the peer using the the NULL authenticated method 171 cannot be verified by the other side and, therefore, MUST NOT be used 172 neither for authorization purposes, nor for policy decisions. All 173 peers who use the NULL Authenticated Method should be considered by 174 the other party as "guests" and get the least possible privileges. 175 Implementations are advised to use the ID_NULL Identity Type with the 176 NULL authenticated method. 178 If endpoint receives a request to create an unauthenticated IKE SA 179 from the IP address, which is configured on the endpoint to be 180 authenticated, the request SHOULD be rejected. 182 If the peer uses the NULL authenticated method, then the content of 183 its Traffic Selector payloads must be treated with care. In 184 particular, implementations are advised not to trust blindly that the 185 public IP addresses the peer put into TS payload are really belong to 186 it. It is RECOMMENDED for security gateways to always assign 187 internal IP addresses to unauthenticated clients as described in 188 Section 2.19 of [IKEv2]. 190 4. Acknowledgments 192 The author would like to thank Paul Wouters, Yaron Sheffer and Tero 193 Kivinen for their reviews and valuable comments. 195 5. IANA Considerations 197 This document defines new value in the "IKEv2 Authentication Method" 198 registry: 200 NULL Authentication Method 202 It also defines new value in the "IKEv2 Identification Payload ID 203 Types" registry: 205 ID_NULL 207 6. Normative References 209 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 210 Requirement Levels", BCP 14, RFC 2119, March 1997. 212 [IKEv2] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 213 Kivinen, "Internet Key Exchange Protocol Version 2 214 (IKEv2)", draft-kivinen-ipsecme-ikev2-rfc5996bis-04 (work 215 in progress), June 2014. 217 Author's Address 219 Valery Smyslov 220 ELVIS-PLUS 221 PO Box 81 222 Moscow (Zelenograd) 124460 223 Russian Federation 225 Phone: +7 495 276 0211 226 Email: svan@elvis.ru