idnits 2.17.1 draft-smyslov-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 (March 3, 2014) is 3678 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) ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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 March 3, 2014 5 Expires: September 4, 2014 7 The NULL Authentication Method in IKEv2 Protocol 8 draft-smyslov-ipsecme-ikev2-null-auth-01 10 Abstract 12 This document defines the NULL Authentication Method for the IKEv2 13 Protocol. This method provides a way to omit peer authentication in 14 IKEv2 and to explicitely indicate it in the protocol run. This 15 method may be used to preserve anonymity or in situations, where no 16 trust relationship exists between the parties. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 4, 2014. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Conventions Used in This Document . . . . . . . . . . . . . 3 54 2. Using the NULL Authentication Method . . . . . . . . . . . . . 4 55 2.1. Authentication Payload . . . . . . . . . . . . . . . . . . 4 56 2.2. Identity Payload . . . . . . . . . . . . . . . . . . . . . 4 57 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 58 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 60 6. Normative References . . . . . . . . . . . . . . . . . . . . . 8 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 1. Introduction 65 The Internet Key Exchange Protocol version 2 (IKEv2), specified in 66 [RFC5996], provides a way for two parties to perform authenticated 67 key exchange. Mutual authentication is mandatory in the IKEv2, so 68 that each party must be authenticated by the other, but 69 authentication methods, used by the peers, need not be the same. 71 In some situations mutual authentication is undesirable or 72 impossible. For example: 74 o User wants to get anonymous access to some resource. In this 75 situation he/she should be able to authenticate server, but to 76 leave out his/her own authentication to prevent anonymity. In 77 this case one-way authentication is desirable. 79 o User wants to get some simple action from remote device. Consider 80 garage door opener: it must authenticate user to open the door, 81 but it is not necessary for the user to authenticate the door 82 opener. In this case one-way authentication is sufficient. 84 o Two peers without any trust relationship want to get some level of 85 security in their communications. Without trust relationship they 86 cannot prevent active Man-in-the-Middle attacks, but it is still 87 possible to prevent passive eavesdropping with opportunistic 88 encryption. In this case they have to perform unauthenticated key 89 exchange. 91 To meet this needs the document introduces the NULL Authentication 92 Method, which is effectively a "dummy" method, that provides no 93 authentication. This allows peer to explicitely indicate to the 94 other side that he/she is unwilling or unable to certify his/her 95 identity. 97 1.1. Conventions Used in This Document 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119]. 103 2. Using the NULL Authentication Method 105 In IKEv2 each peer independently selects the method to authenticate 106 himself/herself to the other side. It means that any peer may choose 107 to omit his/her authentication by using the NULL Authentication 108 Method. If it is not acceptable for the peer, he/she MUST return 109 AUTHENTICATION_FAILED Notification. Note, that when initiator uses 110 EAP, responder MUST NOT use the NULL Authentication Method (in 111 conformance with the section 2.16 of [RFC5996]). 113 The NULL Authentication Method affects how Authentication and 114 Identity Payloads are formed in IKE_AUTH Exchange. 116 2.1. Authentication Payload 118 Even when implementation uses the NULL Authentication, the AUTH 119 Payload must still be present in IKE_AUTH Exchange and must be 120 properly formed, as it cryptographically links IKE_SA_INIT Messages 121 with the other Messages sent over IKE SA. 123 With the NULL Authentication Method the content of AUTH Payload MUST 124 be computed using the syntax for pre-shared secret authentication, 125 described in Section 2.15 of [RFC5996]. The values SK_pi and SK_pr 126 MUST be used as shared secrets for AUTH Payloads generated by 127 Initiator and Responder respectively. Note, that this is exactly how 128 content of the two last AUTH Payloads is calculated in case of using 129 non-key generating EAP Method (see Section 2.16 of [RFC5996] for 130 details). The field Auth Method MUST be set to . 132 2.2. Identity Payload 134 The NULL Authentication Method provides no authentication of the 135 party using it. For that reason Identity Payload content cannot be 136 verified by the other party and MUST be ignored by IKE. As peer 137 identity is meaningless in this case, Identification Data SHOULD be 138 omited from ID Payload, in which case ID Type MAY be set to any 139 value. Implementations supporting the NULL Authentication Method 140 MUST NOT fail if they receive such "empty" ID Payload. 142 3. Security Considerations 144 IKEv2 protocol provides mutual authentication of the peers. If one 145 peer uses the NULL Authentication Method, then this peer cannot be 146 authenticated by the other side, and it makes authentication in IKEv2 147 to become one-way. If both peers use the NULL Authentication method, 148 key exchange becomes unauthenticated, that makes it subject to the 149 Man-in-the-Middle attack. 151 The identity of the peer using the NULL Authenticated Method cannot 152 be verified by the other side and, therefore, MUST NOT be used 153 neither for authorization purposes, nor for policy decisions. All 154 peers who use the NULL Authenticated Method should be considered by 155 the other party as "guests" and get the least possible privileges. 157 4. Acknowledgments 159 The author would like to thank Paul Wouters and Yaron Sheffer for 160 their reviews and valueable comments. 162 5. IANA Considerations 164 This document defines new value in the "IKEv2 Authentication Method" 165 registry: 167 NULL Authentication Method 169 6. Normative References 171 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 172 Requirement Levels", BCP 14, RFC 2119, March 1997. 174 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 175 "Internet Key Exchange Protocol Version 2 (IKEv2)", 176 RFC 5996, September 2010. 178 Author's Address 180 Valery Smyslov 181 ELVIS-PLUS 182 PO Box 81 183 Moscow (Zelenograd) 124460 184 Russian Federation 186 Phone: +7 495 276 0211 187 Email: svan@elvis.ru