Internet DRAFT - draft-williams-btns
draft-williams-btns
NETWORK WORKING GROUP N. Williams
Internet-Draft Sun
Expires: February 2, 2006 August 2005
Better-Than-Nothing-Security: An Unauthenticated Mode of IPsec
draft-williams-btns-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 2, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document specifies how to use the Internet Key Exchange (IKE)
protocols, such as IKEv1 and IKEv2, to setup "unauthenticated"
security associations (SAs) for use with the IPsec Encapsulating
Security Payload (ESP) and the IPsec Authentication Header (AH). No
IKE extensions are needed, but a Peer Authorization Database (PAD)
extension in the form of an ID selector wildcard, 'UNKNOWN',
specified. Unauthenticated IPsec is herein referred to by its
popular acronym, "BTNS" (Better Than Nothing Security).
Williams Expires February 2, 2006 [Page 1]
Internet-Draft BTNS IPsec August 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions used in this document . . . . . . . . . . . . . 3
2. BTNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Asymmetric and Symmetric BTNS SAs . . . . . . . . . . . . . 5
3. Leap-of-Faith BTNS . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . 7
5. Normative . . . . . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . 10
Williams Expires February 2, 2006 [Page 2]
Internet-Draft BTNS IPsec August 2005
1. Introduction
A number of users and applications can benefit from the availability
of "unauthenticated" IPsec or "better than nothing security" (BTNS),
where unauthenticated key exchanges are subject to initial, but not
subsequent MITM attacks, as described in [I-D.ietf-btns-prob-and-
applic].
Here we describe how to establish unauthenticated IPsec SAs using
IKEv1 [RFC2408] [RFC2409] or IKEv2 [I-D.ietf-ipsec-ikev2] and
unauthenticated public keys or certificates. No new bits-on-the-wire
are added to IKE or IKEv2, but a new wildcard for ID selectors in
PAD/SPD entries is added: 'UNKNOWN.'
The [I-D.ietf-ipsec-rfc2401bis] processing model is assumed,
specifically the PAD as a concept separate from the SPD.
This document does not define an opportunistic BTNS mode of IPsec
whereby nodes may fallback on unprotected IP when their peers do not
support IKE or IKEv2, but it does describe an optional leap-of-faith
BTNS mode.
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].
Williams Expires February 2, 2006 [Page 3]
Internet-Draft BTNS IPsec August 2005
2. BTNS
The IPsec processing model, IKE and IKEv2 are hereby modified as
follows:
o An optional new ID type is added, 'PUBLICKEY', for use in PAD and
SPD entries, so that ID selectors can match on public key values.
This ID type is be used for the optional leap-of-faith BTNS mode
(see below), but users could use it to manually create PAD/SPD
entries in a manual equivalent of leap-of-faith BTNS.
o A new wildcard ID selector value for use in PAD and SPD entries is
added, 'UNKNOWN', which matches any peer ID.
o For BTNS IKE and IKEv2 MUST coerce the IDs of peers whose CERT
payloads could not be validated (in certain conditions, see below)
to PUBLICKEY IDs whose values correspond to the public key used by
the peer (if the peer used a certificate, then the certificate's
subjectPublicKey) that can only be matched by either the 'UNKNOWN'
ID selector wildcard value or a PUBLICKEY ID selector with that
same key as its value; of course, HASH/AUTH payloads must be
validated.
Nodes wishing to be treated as BTNS nodes by their peers SHOULD use
CERT payloads generated for the purpose (i.e., ephemeral, non-pre-
shared self-signed certificates or bare RSA public keys).
The conditions under which a BTNS-capable IKE/IKEv2 implementation
MUST accept an IKE_SA that it would otherwise reject are such where
the reasons for rejection relate only to the peer's CERT payload,
namely:
o the peer's CERT was a bare RSA public key and not pre-shared to
the other peer;
o the peer's CERT was a self-signed certificate not pre-shared to
the other peer;
o the peer's CERT was a certificate for which no validation chain
could be constructed and validated by the other peer to one of its
trust anchors.
Similar conditions relating to other CERT payload types are not
described herein.
In other words, BTNS-capable nodes coerce the IDs of peers whose AUTH
payloads were valid but whose CERTs could not be validated (due to
their being unknown bare public keys, self-signed certificates or
Williams Expires February 2, 2006 [Page 4]
Internet-Draft BTNS IPsec August 2005
certificates from unknown PKIs) to IDs which can only be matched by
the new 'UNKNOWN' PAD/SPD ID selector wildcard value or by ID
selectors of the new 'PUBLICKEY' whose value matches the given key.
2.1. Asymmetric and Symmetric BTNS SAs
The key exchange protocols for IPsec are not modified by BTNS, only
processing of peers that would otherwise be rejected by non-BTNS
peers is modified. The rest of the IPsec processing model is
modified only to introduce a way to match unauthenticated peer IDs in
the PAD/SPD. Nodes therefore may not know that peers may accept them
only for authorization as unauthenticated peers. As a result there
is no distinction between symmetric BTNS SAs (where both peers are
unauthenticated) and asymmetric SAs (where only one of the peers is
unauthenticated) beyond the each peer's willingness to authorize
unauthenticated peers to specific resources.
Williams Expires February 2, 2006 [Page 5]
Internet-Draft BTNS IPsec August 2005
3. Leap-of-Faith BTNS
Implementors may provide a PAD entry attribute used to indicate that
the given PAD entry is a template that should, when matched, cause
new PAD and SPD entries to be created binding the matching peer's IP
address and BTNS ID (i.e., public key) by using the PUBLICKEY ID
selector to match on the peer's public key. Entries created this way
have to be persistent, for some value of "persistent," though we
RECOMMEND that "persistent" mean "until manually removed."
Williams Expires February 2, 2006 [Page 6]
Internet-Draft BTNS IPsec August 2005
4. Security Considerations
Unauthenticated security association negotiation is subject to MITM
attacks and should be used with care. Where security infrastructures
are lacking this may indeed be better than nothing.
Use with applications that bind authentication at higher network
layers to secure channels at lower layers may provide one secure way
to use unauthenticated IPsec, but this is not specified herein and,
furthermore, implies native mode IPsec, which this document mostly
ignores. For such applications a possible benefit of using
unauthenticated IPsec may be the ability to use IPsec, with
associated special purpose cryptographic hardware, for transport
protection without having to deploy an authentication infrastructure
suitable for use with IKE. "Channel binding" is a technology
currently being defined elsewhere at the IETF and, therefore, outside
the scope of this document.
Since channel binding is typically performed once per-session such
applications need a way to construct "IPsec channels" using IPsec to
protect common transport protocols layered above IP. This means that
channel binding applications require application programming
interfaces (APIs) for binding datagrams of connection-less transports
(e.g., UDP) and/or entire connections for connection-oriented
transports (e.g., TCP) to a single set of of IPsec SAs, authenticated
or otherwise, where each such SA re-keys a prior SA in the same set
or is established using the same ID and, when unauthenticated IKE is
used, using the same public key. Such APIs are not specified herein;
the work to specify such APIs is ongoing.
Creation of PAD and SPD entries in a leap-of-faith manner creates a
number of problems, most notably a denial-of-service (DoS) attack
where an attacker can consume all address available for use in this
way. Such attacks need not even be conscious: device mobility can
achieve the same effect. A possible mitigation for this problem
would be to allow leap-of-faith BTNS to be used only for address
ranges where no mobile devices are expected and which attackers may
not be able to take over for other reasons. Another possible
mitigation would be to prompt a user about each leap-of-faith BTNS
policy entry instantiation.
[...]
5. Normative
[I-D.ietf-btns-prob-and-applic]
Touch, J., "Problem and Applicability Statement for Better
Than Nothing Security (BTNS)",
Williams Expires February 2, 2006 [Page 7]
Internet-Draft BTNS IPsec August 2005
draft-ietf-btns-prob-and-applic-00 (work in progress),
July 2005.
[I-D.ietf-ipsec-ikev2]
Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
draft-ietf-ipsec-ikev2-17 (work in progress),
October 2004.
[I-D.ietf-ipsec-rfc2401bis]
Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", draft-ietf-ipsec-rfc2401bis-06 (work
in progress), April 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet
Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
Williams Expires February 2, 2006 [Page 8]
Internet-Draft BTNS IPsec August 2005
Author's Address
Nicolas Williams
Sun Microsystems
5300 Riata Trace Ct
Austin, TX 78727
US
Email: Nicolas.Williams@sun.com
Williams Expires February 2, 2006 [Page 9]
Internet-Draft BTNS IPsec August 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Williams Expires February 2, 2006 [Page 10]
