![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:
Nicolas> Also, I think my draft's definition of "end-point channel
Nicolas> bidning" needs to be tightened just a bit: not only must
Nicolas> the end-point IDs be cryptographically bound into the
Nicolas> channel, it must also be the case that the IDs
Nicolas> meaningfully identify the channel end-points -- that is,
Nicolas> that one nodes cannot assert the same ID as another
Nicolas> without sharing credentials with it. I think my text
Nicolas> implies this but does not make it sufficiently explicit.
Be careful. A DN given a trust anchor seems like a find end-point
identifier. However two nodes can share the same DN without sharing
the same credential. Under 3280 rules either the CA issued a
certificate it should not have issued or the two nodes are the same
subject. That's strong enough for the channel binding to be useful
even though the nodes may not share a credential.
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
protocol as the
Charles> EAP<->L2 binding.
The L2 secure association protocol cannot be an eap->anything binding:
it does not typically use EAP level identifiers.
Charles> -- t. charles clancy, ph.d. <> tcc at umd.edu <>
Charles> www.cs.umd.edu/~clancy
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.