[anonsec] BTNS updates

[Nicolas Williams]

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

[Joe Touch]

Post by Nicolas Williams
Sam and I met over the weekend and discussed how to spec BTNS.
- 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.
- 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.

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

[Nicolas Williams]

Post by Joe Touch

Post by Nicolas Williams
We did not discuss leap-of-faith in much detail. Similarly, we did not
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.

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

[Joe Touch]

Post by Nicolas Williams

Post by Joe Touch

Post by Nicolas Williams
We did not discuss leap-of-faith in much detail. Similarly, we did not
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.

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

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

[Nicolas Williams]

Post by Joe Touch
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).

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.

Post by Joe Touch
Again, this would apply to both conventional and BTNS IPsec.

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

[Michael Richardson]

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

[Nicolas Williams]

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

[Nicolas Williams]

Post by Nicolas Williams

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.

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.

[Michael Richardson]

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?
Most often, yes, but not necessarily.

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.

- --
] 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"); [

[Nicolas Williams]

Post by Michael Richardson
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?

Yes.

Post by Michael Richardson
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.

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.

[Michael Richardson]

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"); [

[Nicolas Williams]

Post by Michael Richardson

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.

If the nodes are multi-user nodes then local security is necessary to
protect one user from another on the same node.

Having two channels with the same end-points and channel bindings, but
used by different users should not pose any security problems as long as
local security is maintained -- neither user should be allowed to
interfere with or eavesdrop on the other's channel.

Nico
--