> We almost certainly want endpoints/applications to treat the session ID > as sensitive information -- leaked knowledge of the session ID would > allow someone to impersonate the other party if any authentication was > bootstrapped off of the session ID. > > The point of the text David highlights above is to ensure that an > endpoint/application can't learn anything about the cryptographic > secrets through the session ID interface -- that is, it defends the > cryptographic layer from breakage by the client. But we shouldn't > encourage clients to break the layer that is accessible to them (the > session ID) by publishing their data either.
This can't be the case if, for instance, the session IDs are signed in batches as proposed in the tcpcrypt paper. The session ID is a channel binding identifier, not a cryptographic secret. Woe betide anyone who bootstraps authentication outside of the context of the encrypted session using a session ID it had seen sometime in the past under the assumption it was secret. This is why I like the original wording of "public", because it clearly implies you can throw one around at will as its knowledge will do no good to anyone not in control of one of the endpoints of the connection. David, I'll hopefully address the rest of your reply tonight, when I have some free cycles. Kyle _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
