[anonsec] comments on the BTNS core I-D
mcr at sandelman.ca (Michael Richardson) Thu, 26 July 2007 05:20 UTC
From: "mcr at sandelman.ca"
Date: Thu, 26 Jul 2007 00:20:09 -0500
Subject: [anonsec] comments on the BTNS core I-D
In-Reply-To: <p06240505c2cd5414684e@[172.28.170.76]>
References: <p06240505c2cd5414684e@[172.28.170.76]>
Message-ID: <f89aup$pa$1@sea.gmane.org>
Stephen Kent wrote:
> Sorry I didn't get these out sooner.
thank you very much.
Nico and I printed your PDF and worked with it from 4pm to 9pm tonight.
(diff -u output would have been much easier to deal with)
Trivial stuff: We fixed all the [A] notation to consistently talk
about hosts with [] around them. Thank you for your
suggestions on slightly different choices in english.
Most importantly, we did split up most of the 4-line
sentences.
Important things: a number of things we removed because references to
documents which now say things better made sense.
I attach a diff below.
The only thing we didn't resolve was your comment: "No mention of what form
of ID C asserted (i)n its IKE exchange with SG-A"
(this refers to page 7, point 4, "C does not match PAD entries..."
This is an important question. We weren't sure we understood the question.
We aren't sure that it matters, but we want to understand what concerns
you might have behind the question.
We think that the the only things that matters is that
[C] can't assert [Q]'s identity, or [B]'s identity, because those IDs are in
the PAD as non-BTNS, and therefore [SG-A] must have some way to positively
identify those nodes public keys. So, C can't assert itself as being [C] or
[Q] without the appropriate private key. That's standard IPsec processing.
Was that your concern? Or something else.
The diff, change bar version at:
http://www.sandelman.ca/SSW/ietf/ipsec/btns/ietf-btns-core-04-change.txt
--- ietf-btns-core-03.txt 2007-07-25 22:41:12.000000000 -0500
+++ ietf-btns-core-04.txt 2007-07-25 20:41:14.000000000 -0500
@@ -1,16 +1,15 @@
-
NETWORK WORKING GROUP N. Williams
Internet-Draft Sun
Intended status: Standards Track M. Richardson
-Expires: October 3, 2007 SSW
- April 2007
+Expires: January 26, 2008 SSW
+ July 25, 2007
Better-Than-Nothing-Security: An Unauthenticated Mode of IPsec
- draft-ietf-btns-core-03.txt
+ draft-ietf-btns-core-04.txt
Status of this Memo
@@ -35,7 +34,7 @@
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
- This Internet-Draft will expire on October 3, 2007.
+ This Internet-Draft will expire on January 26, 2008.
Copyright Notice
@@ -53,9 +52,9 @@
-Williams & Richardson Expires October 3, 2007 [Page 1]
+Williams & Richardson Expires January 26, 2008 [Page 1]
-Internet-Draft BTNS IPsec April 2007
+Internet-Draft BTNS IPsec July 2007
Abstract
@@ -64,10 +63,10 @@
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 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).
+ 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).
Table of Contents
@@ -75,20 +74,20 @@
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions used in this document . . . . . . . . . . . . . 3
2. BTNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . 6
- 3.1. Example #1: sgA . . . . . . . . . . . . . . . . . . . . . . 6
- 3.2. Example #2: Q . . . . . . . . . . . . . . . . . . . . . . . 8
- 3.3. Example #3: C . . . . . . . . . . . . . . . . . . . . . . . 9
- 3.4. Miscaellaneous examples . . . . . . . . . . . . . . . . . . 9
+ 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.1. Example #1: A security gateway . . . . . . . . . . . . . . . 5
+ 3.2. Example #2: A mixed end-system . . . . . . . . . . . . . . . 7
+ 3.3. Example #3: A BTNS-only system . . . . . . . . . . . . . . . 8
+ 3.4. Miscellaneous comments . . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . 10
4.1. Connection-Latching and Channel Binding . . . . . . . . . . 10
4.2. Leap-of-Faith (LoF) for BTNS . . . . . . . . . . . . . . . . 10
- 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12
- 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
- 6.1. Normative References . . . . . . . . . . . . . . . . . . . . 13
- 6.2. Informative References . . . . . . . . . . . . . . . . . . . 13
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14
- Intellectual Property and Copyright Statements . . . . . . . 15
+ 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11
+ 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 6.1. Normative References . . . . . . . . . . . . . . . . . . . . 12
+ 6.2. Informative References . . . . . . . . . . . . . . . . . . . 12
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13
+ Intellectual Property and Copyright Statements . . . . . . . 14
@@ -109,27 +108,33 @@
-Williams & Richardson Expires October 3, 2007 [Page 2]
+Williams & Richardson Expires January 26, 2008 [Page 2]
-Internet-Draft BTNS IPsec April 2007
+Internet-Draft BTNS IPsec July 2007
1. Introduction
Here we describe how to establish unauthenticated IPsec SAs using
- IKEv1 [RFC2408] [RFC2409] or IKEv2 [RFC4306] and unauthenticated
- public keys. No new on-the-wire protocol elements are added to IKE
- or IKEv2.
+ IKEv2 [RFC4306] and unauthenticated public keys. No new on-the-wire
+ protocol elements are added to IKEv2.
The [RFC4301] processing model is assumed.
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, nor does it describe "leap-of-faith" modes, or
+ whereby nodes may fallback to unprotected IP when their peers do not
+ support IKEv2, nor does it describe "leap-of-faith" modes, or
"connection latching."
See [I-D.ietf-btns-prob-and-applic] for the applicability and uses of
- BTNS.
+ BTNS and definitions of these terms.
+
+ This document describes BTNS in terms of IKEv2 and [RFC4301]'s
+ concepts. There is no reason why the same methods cannot be used
+ with IKEv1 [RFC2408] [RFC2409] and [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.
1.1. Conventions used in this document
@@ -159,136 +164,74 @@
-
-
-
-
-
-
-Williams & Richardson Expires October 3, 2007 [Page 3]
+Williams & Richardson Expires January 26, 2008 [Page 3]
-Internet-Draft BTNS IPsec April 2007
+Internet-Draft BTNS IPsec July 2007
2. BTNS
- The IPsec processing model, IKE and IKEv2 are hereby modified as
- follows:
+ The IPsec processing model is hereby modified as follows:
o A new ID type is added, 'PUBLICKEY'; IDs of this type have public
keys as values. This ID type is not used on the wire.
- o A BTNS-specific PAD entry. This entry is intended to be the last
- entry in the PAD when BTNS is enabled. A peer that matches no
- other PAD entries is to be "authenticated" by verifying that the
- signature in its AUTH (or SIG) payload in the IKEv2 (or v1)
- exchange with the public key from the peer's CERT payload. The
- peer's ID MUST then be coerced to be of 'PUBLICKEY' type with the
- peer's public key as its value.
+ o A BTNS-specific PAD entry. This entry MUST be the last entry in
+ the PAD when BTNS is enabled. A peer that matches no other PAD
+ entries is to be "authenticated" by verifying that the signature
+ in its AUTH payload in the IKEv2 exchange with the public key from
+ the peer's CERT payload. The peer's ID MUST then be coerced to be
+ of 'PUBLICKEY' type with the peer's public key as its value.
o A new flag for SPD entries: 'BTNS_OK'. Traffic to/from peers that
- match the BTNS PAD entry will only match SPD entries that have the
+ 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, of course, for BTNS peers), as per the IPsec
- processing model [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" behaviour, for example).
+ type PUBLICKEY, for BTNS peers), as per the IPsec processing model
+ [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" [I-D.ietf-btns-prob-and-applic] Section 4.2
+ behaviour, for example).
Nodes MUST reject IKE_SA proposals from peers that match non-BTNS PAD
entries but fail to authenticate properly.
- Nodes wishing to be treated as BTNS nodes by their peers SHOULD use
- bare RSA key CERT payloads and MAY use certificates known not to have
- been pre-shared with their peers or outside their trust anchors
- (e.g., self-signed certificates). RSA keys for use in BTNS may be
- generated at any time, but "connection latching"
- [I-D.ietf-btns-connection-latching] requires that they remain
- constant between IKE exchanges setting up SAs for latched
- connections.
-
- To preserve standard IPsec access control semantics BTNS responders
- MUST NOT allow BTNS peers to assert addresses which could be asserted
- by non-BTNS peers. This can be achieved by processing the PAD in
- order both, when peers authenticate and when BTNS peers negotiate
- child SAs -- in the first case the PAD is searched for a matching PAD
+ Nodes wishing to be treated as BTNS nodes by their peers MUST include
+ bare RSA key CERT payloads. 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" [I-D.ietf-btns-connection-latching]
+ requires that they remain constant between IKEv2 exchanges that are
+ used to establish SAs for latched connections.
+
+ To preserve standard IPsec access control semantics the BTNS PAD
+ entry MUST be last (lowest priority), and it MUST have ID constraints
+ that do not overlap those of other PAD entries.
+
+ This can easily be implemented by searching the PAD twice. Once when
+ BTNS peers authenticate and a second time when BTNS peers negotiate
+ child SAs. In the first pass the PAD is searched for a matching PAD
entry as usual, and in the second it is searched to make sure that
BTNS peers' asserted child SA traffic selectors do not conflict with
- non-BTNS PAD entries. Note that in general, if there are multiple
- PAD entries with wildcard matching on peer ID then all but the last
- one should constrain the traffic selectors for matching peers.
-
- Note that nodes may unwittingly match peers' BTNS PAD entries and be
-
-
-
-Williams & Richardson Expires October 3, 2007 [Page 4]
-
-Internet-Draft BTNS IPsec April 2007
-
-
- authenticated as BTNS nodes. This may be used in specifying the
- "latching" of traffic flows to peer IDs
- [I-D.ietf-btns-connection-latching].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+ non-BTNS PAD entries.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams & Richardson Expires October 3, 2007 [Page 5]
+Williams & Richardson Expires January 26, 2008 [Page 4]
-Internet-Draft BTNS IPsec April 2007
+Internet-Draft BTNS IPsec July 2007
3. Usage Scenarios
In order to explain the above rules a number of scenarios will be
- postulated. The goal here is to demonstrate that the above rules are
- both sufficient and required.
+ examined. The goal here is to persuade the reader that the above
+ rules are both sufficient and necessary.
- To explain the scenarios a reference diagram describing a canonical
+ To explain the scenarios a reference diagram describing an example
network will be used. It is as follows:
[Q] [R]
@@ -305,45 +248,50 @@
systems are security gateways: SG-A, SG-B, protecting networks on
which [A] and [B] reside. There is a node [Q] which is IPsec and
BTNS capable, and node [R] is a simple node, with no IPsec or BTNS
- capability. Nodes [C] and [D] are BTNS capable. We will examine
- interactions between the BTNS enabled nodes, and the IPsec enabled
- nodes.
+ capability. Nodes [C] and [D] are BTNS capable.
+
+ Nodes [C] and [Q] have fixed addresses. Node [D] has a non-fixed
+ address.
- Nodes C and Q have a fixed addresses. Node D non-fixed addresses.
+ We will examine how these various nodes communicate with node SG-A,
+ and/or how SG-A rejects communications with some such nodes. In the
+ first example, we examine SG-A's point of view. In the second
+ example we look at Q's point of view. In the third example we look
+ at C's point of view.
PI is the Public Internet ("The Wild").
-3.1. Example #1: sgA
+3.1. Example #1: A security gateway
- The machine that we will care about will be [SG-A], a firewall device
- of some kind which we wish to configure to respond to BTNS
- connections from [C]
+ The machine that we will care in this example is [SG-A], a firewall
+ device of some kind which we wish to configure to respond to BTNS
+ connections from [C].
- SG-A has the following "VPN" PAD and SPD entries:
+ SG-A has the following PAD and SPD entries:
Child SA
Rule Remote ID IDs allowed SPD Search by
---- --------- ----------- -------------
- 1 <B's ID> <B's network> by-IP
- 2 <Q's ID> <Q's host> by-IP
- 3 PUBLICKEY:any ANY by-IP
-
- The last entry is the BTNS entry.
-Williams & Richardson Expires October 3, 2007 [Page 6]
+Williams & Richardson Expires January 26, 2008 [Page 5]
-Internet-Draft BTNS IPsec April 2007
+Internet-Draft BTNS IPsec July 2007
+
+ 1 <B's ID> <B's network> by-IP
+ 2 <Q's ID> <Q's host> by-IP
+ 3 PUBLICKEY:any ANY by-IP
+
+ The last entry is the BTNS entry.
Figure 2: SG-A PAD table
- Here <ANY> is any address that is not part of A's network, and is not
- claimed by any other entry. Note that sgA's PAD entry has one and
- only one wildcard PAD entry: the BTNS catch-all PAD entry, so, as
- described in Section 2.
+ Note that [SG-A]'s PAD entry has one and only one wildcard PAD entry:
+ the BTNS catch-all PAD entry as the last entry, as described in
+ Section 2.
<Child SA IDs allowed> and <SPD Search by> are from [RFC4301] section
4.4.3
@@ -352,108 +300,114 @@
Rule Local Remote Next Layer BTNS Action
addr addr Protocol ok
---- ----- ------ ---------- ---- -----------------------
- 1 A R ANY N/A BYPASS
- 2 A Q ANY no PROTECT(ESP,tunnel,AES,
+ 1 [A] [R] ANY N/A BYPASS
+ 2 [A] [Q] ANY no PROTECT(ESP,tunnel,AES,
SHA256)
- 3 A B-net ANY no PROTECT(ESP,tunnel,AES,
+ 3 [A] B-net ANY no PROTECT(ESP,tunnel,AES,
SHA256)
- 4 A ANY ANY yes PROTECT(ESP,transport,
+ 4 [A] ANY ANY yes PROTECT(ESP,transport,
integr+conf)
- Figure 3: SG-A SPD table
+ Figure 3: [SG-A] SPD table
- The processing by sgA of various peers then is as follows:
+ The processing by [SG-A] of SA establishment attempts by various
+ peers is as follows:
- o Q does not match PAD entry #1, but does match PAD entry #2; PAD
- processing stops, then the SPD is searched by Q's ID to find entry
- #2; CHILD SAs are then allowed that have sgA's and Q's addresses
- as the end-point addresses.
+ o [Q] does not match PAD entry #1, but does match PAD entry #2; PAD
+ processing stops, then the SPD is searched by [Q]'s ID to find
+ entry #2; CHILD SAs are then allowed that have [SG-A]'s and [Q]'s
+ addresses as the end-point addresses.
+
+ o [SG-B] matches PAD entry #1; PAD processing stops, then the SPD is
+ searched by [SG-B]'s ID to find SPD entry #3; CHILD SAs are then
+ allowed that have [SG-A]'s address and any addresses from B's
+ network as the end-point addresses.
- o sgB matches PAD entry #1; PAD processing stops, then the SPD is
- searched by sgB's ID to find SPD entry #3; CHILD SAs are then
- allowed that have sgA's address and any addresses from B's network
- as the end-point addresses.
+ o [R] does not initiate any IKE SAs; its traffic to [A] is bypassed
+ by SPD entry #1.
- o R does not initiate any IKE_SAs; its traffic to A is bypassed by
- SPD entry #1.
-
- o C does not match PAD entries #1 or #2, but does match entry #3,
- the BTNS wildcard PAD entry; the SPD is searched by C's address
+ o [C] does not match PAD entries #1 or #2, but does match entry #3,
+ the BTNS wildcard PAD entry; the SPD is searched by [C]'s address
and SPD entry #4 is matched. CHILD SAs are then allowed that have
- sgA's address and C's address as the end-point addresses provided
- that C's address is neither Q's nor any of B's (see Section 2).
-
- o Rogue BTNS nodes attempting to assert Q's or B's addresses will
- either match the PAD entries for Q or B and fail to authenticate
- as Q or B, in which case they are rejected, or they will match PAD
-Williams & Richardson Expires October 3, 2007 [Page 7]
+Williams & Richardson Expires January 26, 2008 [Page 6]
-Internet-Draft BTNS IPsec April 2007
+Internet-Draft BTNS IPsec July 2007
- entry #3 but will not be allowed to create CHILD SAs with Q's or
- B's addresses as traffic selectors.
+ [SG-A]'s address and [C]'s address as the end-point addresses
+ provided that [C]'s address is neither [Q]'s nor any of [B]'s (see
+ Section 2).
- o Rogue BTNS nodes attempting to assert C's address are allowed.
- Protection for C requires additional bindings of C's specific BTNS
- ID (that is, its public key) to its traffic flows through
- connection-latching and channel binding, or leap-of-faith, none of
- which are described here.
+ o A rogue BTNS node attempting to assert [Q]'s or [B]'s addresses
+ will either match the PAD entries for [Q] or [B] and fail to
+ authenticate as [Q] or [B], in which case they are rejected, or
+ they will match PAD entry #3 but will not be allowed to create
+ CHILD SAs with [Q]'s or [B]'s addresses as traffic selectors.
-3.2. Example #2: Q
+ o A rogue BTNS nodes attempting to assert [C]'s address will
+ succeed. Protection for [C] requires additional bindings of [C]'s
+ specific BTNS ID (that is, its public key) to its traffic flows
+ through connection-latching and channel binding, or leap-of-faith,
+ none of which are described here.
- Q is either a BITS or native IPsec implementation; if it is a native
- implementation it may have IPsec-aware applications, specifically
- NFSv4 (TCP port 2049).
+3.2. Example #2: A mixed end-system
- In any case, Q wants to communicate with A generally, and with BTNS
- peers for NFSv4 only. It's PAD and SPD are configured as follows:
+ [Q] is an NFSv4 server.
+
+ [Q] is a native IPsec implementation, and it's NFSv4 implementation
+ is IPsec-aware.
+
+ [Q] wants to protect all traffic with [A]. [Q] also wants to protect
+ NFSv4 traffice with all peers. It's PAD and SPD are configured as
+ follows:
Child SA
Rule Remote ID IDs allowed SPD Search by
---- --------- ----------- -------------
- 1 <A's ID> <A's address> by-IP
+ 1 <[A]'s ID> <[A]'s address> by-IP
2 PUBLICKEY:any ANY by-IP
The last entry is the BTNS entry.
- Figure 4: Q PAD table
+ Figure 4: [Q] PAD table
Rule Local Remote Next Layer BTNS Action
addr addr Protocol ok
---- ----- ------ ---------- ---- -----------------------
- 1 Q A ANY no PROTECT(ESP,tunnel,AES,
+ 1 [Q] [A] ANY no PROTECT(ESP,tunnel,AES,
SHA256)
- 2 Q ANY ANY yes PROTECT(ESP,transport,
- and integr+conf)
- port
- 2049
-
- Figure 5: SG-A SPD table
+ 2 [Q] ANY ANY yes PROTECT(ESP,transport,
+ with integr+conf)
+ port 2049
- The same analysis shown above in Section 3.1 applies here with
- respect to sgA, C and rogue peers, except that C is allowed only
- access to the NFSv4 service on Q. Additionally sgB is treated as a
- BTNS peer as it is not known to Q, and therefore any host behind sgB
- can access the NFSv4 service on Q (and, because Q has no formal
- relationship with sgB, rogues can impersonate B).
-Williams & Richardson Expires October 3, 2007 [Page 8]
+Williams & Richardson Expires January 26, 2008 [Page 7]
-Internet-Draft BTNS IPsec April 2007
+Internet-Draft BTNS IPsec July 2007
+
+ Figure 5: [Q] SPD table
-3.3. Example #3: C
+ The same analysis shown above in Section 3.1 applies here with
+ respect to [SG-A], [C] and rogue peers. The second SPD entry permits
+ any BTNS capable node to negotiate a port-specific SA to port 2049,
+ the port on which NFSv4 runs. Additionally [SG-B] is treated as a
+ BTNS peer as it is not known to [Q], and therefore any host behind
+ [SG-B] can access the NFSv4 service on [Q]. As [Q] has no formal
+ relationship with [SG-B], rogues can impersonate [B] (i.e., assert
+ [B]'s addresses).
+
+3.3. Example #3: A BTNS-only system
- C only supports BTNS and wants to use BTNS to protect NFSv4 traffic.
- It's PAD and SPD are configured as follows:
+ [C] supports only BTNS and wants to use BTNS to protect NFSv4
+ traffic. It's PAD and SPD are configured as follows:
Child SA
@@ -461,7 +415,7 @@
---- --------- ----------- -------------
1 PUBLICKEY:any ANY by-IP
- The last entry is the BTNS entry.
+ The last (and only) entry is the BTNS entry.
Figure 6: Q PAD table
@@ -469,101 +423,53 @@
Rule Local Remote Next Layer BTNS Action
addr addr Protocol ok
---- ----- ------ ---------- ---- -----------------------
- 1 C ANY ANY yes PROTECT(ESP,transport,
- and integr+conf)
+ 1 [C] ANY ANY yes PROTECT(ESP,transport,
+ with integr+conf)
port
2049
- 2 C ANY ANY N/A BYPASS
+ 2 [C] ANY ANY N/A BYPASS
Figure 7: SG-A SPD table
-3.4. Miscaellaneous examples
-
- If sgA were not BTNS-capable then it would not have PAD and SPD
- entries #3 and #4, respectively. Then C would be rejected as usual
- under the standard IPsec model [RFC4301].
+ The analysis from Section 3.1 applies as follows:
- Similarly, if Q were not BTNS-capable then it would not have PAD and
- SPD entries #2. Then C would be rejected as usual under the standard
- IPsec model [RFC4301].
+ o Communication with [Q] on port 2049 matches SPD entry number 1.
+ This causes [C] to initiate an IKEv2 exchange with [Q]. The PAD
+ entry on [C] causes it to not care what identity [Q] asserts.
+ Further authentication (and channel binding) could occur within
+ the NFSv4 protocol.
+ o Communication with [A], [B] or any other internet machine
-
-
-
-
-
-
-
-
-
-
-Williams & Richardson Expires October 3, 2007 [Page 9]
+Williams & Richardson Expires January 26, 2008 [Page 8]
-Internet-Draft BTNS IPsec April 2007
+Internet-Draft BTNS IPsec July 2007
-4. Security Considerations
+ (including [Q]), occurs in the clear, so long as it is not on port
+ 2049.
- 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.
+ o All analysis about rogue BTNS nodes applies, but they can only
+ assert SAs for port 2049.
- 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.
-
- Use of multiple wildcard PAD entries can be problematic. Where it is
- important that addresses and node identities be tightly bound it is
- important that such PAD entries limit the addresses that matching
- peers can assert for their CHILD SAs to non-overlapping address
- spaces. In practice this may be difficult to configure; if it is not
- feasible to configure systems in this way then either BTNS should not
- be used or BTNS PAD entries should constrain matching peers only to
- using services for which authentication is not normally necessary or
- where IPsec-aware/connection-latching applications are used.
-
-4.1. Connection-Latching and Channel Binding
+3.4. Miscellaneous comments
- BTNS is subject to MITM attacks. One way to protect against MITM
- attacks subsequent to initial communications is to use "connection
- latching" [I-D.ietf-btns-connection-latching], whereby ULPs cooperate
- with IPsec in native IPsec implementations to bind individual packet
- flows to sequences of SAs whose end-point IDs (public keys, in the
- case of BTNS end-points) and other characteristics (e.g., quality of
- protection) must all be the same.
-
- MITMs can be detected by using application-layer authentication
- frameworks and/or mechanisms, such as the GSS-API [RFC2743], with
- channel binding [I-D.williams-on-channel-binding], where the channels
- to be bound to application-layer authentication are latched
- connections and where the channel bindings data strongly identify the
- end-points of the latched connection (e.g., the public keys of the
- end-points).
+ If [SG-A] were not BTNS-capable then it would not have PAD and SPD
+ entries #3 and #4, respectively in example #1. Then [C] would be
+ rejected as usual under the standard IPsec model [RFC4301].
-4.2. Leap-of-Faith (LoF) for BTNS
+ Similarly, if [Q] were not BTNS-capable then it would not have PAD
+ and SPD entries #2 in example #2. Then [C] would be rejected as
+ usual under the standard IPsec model [RFC4301].
- "Leap of faith" is the term generally used for the habit of accepting
- that a given key identifies a peer that one wanted to talk to without
- strong evidence for that proposition. Specifically this is a common
- mode of operation for Secure Shell [RFC4251] clients where, when a
- server is encountered for the first time the client may ask the user
- whether to accept the server's public key as its identity and, if so,
- records the server's name (as given by the user) and public key in a
- database.
-Williams & Richardson Expires October 3, 2007 [Page 10]
-
-Internet-Draft BTNS IPsec April 2007
- Leap of Faith can work in a similar way for BTNS nodes, but it is
- currently still being designed and specified by the IETF BTNS WG.
@@ -594,17 +500,54 @@
+Williams & Richardson Expires January 26, 2008 [Page 9]
+
+Internet-Draft BTNS IPsec July 2007
+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.
+ The BTNS PAD entry must be last and its child SA ID constraints must
+ be non-overlapping with any other PAD entry, as described in section
+ 2, in order to ensure that no BTNS peer can impersonate another IPsec
+ non-BTNS peer.
+4.1. Connection-Latching and Channel Binding
+ BTNS is subject to MITM attacks. One way to protect against MITM
+ attacks subsequent to initial communications is to use "connection
+ latching" [I-D.ietf-btns-connection-latching]. In connection
+ latching, ULPs cooperate with IPsec to bind discrete packet flows to
+ sequences of similar SAs. Connection latching requires native IPsec
+ implementations.
+ MITMs can be detected by using application-layer authentication
+ frameworks and/or mechanisms, such as the GSS-API [RFC2743], with
+ channel binding [I-D.williams-on-channel-binding]. IPsec "channels"
+ are nothing other than latched connnections.
+4.2. Leap-of-Faith (LoF) for BTNS
+ "Leap of faith" is the term generally used when a user accepts the
+ assertion that a given key identifies a peer on the first
+ communication, despite a lack of strong evidence for that assertion,
+ and then remembers this association for future communications.
+ Specifically this is a common mode of operation for Secure Shell
+ [RFC4251] client. When a server is encountered for the first time
+ the Secure Shell client may ask the user whether to accept the
+ server's public key. If so, records the server's name (as given by
+ the user) and public key in a database.
+ Leap of faith can work in a similar way for BTNS nodes, but it is
+ currently still being designed and specified by the IETF BTNS WG.
@@ -613,9 +556,9 @@
-Williams & Richardson Expires October 3, 2007 [Page 11]
+Williams & Richardson Expires January 26, 2008 [Page 10]
-Internet-Draft BTNS IPsec April 2007
+Internet-Draft BTNS IPsec July 2007
5. IANA Considerations
@@ -669,9 +612,9 @@
-Williams & Richardson Expires October 3, 2007 [Page 12]
+Williams & Richardson Expires January 26, 2008 [Page 11]
-Internet-Draft BTNS IPsec April 2007
+Internet-Draft BTNS IPsec July 2007
6. References
@@ -694,14 +637,17 @@
[I-D.ietf-btns-prob-and-applic]
Touch, J., "Problem and Applicability Statement for Better
Than Nothing Security (BTNS)",
- draft-ietf-btns-prob-and-applic-05 (work in progress),
- February 2007.
+ draft-ietf-btns-prob-and-applic-03 (work in progress),
+ June 2006.
[I-D.williams-on-channel-binding]
Williams, N., "On the Use of Channel Bindings to Secure
Channels", draft-williams-on-channel-binding-00 (work in
progress), August 2006.
+ [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
+ Internet Protocol", RFC 2401, November 1998.
+
[RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet
Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998.
@@ -722,12 +668,9 @@
-
-
-
-Williams & Richardson Expires October 3, 2007 [Page 13]
+Williams & Richardson Expires January 26, 2008 [Page 12]
-Internet-Draft BTNS IPsec April 2007
+Internet-Draft BTNS IPsec July 2007
Authors' Addresses
@@ -781,9 +724,9 @@
-Williams & Richardson Expires October 3, 2007 [Page 14]
+Williams & Richardson Expires January 26, 2008 [Page 13]
-Internet-Draft BTNS IPsec April 2007
+Internet-Draft BTNS IPsec July 2007
Full Copyright Statement
@@ -837,6 +780,5 @@
-Williams & Richardson Expires October 3, 2007 [Page 15]
+Williams & Richardson Expires January 26, 2008 [Page 14]
-
- [anonsec] comments on the BTNS core I-D Stephen Kent
- [anonsec] comments on the BTNS core I-D Sam Hartman
- [anonsec] comments on the BTNS core I-D Michael Richardson
- [anonsec] comments on the BTNS core I-D Stephen Kent
- [anonsec] comments on the BTNS core I-D Michael Richardson
- [anonsec] comments on the BTNS core I-D Michael Richardson
- [anonsec] comments on the BTNS core I-D Nico
- [anonsec] comments on the BTNS core I-D Stephen Kent
- [anonsec] comments on the BTNS core I-D Nicolas Williams
- [anonsec] comments on the BTNS core I-D Derrell Piper
- [anonsec] comments on the BTNS core I-D Stephen Kent
- [anonsec] comments on the BTNS core I-D Nicolas Williams
- [anonsec] comments on the BTNS core I-D Nicolas Williams
- [anonsec] comments on the BTNS core I-D Stephen Kent
- [anonsec] comments on the BTNS core I-D Nicolas Williams
- [anonsec] comments on the BTNS core I-D Derrell Piper
- [anonsec] comments on the BTNS core I-D Nicolas Williams