wdiff draft-ietf-ipsecme-ikev2-null-auth-00.txt draft-ietf-ipsecme-ikev2-null-auth-01.txt

Network Working Group V. Smyslov
Internet-Draft ELVIS-PLUS
Intended status: Standards Track September 15, October 22, 2014
Expires: March 19, April 25, 2015

The NULL Authentication Method in IKEv2 Protocol
draft-ietf-ipsecme-ikev2-null-auth-00
draft-ietf-ipsecme-ikev2-null-auth-01

Abstract

This document introduces the NULL Authentication Method authentication method for the IKEv2
Protocol. This method provides a way to omit peer authentication in
the IKEv2. It may be used to preserve anonymity of or in the
situations, where no trust relationship exists between the parties.

Status of this Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

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 March 19, April 25, 2015.

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
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . . 3
2. Using the NULL Authentication Method . . . . . . . . . . . . . 4
2.1. Authentication Payload . . . . . . . . . . . . . . . . . . 4
2.2. Identity Payload . . . . . . . . . . . . . . . . . . . . . 4
2.3. INITIAL_CONTACT Notification . . . . . . . . . . . . . . . 4
3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 6
4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 8
6. Normative References . . . . . . . . . . . . . . . . . . . . . 8 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 10

1. Introduction

The Internet Key Exchange Protocol version 2 (IKEv2), specified in
[IKEv2], provides a way for two parties to perform authenticated key
exchange. Mutual authentication is mandatory in the IKEv2, so that
each party must be authenticated by the other. However the
authentication methods, used by the peers, need not be the same.

In some situations mutual authentication is undesirable, superfluous
or impossible. For example:

o User wants to get anonymous access to some server. In this
situation he/she should be able to authenticate the server, but to
leave out his/her own authentication to preserve anonymity. In
this case one-way authentication of the responder is desirable.

o Sensor, that sleeps most of the time, but periodically wakes up,
makes some measurment (e.g. temperature) and sends the results to
some server. The senser sensor must be authenticated by the server to
ensure authenticity of the measurment, but the server need not be
authenticated by the senser. sensor. In this case one-way authentication
of the initiator is sufficient.

o Two peers without any trust relationship want to get some level of
security in their communications. Without trust relationship they
cannot prevent active Man-in-the-Middle attacks, but it is still
possible to prevent passive eavesdropping with opportunistic
encryption. In this case they can use unauthenticated key
exchange.

To meet these needs the document introduces the NULL Authentication
Method, authentication
method, which is a "dummy" method, that provides no authentication.
This allows peer to explicitly indicate to the other side 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].

2. Using the NULL Authentication Method

In IKEv2 each peer independently selects the method to authenticate
itself to the other side. It means that any of the peers may choose
to omit its authentication by using the NULL Authentication Method. authentication method.
If it is not acceptable for the other peer, it MUST return
AUTHENTICATION_FAILED Notification. notification. Note, that when the Initiator initiator
uses EAP, the Responder responder MUST NOT use the NULL Authentication Method authentication method
(in conformance with the section 2.16 of [IKEv2]).

The NULL Authentication Method authentication method affects how the Authentication and the
Identity payloads are formed in the IKE_AUTH Exchange. exchange.

2.1. Authentication Payload

Despite the fact that the NULL Authentication Method authentication method provides no
authentication, the AUTH Payload payload must still be present in the
IKE_AUTH Exchange exchange messages and must be properly formed, as it
cryptographically links the IKE_SA_INIT Exchange exchange messages with the
other messages sent over the this IKE SA.

With the NULL Authentication Method authentication method the content of the AUTH Payload payload
MUST be computed using the syntax for pre-shared secret
authentication, described in Section 2.15 of [IKEv2]. The values
SK_pi and SK_pr MUST be used as shared secrets for the content of the
AUTH Payloads payloads generated by Initiator the initiator and Responder the responder
respectively. Note, that this is exactly how the content of the two
last AUTH
Payloads payloads is calculated for non-key generating EAP Method method
(see Section 2.16 of [IKEv2] for details). The value for the the
NULL
Authentication Method authentication method is <TBA by IANA>.

2.2. Identity Payload

The NULL Authentication Method authentication method provides no authentication of the
party using it. For that reason the Identity Payload payload content cannot
be verified by the peer and MUST be ignored by the IKE.

This specification defines new ID Type - ID_NULL, which is intended
to be used with the NULL Authentication Method authentication method to explicitely
indicate anonymity of the peer. This ID Type SHOULD MUST NOT be used with
other
authentication methods. methods, that provide real authentication. The
Identification Data in Identity
Payload payload for the ID_NULL type MUST be
absent and the ID Type is set to <TBA by IANA>.

2.3. INITIAL_CONTACT Notification

The identity of the peer which uses the NULL authentication method
cannot be used to distinguish betweed IKE SAs created by different
peers, because the peers may use the same identity (for example all
endpoints which use identity of type ID_NULL). For that reason the
INITIAL_CONTACT notification MUST be ignored if it is present by the
party using the NULL authentication method. To find out stale IKE
SAs in this situation, implementations should perform Liveness Check
on all IKE SAs with the same peer idenity as the newly created IKE
SA.

3. Security Considerations

IKEv2 protocol provides mutual authentication of the peers. If one
peer uses the NULL Authentication Method, authentication method, then this peer cannot be
authenticated by the other side, and it makes authentication in IKEv2
to be one-way. If both peers use the NULL Authentication method, key
exchange becomes unauthenticated, that makes it subject susceptible to active
attacks. For that reason completely unauthenticated IKE SA must be
used only if the Man-
in-the-Middle attack. alternative is to send plaintext.

The identity of the peer using the the NULL Authenticated Method authenticated method
cannot be verified by the other side and, therefore, MUST NOT be used
neither for authorization purposes, nor for policy decisions. All
peers who use the NULL Authenticated Method should be considered by
the other party as "guests" and get the least possible privileges.
Implementations are advised to use the ID_NULL Identity Type with the
NULL authenticated method.

If endpoint receives a request to create an unauthenticated IKE SA
from the IP address, which is configured on the endpoint to be
authenticated, the request SHOULD be rejected.

If the peer uses the NULL Authenticated Method, authenticated method, then the content of
its Traffic Selector Payloads payloads must be treated with care. In
particular, implementations are advised not to trust blindly that the
public IP addresses the peer put into TS Payload payload are really belong to
it. It is RECOMMENDED for security gateways to always assign
internal IP addresses to unauthenticated clients as described in
Section 2.19 of [IKEv2].

4. Acknowledgments

The author would like to thank Paul Wouters, Yaron Sheffer and Tero
Kivinen for their reviews and valuable comments.

5. IANA Considerations

This document defines new value in the "IKEv2 Authentication Method"
registry:

<TBA> NULL Authentication Method

It also defines new value in the "IKEv2 Identification Payload ID
Types" registry:

<TBA> ID_NULL

6. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[IKEv2] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", draft-kivinen-ipsecme-ikev2-rfc5996bis-04 (work
in progress), June 2014.

Author's Address

Valery Smyslov
ELVIS-PLUS
PO Box 81
Moscow (Zelenograd) 124460
Russian Federation

Phone: +7 495 276 0211
Email: svan@elvis.ru