Subject: [anonsec] comments on the BTNS core I-D

From: kent at bbn.com (Stephen Kent)
Date: Wed, 25 Jul 2007 15:25:54 -0400

Sorry I didn't get these out sooner.

Steve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: draft-ietf-btns-core-03.pdf
Type: application/octet-stream
Size: 219583 bytes
Desc: not available
Url : http://mailman.postel.org/pipermail/anonsec/attachments/20070725/76d81da0/draft-ietf-btns-core-03-0001.obj

---

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Wed, 25 Jul 2007 16:38:32 -0400

This document has already been submitted for AD review.  Chairs, if
you want me to return to the WG then please instruct me to do so.

---

From: mcr at sandelman.ca (Michael Richardson)
Date: Thu, 26 Jul 2007 00:20:09 -0500

> 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]
  
-

---

From: kent at bbn.com (Stephen Kent)
Date: Thu, 26 Jul 2007 14:48:23 -0400

>(diff -u output would have been much easier to deal with)

sorry. I always import the text version of an I-D into MS Word, where 
I can mark it up and add comments and have both sorts of changes be 
easily visible.  I then convert to a PDF, so everyone can read the 
results, and still see the changes.  As someone who does not 
regularly use Unix for text editing, I don't find diff's helpful, 
something reaffirmed by looking at the diff you provided at the end 
of this message :-).

>...

my comment appears on page 7, in reference to example #1. I asked the 
question because the PAD description in 4301 says how to search the 
PAD based on matching the ID asserted in IKE against the PAD. there 
are words early in this document (page 4) about the new ID type 
"PUBLICKEY" and the need to coerce the ID offered by a BTNS peer into 
this new ID type, which is never transferred over the wire via IKE. 
(That raises the question of whether we ought to describe this as an 
IKE ID type, but I'll let Charlue Kaufman comment on that later, if 
he wishes.)

So, I was wondering if the kind of ID asserted by C in KE was 
relevant to the example, or any example, based on the wording here. 
maybe what should happen is to refine the description of the modified 
PAD search algorithm in section 2, which is rather brief. Maybe it 
could say something  along the lines of:

	- If the ID asserted by a peer does not match any PAD entry, 
then a BTNS-enabled IPsec implementation replaces the ID with into 
the new ID of type "PUBLICKEY" that is created by extracting the 
public key from the IKE CERT (or ??) payload

	- the PAD is searched again, using this new ID type and value

	- if there is a match, the associated PAD entry (which will 
be a BTNS entry) is used to control the SPD search

	- if there is no match, the IKE SA is rejected

That sort of text would avoid the ambiguity that triggered my question.

Steve

---

From: mcr at sandelman.ca (Michael Richardson)
Date: Thu, 26 Jul 2007 14:19:28 -0500

> something reaffirmed by looking at the diff you provided at the end 

   I understand. For those of us who do use it, it is very immediately
visible what is going on, and there are some who can apply diffs in their head.

>> identify those nodes public keys. So, C can't assert itself as being [C] or
                                                                         [B]

> IKE ID type, but I'll let Charlue Kaufman comment on that later, if 

   The public key *is* transmitted on the wire in a slightly mis-named "CERT" 
payload, of type "Raw RSA Key                         11". This was first 
stated on page 4 of btns-core, (and page 59 of RFC2406).

> 	- if there is no match, the IKE SA is rejected

Good text. We'll use it.
Q: does this relax the requirement for the PAD entry to be lowest priority?
The two searches can be implemented with a single scan, with a priority based 
comparison (i.e. keep on the best match).

---

From: mcr at sandelman.ca (Michael Richardson)
Date: Thu, 26 Jul 2007 14:32:38 -0500

> public key from the IKE CERT (or ??) payload

Index: ietf-btns-core.xml
===================================================================
RCS file: /l/users/nico/btns/drafts/ietf-btns-core.xml,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -5 -r1.20 -r1.21
--- ietf-btns-core.xml	26 Jul 2007 01:40:52 -0000	1.20
+++ ietf-btns-core.xml	26 Jul 2007 19:29:13 -0000	1.21
@@ -132,20 +132,35 @@
  	    <t>The IPsec processing model is hereby modified as follows:
  		<list style='symbols'>
  		    <t>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.</t>
+
  		    <t>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.</t>
+
+                    <t>To accomplish the above, search the PAD as normal,
+                       with the ID provided by the peer. If it matches do
+                       normal processing.  If the ID asserted by a peer does
+                       not match any PAD entry, then a BTNS-enabled IPsec
+                       implementation replaces the ID with into the new ID 
of type "PUBLICKEY"
+                       that is created by extracting the public key from the 
IKE CERT payload.</t>
+
+                    <t>The PAD is searched again, using this new ID type and 
value.
+                       If there is a match, the associated PAD entry (which 
will be a BTNS entry)
+                       is used to control the SPD search.
+                    </t>
+                    <t>If there is no match, the IKE SA is rejected</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, for BTNS
@@ -184,11 +199,12 @@
                  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.</t>
+		selectors do not conflict with non-BTNS PAD entries.
+             </t>
  	</section>

          <section title="Usage Scenarios">
  	    <t>In order to explain the above rules a number of scenarios
  		will be examined.  The goal here is to persuade the reader
@@ -498,10 +514,14 @@
  		to create new registrations nor new registries.  (The
  		new ID type is not used on the wire, therefore it need
  		not be assigned a number from the IANA IKEv2
  		Identification Payload ID Types registry.)</t>
          </section>
+
+        <section title="Acknowledgements">
+            <t>Thanks for the following reviewers: Stephen Kent</t>
+        </section>
      </middle>

      <back>
  	<references title="Normative References">
  	    &rfc2119; &rfc4301;

---

From: Nicolas.Williams at sun.com (Nico)
Date: Thu, 26 Jul 2007 14:37:31 -0500

> > 	- the PAD is searched again, using this new ID type and value

Indeed, if there are any PAD entries matching a specific public key,
then those must take precedence over the catch-all BTNS PAD entry.

> Q: does this relax the requirement for the PAD entry to be lowest priority?

No.  PAD entries that match specific PUBLICKEY IDs must come before the
catch-all BTNS PAD entry (which MUST be last); they must also come
logically after any PAD entries matching other ID types.

> comparison (i.e. keep on the best match).

Indeed.  We need only describe a canonical approach though, but we could
certainly say that a one-pass optimization is feasible.

Nico
--

---

From: kent at bbn.com (Stephen Kent)
Date: Fri, 27 Jul 2007 17:15:22 -0400

At 2:19 PM -0500 7/26/07, Michael Richardson wrote:
>S...

I didn't say that the key isn't transmitted; I just noted the wording 
in the document that says that the new IKE ID type is not carried on 
the wire.

The new text on page 4 also says "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)."

first, "ephemeral" is misspelled and there seems to be a word missing 
in that parenthetical phrase.

Second, the text refers to bare RSA key payloads, plural, but I 
assume is it acceptable to send just one such payload, right? in 
fact, would it make sense to send more than one? also, the text 
allows additional cert payloads, but only of they contain the same 
key as the bare RSA payload, but the wording is confusing.  I suggest 
the following rewording, if my assumptions about your intent are 
correct:

A node that wishes to be treated as BTNS node by a peer MUST include 
at least one Raw RSA Key CERT payload.  A node also MAY include one 
or more certificate payloads of types other than Raw RSA Key, but 
only if they contain the same public key as the Raw RSA Key CERT 
payload.  These additional certificates need not have been pre-shared 
with the peer in (e.g., because they may be ephemeral, or 
self-signed).

A final question re this text: why allow sending additional certs?

>comparison (i.e. keep on the best match).

I think you and Nico should agree on this point, and clarify the text 
if needed.
Nico's message refers to the potential for additional PAD entries 
that match PUBLICKEY, but if this ID type was created only to support 
BTNS entries, then his message is saying that there can be multiple 
such entries. Right now the text seems to indicate just one BTNS PAD 
entry, and requires it to be in the last slot.

Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/anonsec/attachments/20070727/8476e0c6/attachment.html

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 30 Jul 2007 10:47:51 -0500

> in the document that says that the new IKE ID type is not carried on 

Correct.  A new IKE ID would be primarily useful as an implementation
detail, but probably useful enough to be worthy of having an assignment
for it.

> in that parenthetical phrase.

It was misspelled, and no word is missing ("because <adjective>" is a
legitimate English language idiom, as in "Joe was lazy because
spoiled").  It is an odd idiom, but one that I'm fond of.

> assume is it acceptable to send just one such payload, right? in 

It is plural because the nodes will be doing multiple IKE exchanges with
many peers thus there will be multiple bare RSA key payloads.

But in one IKE exchange there should be a single payload because there
can be only one AUTH payload so there can really only be one public key.

> fact, would it make sense to send more than one? also, the text 

Having multiple CERT payloads per-exchange all using the same public
key, as in different certs for the same key, seems OK, and even useful.

> with the peer in (e.g., because they may be ephemeral, or 

I like it, thanks.

> A final question re this text: why allow sending additional certs?

Because it would allow a node to do better than BTNS with some peer if
that peer could authenticate it; the node need not know a priori that
its peer can do so.  RFC4306 doesn't seem to disallow multiple CERT
payloads, but the structure of the protocol is such that only one AUTH
payload makes sense, thus all CERT payloads should use the same public
key.

> entry, and requires it to be in the last slot.

The BTNS catch-all entry must be the last one in the PAD.  There may be
PAD entries that match specific public keys -- these must come before
the BTNS catch-all PAD entry.

---

From: kent at bbn.com (Stephen Kent)
Date: Mon, 30 Jul 2007 12:27:44 -0400

>spoiled").  It is an odd idiom, but one that I'm fond of.

For standards documents we tend to look for somewhat more formal writing :-).

>many peers thus there will be multiple bare RSA key payloads.

This is another place where it's better to use singular instances as 
examples, rather than plural instances.  The use of a plural instance 
as a subject creates ambiguity in the rest of the sentence, because 
one cannot know whether the later plural objects apply to each 
instance of the subject, or are due to the use of a plural subject. 
That's why I suggested re-writing text from "nodes" to "a node" in 
other parts of the document.

>can be only one AUTH payload so there can really only be one public key.

That makes sense for this type of CERT payload; IKE does not provide 
guidance about specific CERT payload sub-types, just for the overall 
payload type, so it is helpful to provide that guidance here.

>key, as in different certs for the same key, seems OK, and even useful.

agreed.

>payload makes sense, thus all CERT payloads should use the same public

yes, and it would be appropriate to not that here.

>the BTNS catch-all PAD entry.

I agree that a BTNS "catch-all" entry must come last, but that entry 
is described with two adjectives: BTNS and "catch-all." So, can there 
be a BTNS's entry that matches a specific PUBLICKEY ID type and thus 
is not "catch-all?" I think that was Michael's question, and mine. If 
we say that a BTNS PAD entry is any PAD entry that uses the PUBLICKEY 
ID type, then syntactically this would allow other than catch-all 
BTNS entries.

Steve

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 30 Jul 2007 12:15:51 -0500

> For standards documents we tend to look for somewhat more formal writing 

Sure, but show me that this is not formal (it's harder than you think).

Or did you mean that we want to use a subset of English likely to be
understood by most readers, including those for whom English is not a
first language?  :)  Such an argument wins me over more easily :)

I'll put a note to the RFC-Editor about this.

> other parts of the document.

OK, we can change that to a singular ("A node wishing to be treated as a
BTNS node MUST include a bare RSA key CERT payload.  ...").

> yes, and it would be appropriate to not that here.

Er, "to not that here"?  Did you mean "to do that here"?

> is not "catch-all?" I think that was Michael's question, and mine. If 

Yes, there can be.  Such an entry could be made as a result of
connection latching (using the automatic IPsec policy editing scheme) or
some leap of faith-ish schemes (not yet defined).

> ID type, then syntactically this would allow other than catch-all 

I'll make sure that we distinguish between the BTNS wildcard PAD entry
and others.

For example, the second bullet in section 2 needs a "wildcard" qualifier
to be sprinkled here and there, and another bullet item needs to be
added describing non-wildcard BTNS PAD entries (each such entry must
match a single public key, either by value or by fingerprint).

Thanks for catching this.

---

From: kent at bbn.com (Stephen Kent)
Date: Mon, 30 Jul 2007 13:50:57 -0400

>Sure, but show me that this is not formal (it's harder than you think).

Do you even have a copy of "Strunk and White" on your bookshelf?

>first language?  :)  Such an argument wins me over more easily :)

That's a good argument too, and if that's the one that will cause 
this text to be changed, I'll buy into it :-).

>BTNS node MUST include a bare RSA key CERT payload.  ...").

great.

>Er, "to not that here"?  Did you mean "to do that here"?

no, I meant to "note that here." Just a single letter typo :-).

>some leap of faith-ish schemes (not yet defined).

Then perhaps the text should define a BTNS entry more clearly, near 
the beginning, and discuss the "catch-all" BTNS entry as a special 
case.

>I'll make sure that we distinguish between the BTNS wildcard PAD entry

great.

>Thanks for catching this.

You're welcome.

Steve

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 30 Jul 2007 13:11:58 -0500

> Do you even have a copy of "Strunk and White" on your bookshelf?

I have a couple such books in my bookshelf, but I'm not at home at the
moment.  I've seen recent debates on prescriptivism that have caused me
to doubt some of my own dislikes about other people's use of English.

(I've been noticing that use of 'because' in several novels lately too,
including Quicksilver, by Neal Stephenson.)

> this text to be changed, I'll buy into it :-).

OK :)

> no, I meant to "note that here." Just a single letter typo :-).

OK.