<?xml version="1.0" encoding="UTF-8"?>
<!-- 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml' -->
<!-- vim commands to change references URLs -->
<!-- :.,$ s/iquad.central\/\~nw141292/www.sandelman.ca\/public\/rfc/ -->
<!-- :.,$ s/www.sandelman.ca\/public\/rfc/iquad.central\/\~nw141292/ -->
<!-- :.,$ s/http:\/\/www.sandelman.ca\/public\/rfc/\/home\/nw141292\/public_html/  -->
<!-- :.,$ s/\/home\/nw141292\/public_html/http:\/\/www.sandelman.ca\/public\/rfc/  -->
<!-- :.,$ s/PUBLIC ''/SYSTEM/ -->
<!-- :.,$ s/SYSTEM/PUBLIC ''/ --> encoding="US-ASCII"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
    <!ENTITY rfc2025 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2025.xml'>
    <!ENTITY rfc0854 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0854.xml'>
    <!ENTITY rfc1035 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml'>
    <!ENTITY rfc3008 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3008.xml'>
    <!ENTITY rfc2203 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2203.xml'>
    <!ENTITY rfc2623 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2623.xml'>
    <!ENTITY rfc3530 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3530.xml'>
    <!ENTITY rfc2478 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2478.xml'>
    <!ENTITY rfc2743 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2743.xml'>
    <!ENTITY rfc2744 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2744.xml'>
    <!ENTITY rfc1964 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1964.xml'>
    <!ENTITY rfc2401 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2401.xml'>
    <!ENTITY rfc2408 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2408.xml'>
    <!ENTITY rfc2409 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2409.xml'>
    <!ENTITY rfc4251 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4251.xml'>
    <!ENTITY rfc4301 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4301.xml'>
    <!ENTITY rfc4306 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4306.xml'>
    <!ENTITY rfc5056 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5056.xml'>
    <!ENTITY btns-applic PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-btns-prob-and-applic.xml'>
    <!ENTITY connection-latching PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-btns-connection-latching'>
]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc toc="yes" ?>
<?rfc tocindent="no" ?>
<?rfc autobreaks="no" autobreaks="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" strict="no" ?>
<?rfc rfcedstyle="yes" ?>
<?rfc strict="yes" subcompact="no" ?>

<rfc category="std" ipr="full3978" docName="draft-ietf-btns-core-07.txt"> number="XXXX" category="std">
    <front>
	<title abbrev="BTNS IPsec">Better-Than-Nothing-Security: An Unauthenticated Mode of IPsec</title>
	<author initials='N.' surname="Williams" fullname='Nicolas
	    Williams'>
	    <organization abbrev="Sun">Sun Microsystems</organization>
	    <address>
		<postal>
		    <street>5300 Riata Trace Ct</street>
		    <city>Austin</city> <region>TX</region>
		    <code>78727</code> <country>US</country>
		</postal>
		<email>Nicolas.Williams@sun.com</email>
	    </address>
	</author>
	<author initials="M." surname="Richardson" fullname="Michael C.
	    Richardson">
	    <organization abbrev="SSW">Sandelman Software
		Works</organization>
	    <address>
		<postal>
		    <street>470 Dawson Avenue</street>
		    <city>Ottawa</city>
		    <region>ON</region>
		    <code>K1Z
			5V7</code>
		    <country>CA</country>
		</postal>
		<email>mcr@sandelman.ottawa.on.ca</email>
		<uri>http://www.sandelman.ottawa.on.ca/</uri>
	    </address>
	</author>
        <date month="August" month="October" year="2008"/>
	<area>Security</area>
	<workgroup>NETWORK WORKING GROUP</workgroup>

<!--[rfced] Please insert any keywords (beyond those that appear in
    the title) for use on http://www.rfc-editor.org/rfcsearch.html. -->

	<keyword>Internet-Draft</keyword>
	<abstract><t>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 changes to
                IKEv2 bits-on-the-wire
		are required, but Peer Authorization Database
		(PAD) and Security Policy Database (SPD) extensions are
		specified.  Unauthenticated IPsec is herein referred to
		by its popular acronym, "BTNS" (Better Than Nothing
		Security).</t>
	</abstract>
    </front>

    <middle>
        <section title="Introduction">

	    <t>Here we describe how to establish unauthenticated IPsec
		SAs using IKEv2 <xref target="RFC4306"/> and
		unauthenticated public keys.  No new on-the-wire
		protocol elements are added to IKEv2.</t>

	    <t>The <xref target="RFC4301"/> processing model is
		assumed.</t>

	    <t>This document does not define an opportunistic BTNS mode
		of IPsec whereby nodes may fallback to unprotected IP
		when their peers do not support IKEv2, nor does it
		describe "leap-of-faith" modes, modes or "connection
		latching."</t>

	    <t>See <xref target="I-D.ietf-btns-prob-and-applic"/> target="ProbApp"/> for
		the applicability and uses of BTNS and definitions of
		these terms.</t>

	    <t>This document describes BTNS in terms of IKEv2 and <xref
		    target="RFC4301"/>'s concepts.  There is no reason
		why the same methods cannot be used with IKEv1 <xref
		    target="RFC2408"/>
		    target="RFC2408"/>, <xref target="RFC2409" /> />, and
		<xref target="RFC2401" />, />; however, those specifications
		do not include the PAD concepts, and therefore it may
		not be possible to implement BTNS on all compliant
		RFC2401 implementations.</t>

	    <section title="Conventions used Used in this document"> This Document">
		<t>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 <xref target="RFC2119"/>.</t>
	    </section>
        </section>

	<section anchor="core" title="BTNS">
	    <t>The IPsec processing model is hereby modified as follows:
		<list style='symbols'>
		    <t>A new ID type is added, 'PUBLICKEY'; added: 'PUBLICKEY'.  IDs of this
			type have public keys as values.  This ID type
			is not used on the wire.</t>

		    <t>PAD entries that match on PUBLICKEY IDs are
			referred to as "BTNS PAD entries." entries".  All other
			PAD entries are referred to as "non-BTNS PAD
			entries."</t>
			entries".</t>

		    <t>BTNS PAD entries may match on specific peer
			PUBLICKEY IDs (or public key fingerprints), fingerprints) or
			on all peer public keys.  The latter is referred
			to as the "wildcard BTNS PAD entry."</t> entry".</t>

		    <t>BTNS PAD entries MUST logically (see below)
			follow all other PAD entries (the PAD being an
			ordered list).</t>

		    <t>At most one wildcard BTNS PAD entry may appear in
			the PAD, and, if present, MUST be the last entry
			in the PAD (see below).</t>

		    <t>Any peer that uses an IKEv2 AUTH method involving
			a digital signature (made with a private key to
			a public key cryptosystem) may match a BTNS PAD
			entry, provided that it matches no non-BTNS PAD
			entries.  Suitable AUTH methods as of August
			2007 are: RSA Digital Signature (method #1) and
			DSS Digital Signature (method #3); see <xref
			    target="RFC4306"/>, section 3.8.</t>

		    <t>A BTNS capable BTNS-capable implementation of IPsec will first
			search the PAD for non-BTNS entries matching a
			peer's ID.  If no matching non-BTNS PAD entries
			are found found, then the peer's ID MUST then be
			coerced to be of 'PUBLICKEY' type with the
			peer's public key as its value and the value.  The PAD is
			then searched again for matching BTNS PAD
			entries.  This ensures that BTNS PAD entries
			logically follow non-BTNS PAD entries.  A single
			PAD search that preserves these semantics is
			allowed.</t>

		    <t>A peer that matches a BTNS PAD entry is referred
			to as a "BTNS peer." peer".  Such a peer is
			"authenticated" by verifying that the signature
			in its IKEv2 AUTH payload with the public key
			from the peer's CERT payload.</t>

		    <t>Of course, if no matching PAD entry is found,
			then the IKE SA is rejected as usual.</t>

		    <t>A new flag for SPD entries: 'BTNS_OK'.  Traffic
			to/from peers that match the BTNS PAD entry will
			match only SPD entries that have the BTNS_OK
			flag set.  The SPD may be searched by address or
			by ID (of type PUBLICKEY, PUBLICKEY for BTNS peers), as
			per the IPsec processing model <xref
			    target="RFC4301"/>; searching
			    target="RFC4301"/>.  Searching by ID in this
			case requires creation of SPD entries that are
			bound to public key values (this could be used
			to build "leap-of-faith" behavior, <xref
			    target="I-D.ietf-btns-prob-and-applic"/>
			    target="ProbApp"/>
			<xref target="lof" /> behaviour, />, for
			example).</t>

		</list>
	    </t>

	    <t>Nodes MUST reject IKE_SA proposals from peers that match
		non-BTNS PAD entries but fail to authenticate
		properly.</t>

	    <t>Nodes wishing to be treated as BTNS nodes by their peers
		MUST include bare public key CERT payloads.  Currently
		only bare RSA public key CERT payloads are defined,
		which means that BTNS works only with RSA public keys at
		this time (see "Raw RSA Key" in section 3.6 of <xref
		    target='RFC4306'/>).  Nodes MAY also include any
		number of certificates that bind the same public key.
		These certificates need not to have been pre-shared with
		their peers (e.g., because ephermal, self-signed).  RSA
		keys for use in BTNS may be generated at any time, but
		"connection latching" <xref
		    target="I-D.ietf-btns-connection-latching"/>
		    target="ConnLatch"/>
		requires that they remain constant between IKEv2
		exchanges that are used to establish SAs for latch