-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:
>> 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"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Finger me for keys
iQEVAwUBRB5Ry4CLcPvd0N1lAQLmDAf9H1XYEeU48OJIBhj22d58EW6s/Kh2/1IZ
BOLQl9EhcJ7k0kKWk21ur+GRgWa38NkzSH2sZ8ITrqkHsLJ86u0p3QZSEFDvG4HN
leu3v3/UTKRqldUDLP/wPMakjvaMihv1v45MHyIm4xzMapxDwN+hFT1/sKEKlN4R
ioWMJDQpzocvKV7o+mYd6HS92YX7xodMiBkKs20Cg61YcsyCY6igiuqps3Tt6H8O
m/xM+4oNJmwsLqGcDBuU9XgF5/4YzJZW71MXVH9D3mg7Bk/UxFSrX+ULA+GJRhZ2
S4rjInQ36v4zIWJhrrnsORWF8T3DgeLpdIk6oePvVyRM1o9V3mFYNw==
=zTpZ
-----END PGP SIGNATURE-----
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.