Subject: [anonsec] BTNS updates

From: mcr at sandelman.ottawa.on.ca (Michael Richardson)
Date: Sun, 19 Mar 2006 11:49:46 -0600

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 480 bytes
Desc: not available
Url : http://www.postel.org/pipermail/anonsec/attachments/20060319/fb488cd9/attachment.bin

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Sun, 19 Mar 2006 16:26:06 -0600

On Sun, Mar 19, 2006 at 11:49:46AM -0600, Michael Richardson wrote:
> 
> >>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:
>     Nicolas>  - Nodes that wish to be treated as BTNS nodes by their peers
>     Nicolas> should generate a self-signed cert with a randomized DN.
> 
>   Can you be more specific?

Do I have to be?

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

No, not directly, a bit of structure may be necessary, and a canonical
order is necessary (there can be only two, so let's pick one).

>   Will we write a single description of a channel binding "blob", or will
> this be application defined? 

We will write a single description in a separate document (most likely).

>   If there are two connections between peers, such as, in some cases, two NFS
> mounts, but certainly if I used channel binding for two SSH connections for
> which I had a (probably-non-btns) /32<->/32 tunnel, would both instances see
> the same binding data?

Most often, yes, but not necessarily.

Nico
--

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Sun, 19 Mar 2006 16:40:41 -0600

> Most often, yes, but not necessarily.

To be more specific, provided that the peer IDs do not change then the
*latched* IDs should be the same for all end-to-end connections with the
same ends, but because of key rollovers the channel bindings for any two
such connections may be different.

---

From: mcr at sandelman.ottawa.on.ca (Michael Richardson)
Date: Mon, 20 Mar 2006 00:47:12 -0600

>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:
    Nicolas> On Sun, Mar 19, 2006 at 11:49:46AM -0600, Michael
    >> >>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com>
    Nicolas> - Nodes that wish to be treated as BTNS nodes by their
    Nicolas> peers should generate a self-signed cert with a randomized
    Nicolas> DN.
    >> Can you be more specific?

    Nicolas> Do I have to be?

  Give me an example of a randomized DN.
  
    Nicolas> No, not directly, a bit of structure may be necessary, and
    Nicolas> a canonical order is necessary (there can be only two, so
    Nicolas> let's pick one).

  I suggest sorting by IP address of initiator/responder in network order.
That's a simple sorting method.

    >> Will we write a single description of a channel binding "blob",
    >> or will this be application defined?

    Nicolas> We will write a single description in a separate document
    Nicolas> (most likely).

  Good. I prefer it be similar across application uses.

    >> If there are two connections between peers, such as, in some
    >> cases, two NFS mounts, but certainly if I used channel binding
    >> for two SSH connections for which I had a (probably-non-btns)
    >> /32<->/32 tunnel, would both instances see the same binding data?

    Nicolas> Most often, yes, but not necessarily.

  Okay. I am concerned about this. I have a nagging feeling that the
channel binding should be made unique between users, but I'm not sure
how to do this without introducing new {IKE,IKEv2} notifies. 

- -- 
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr at xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: mcr at sandelman.ottawa.on.ca (Michael Richardson)
Date: Mon, 20 Mar 2006 00:55:09 -0600

>> On Sun, Mar 19, 2006 at 11:49:46AM -0600, Michael Richardson
    >> wrote: > If there are two connections between peers, such as, in
    >> some cases, two NFS > mounts, but certainly if I used channel
    >> binding for two SSH connections for > which I had a
    >> (probably-non-btns) /32<->/32 tunnel, would both instances see >
    >> the same binding data?
    >> 

    Nicolas> To be more specific, provided that the peer IDs do not
    Nicolas> change then the *latched* IDs should be the same for all
    Nicolas> end-to-end connections with the same ends, but because of
    Nicolas> key rollovers the channel bindings for any two such
    Nicolas> connections may be different.

  When you say key rollover, you mean at the PK level, not at the IPsec
"rekey" level, right?

  To take what I consider is the canonical case of FTP with the data
channel(s) (but also maps to HTTP with multiple sessions, SIP with
control and RTP channels, and other protocols too), you are saying that
the channel binding for data/control of FTP would be the same.
  I agree that this *SHOULD* be the case.

  But, you are also saying that *two* FTP sessions between the same
hosts (under the same users, if user-based-keying were available) would
have the same channel bindings as well. 
  I'm trying to figure out if there is some threat there that we need
defend against, given that the public key are the same.

  I think that I'd like the channel binding to be hash'es of the public
key itself (not the certificate, if one was involved). that way, I don't
have to worry how the end-points got the public keys.

  I suggest that the hash should be essentially identical to SSHFP
format or 
  # openssl x509 -hash -noout -in /etc/postfix/client.crt

  format. I  am not sufficiently PKIX aware to know if this is the same
HASH.

- --

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 20 Mar 2006 09:10:38 -0600

>   When you say key rollover, you mean at the PK level, not at the IPsec

Yes.

> have to worry how the end-points got the public keys.

The latch is to the IDs, the channel bindings are the public keys used
to authenticate the peers in the KE for the SA that protected the packet
that led to the latch being set up.

If there's a key rollover but the IDs don't change between two
connections between the same endpoints then the latches will be the same
for both connections but the channel bindings will differ.