Sam,
We discussed channel binding before the publication of 4962 (I was
reminded recently that draft-housley-aaa-key-mgmt is now a published
document :) ) and concluded (I think) that the language in 4962 should
just mirror the language of 3748. I think that is what 4962 in fact does:
"As described in RFC
3748 in Section 7.15, channel binding is required to enable the
peer to verify that the authenticator claim of identity is both
consistent and correct."
As to what needs to be done for channel binding, I would echo what
Bernard said recently
"With respect to Channel Bindings, it should be understood that no
proposals for this have ever been implemented, as far as I am aware. So
a first step would be for a method to choose one of the approaches to
Channel Bindings and support it (probably as an experimental extension),
and then to evaluate the experiment so we can understand how well (or
badly) the chosen approach works. At that point we might be ready to
support Channel Bindings in other methods. "
best regards,
Lakshminath
On 8/22/2007 4:48 AM, Sam Hartman wrote:
"Lakshminath" == Lakshminath Dondeti <[EMAIL PROTECTED]> writes:
Lakshminath> I would like to see the crypto-binding stuff (not
Lakshminath> compound binding -- as others have noted, we don't
Lakshminath> have consensus on that topic) and extensibility (how
Lakshminath> to add new attributes) specified.
I'd really appreciate it if someone would think hard about the
interactions of draft-housley-aaa-key-mgmt and channel binding. I'd
like to understand whether we can meet all the requirements of that
BCP without channel binding and if not, what we need to do about it.
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu
