> That said, one could imagine a fringe use case where an application
> wants to prove that two anonymous TCP connections belong to the same two
> processes, in which case the session ID of the first connection might be
> used as a MAC key to authenticate the session ID of the second. So you
> don't want the session ID to be predictable, even if making it public
> doesn't hurt TCPINC itself.
I'm starting to come around to dkg's viewpoint that it doesn't
necessarily *have* to be public: batch signing of session IDs is one
suggested use case, but authentication protocols that don't do that
could potentially make use of the session ID being private.
I think maybe guidance about when it is appropriate to consider them
public vs. private belongs in section 4.1 of this doc, or in the API
doc if a section there is added on batch signing. Strictly speaking,
the current wording ("The session ID MUST NOT contain any confidential
data (such as data permitting the derivation of session keys)") is
probably right.
Kyle
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
