Lakshminath,
Actually we're discussing my suggested additions to an individual
submission that is in IESG evaluation stage. Since I do not believe
they will be accepted at this point in time I don't see a point in
elaborating on them here. We're intersecting on this issue for one
reason and one reason only: HOKEY.
If you want to a full description of the problem then read (and
comment on) the "Problem Statement and Requirments on a 3-Party Key
Distribution Protocol for Handover Keying." Please do so on the HOKEY
list so we are sure to include all the people who might care but are
not on this list.
thanks,
Dan.
On Thu, March 8, 2007 12:41 am, Lakshminath Dondeti wrote:
Dan Harkins wrote:
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.
Could you elaborate on what part is missing from my description please?
What is in the "state" that the parties need to agree on?
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.
In this round, I am trying to get a full description of the problem
before jumping into solutions, but now that you mention this what in
your view is wrong with this approach? What necessary properties are
lost? Perhaps exploring this might help us agree on the problem.
This is not the forum for this discussion.
This is the IETF Discussion list after all and we are discussing an
individual submission that is in the IESG evaluation stage. To my
knowledge, this is the appropriate open forum.
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.
I am ok with an offline discussion in Prague, but I am not sure whether
we have that much time.
regards,
Lakshminath
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