Subject: [anonsec] BTNS updates

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 5 Dec 2005 18:03:03 -0600

Sam and I met over the weekend and discussed how to spec BTNS.

We read through the RFC2401bis sections on the PAD and worked this out:

 - We need a an SPD "BTNS OK" flag, not an "UNKNOWN" value for the name
   selector.

 - The PAD needs to allow a last entry for BTNS that matches peer IDs
   not matched by any other previous entry

 - Nodes that wish to be treated as BTNS nodes by their peers should
   generate a self-signed cert with a randomized DN.

 - Processing then works like so:

    - search the PAD as per-RFC2401bis, sections 4.4.3.*

    - if a match is found, use that PAD entry as per-RFC2401bis; failure
      to authenticate leads to failure[1]

    - if no matching entry is found and the last entry in the PAD is a
      BTNS entry, then authenticate the peer by verifying that the AUTH
      payload (in the IKEv2 case) is made with a private key
      corresponding to the peer's CERT

      CHILD SAs creation is constrained as with any other PAD entry,
      except that a BTNS peer ID is coerced to a "public key" ID type if
      the PAD entry says to search the SPD by ID.

    - if the peer matched the BTNS PAD entry then only SPD protect
      entries that have the "BTNS OK" flag will be matched

We did not discuss leap-of-faith in much detail.  Similarly, we did not
discuss connection latching in too much detail.

We did discuss channel bindings, however.  Channel bindings do presume
connection latching, which we did not work out in detail, but
nonetheless we think that for SAs authenticated with public key
signatures the channel bindings for latched connections will be the
public key values of the two peers.

Connection latching requires more thought.  Specifically, we need to
find a way to describe connection latching in RFC2401bis terms, or, if
need be, specify extensions to RFC2401bis to permit the specification of
connection latching.

[1]  Note that not allowing a fallback from a matching non-BTNS PAD
     entry to a BTNS PAD entry is important, particularly if the SPD
     would be searched by "peer IP addresses asserted in traffic
     selector payloads," but I think it might be OK if the BTNS PAD
     entry were to specify that the SPD should be searched for entries
     matching the special Name selector "UNKNOWN."

Nico
--

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 05 Dec 2005 16:15:47 -0800

> discuss connection latching in too much detail.

As per my other post, wouldn't both end up adding an entry to the PAD
(call that a latching PAD entry)? That entry ought to supercede the BTNS
entry.

Joe

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 5 Dec 2005 20:49:43 -0600

> (call that a latching PAD entry)? That entry ought to supercede the BTNS

We did discuss this for leap-of-faith at IETF64.

I had not considered this approach for connection latching.  But it
sounds plausible, with a reference count on the PAD entry, so each
latched connection holds a reference and the PAD entry is removed when
the reference count falls to zero.  Matching SPD entries would be
added/removed dynamically as well as connections are latched/closed.

Yes, seems workable.

Nico
--

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 06 Dec 2005 09:55:11 -0800

> added/removed dynamically as well as connections are latched/closed.

FWIW, the same approach SHOULD be used for conventional PAD entries - no
modification while the reference count is non-zero.

Actually, given the problems with the reference count, as well as the
potential for entries above (ealier in the PAD) to be added which could
override, it seems like the PAD information MUST be copied into the SAD
when the connection is established, and only _that_ entry verified when
incoming packets warrant (e.g., before taking actions that change the SA).

Again, this would apply to both conventional and BTNS IPsec.

Joe

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 6 Dec 2005 12:07:52 -0600

> incoming packets warrant (e.g., before taking actions that change the SA).

I'm not sure, but I think a proper connection latch or leap-of-faith
binding may have to be effected through all the databases -- PAD, SAD
and SPD.

For connection latching, in particular, I don't see how the SPD can be
avoided.  Note too that connection latching requires native IPsec -- it
involves cooperation of the ULPs.

> Again, this would apply to both conventional and BTNS IPsec.

Agreed.  Connection latching pre-dates BTNS for a reason, I'm sure :)