idnits 2.17.1 draft-smyslov-ipsecme-ikev2-null-auth-00.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 (December 24, 2013) is 3776 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** 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: Informational December 24, 2013 5 Expires: June 27, 2014 7 The NULL Authentication Method in IKEv2 Protocol 8 draft-smyslov-ipsecme-ikev2-null-auth-00 10 Abstract 12 This document defines the NULL Authentication Method for 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 June 27, 2014. 35 Copyright Notice 37 Copyright (c) 2013 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 NULL Authentication Method . . . . . . . . . . . . . . . 4 55 2.1. Authentication Payload . . . . . . . . . . . . . . . . . . 4 56 2.2. Identity Payload . . . . . . . . . . . . . . . . . . . . . 4 57 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 58 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 59 5. Normative References . . . . . . . . . . . . . . . . . . . . . 7 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 1. Introduction 64 The Internet Key Exchange Protocol version 2 (IKEv2), specified in 65 [RFC5996], provides a way for two parties to perform authenticated 66 key exchange. Mutual authentication is mandatory in the IKEv2, so 67 that each party must be authenticated by the other, but 68 authentication methods, used by the peers, need not be the same. 70 In some situations mutual authentication is undesirable or 71 impossible. For example: 73 o User wants to get anonymous access to some resource. In this 74 situation he/she should be able to authenticate server, but to 75 leave out his/her own authentication to prevent anonymity. In 76 this case one-way authentication is desirable. 78 o Two peers without any trust relationship want to get some level of 79 security in their communications. Without trust relationship they 80 cannot prevent active Man-in-the-Middle attacks, but it is still 81 possible to prevent passive eavesdropping with opportunistic 82 encryption. In this case they have to perform unauthenticated key 83 exchange. 85 To meet this needs the document introduces NULL Authentication 86 Method, which is effectively a "dummy" method, that provides no 87 authentication. This allows peer to explicitely indicate to the 88 other side that he is unwilling or unable to certify his identity. 90 1.1. Conventions Used in This Document 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 2. Using NULL Authentication Method 98 NULL Authentication Method affects how Authentication and Identity 99 Payloads are formed in IKE_AUTH Exchange. 101 2.1. Authentication Payload 103 Even when peer uses NULL Authentication, the AUTH Payload must still 104 be present in IKE_AUTH Exchange and must be properly formed, as it 105 cryptographically links IKE_SA_INIT Messages with the other Messages 106 sent over IKE SA. 108 With NULL Authentication Method the content of AUTH Payload MUST be 109 computed using the syntax for pre-shared secret authentication, 110 described in Section 2.15 of [RFC5996]. The values SK_pi and SK_pr 111 MUST be used as shared secrets for AUTH Payloads generated by 112 Initiator and Responder respectively. Note, that this is exactly how 113 content of the two last AUTH Payloads is calculated in case of using 114 non-key generating EAP Method (see Section 2.16 of [RFC5996] for 115 details). The field Auth Method MUST be set to . 118 2.2. Identity Payload 120 NULL Authentication Method provides no authentication of the party 121 using it. For that reason Identity Payload content cannot be 122 verified by the other party and SHOULD be ignored. It MAY be used 123 for the purpose of audit, but it MUST NOT be used for any 124 authorization decisions. As peer identity is meaningless in this 125 case, Identification Data MAY be omited from ID Payload, in which 126 case ID Type MAY be set to any value. Implementations supporting 127 NULL Authentication Method MUST NOT fail if they receive such "empty" 128 ID Payload. 130 3. Security Considerations 132 IKEv2 protocol provides mutual authentication of the peers. If one 133 peer uses NULL Authentication Method, then this peer cannot be 134 authenticated by the other side, and it makes authentication in IKEv2 135 to become one-way. If both peers use NULL Authentication method, key 136 exchange becomes unauthenticated, that makes it subject to the Man- 137 in-the-Middle attack. 139 The identity of the peer using NULL Authenticated Method cannot be 140 verified by the other side and, therefore, MUST NOT be used neither 141 for authorization purposes, nor for policy decisions. All peers who 142 use NULL Authenticated Method should be considered by the other party 143 as "guests" and get the least possible privileges. 145 4. IANA Considerations 147 This document defines new value in the "IKEv2 Authentication Method" 148 registry: 150 NULL Authentication Method 152 5. Normative References 154 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 155 Requirement Levels", BCP 14, RFC 2119, March 1997. 157 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 158 "Internet Key Exchange Protocol Version 2 (IKEv2)", 159 RFC 5996, September 2010. 161 Author's Address 163 Valery Smyslov 164 ELVIS-PLUS 165 PO Box 81 166 Moscow (Zelenograd) 124460 167 RU 169 Phone: +7 495 276 0211 170 Email: svan@elvis.ru