[anonsec] BTNS updates

[Michael Richardson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:
    Nicolas> On Sun, Mar 19, 2006 at 11:49:46AM -0600, Michael
    Nicolas> Richardson wrote:
    >> >>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com>
    >> writes:
    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"); [

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBRB5P74CLcPvd0N1lAQJmrAf/RaVkj/8NHIcD5d6fY1cJGlYdL5hXO5WU
K5rCSRc58nQcY0gaGWbgAjpSlAuITQTuMKEaAJl3fmcmEM/ZXsDhqEAxjXAD/bYl
IXDc0d4sd96USN2ZEDAh7O1jNvH9AXLhjgTTUX8YDgnzJxOxhTjqxOGN0CxHQMLA
sz3amoG/vYCYuJ91tj3YZ6vLzSWYFjqCDaVCoH7JdEbh1qEcnJm1Tdh6KSIW4A2x
us1LfravwSurq1lpqMH07P9EUtW5inttw6IayvoNurk2nsy4gE2b0E24QYnkvVx1
4wXFa4R0jvBIwDlFb+g/+2pZ5ilxZQ/54xA4zSkcVNJQDjbbqEjZIQ==
=xiom
-----END PGP SIGNATURE-----