Hi Lakshminath,
That's not entirely correct. As I recently stated to your
colleage if a 3 party key distribution scheme finishes and
all 3 parties think it finished successfully but they do not
agree on all state then the scheme is flawed.
I see the path you're trying to go down-- add a server nonce,
assume everything is now fine-- and I'm not going to follow
you down there.
This is not the forum for this discussion. Let's take this to
the HOKEY list if you really want to continue. Better yet we
can discuss it over a Budvar in Prague.
Dan.
On Wed, March 7, 2007 10:51 pm, Lakshminath Dondeti wrote:
Dan Harkins wrote:
Sam,
But for things like HOKEY or 802.11r they want to have the AAA server
create a key hierarchy rooted off the EMSK or the MSK, respectively,
that
contains keys for specific authenticators. These keys are going to be
distributed using AAA (that seems to be the plan) and either proactively
distributed-- "here have a key!"-- or distributed on demand-- "gimme a
key!" The authenticator-specific key gets produced by mixing in some
identity of the authenticator and that key is then sent under the
protection of the security association between the AAA server and the
authenticator.
Dan,
I snipped all the rest of the email so I can get a clarification from
you on this particular paragraph. The problem you describe here is that
the authenticator gets a key based on the claimed identity of the
authenticator. If the peer and the server do not have a way to verify
the identity of the authenticator it is a problem because the key that
the server sends to the authenticator is the same as long as the claimed
identity of the authenticator is the same.
Do I understand correctly?
thanks,
Lakshminath
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf