Narayanan, == Narayanan, Vidya [EMAIL PROTECTED] writes:
Narayanan, Dan, There is a fundamental security property in all
Narayanan, that we have been discussing:
Narayanan, It MUST NOT be possible for an entity A, impersonating
Narayanan, as entity B, to obtain any key material
My 2 cents inline...
-Message d'origine-
De : Lakshminath Dondeti [mailto:[EMAIL PROTECTED] Envoyé :
mercredi 7 mars 2007 23:50 À : Sam Hartman Cc : ietf@ietf.org Objet :
Re: [Dan Harkins] comments on draft-houseley-aaa-key-mgmt-07.txt
Hi Sam,
Many thanks for the opportunity
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
-Original Message-
From: Dan Harkins [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 07, 2007 10:36 PM
To: Narayanan, Vidya
Cc: Dan Harkins; Sam Hartman; ietf@ietf.org
Subject: RE: [Dan Harkins] comments on
draft-houseley-aaa-key-mgmt-07.txt
If you have a 3 party key
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
Hi, folks. The following last call comment was received and based on
discussion the draft was updated. This comment never seems to have
made it to the ietf list though.
The following text was added to address the comment. Please confirm
that this text addresses the comment and that from the
Hi Sam,
Thanks for the update. My original comment never made it to the ietf
list because I wasn't a member at the time of posting. I was informed that
if the moderator approved my posting it would be sent to the list,
unfortunately it wasn't. :-(
In the new Peer and authenticator
Dan, again, with the text as it stands, what attacks do you see
permitted by these requirements that you believe should not be
permitted.
The text changes you proposed were considered but are rather
problematic for existing protocols. I don't think we mind mandating
changing protocols for real
Hi Sam,
Many thanks for the opportunity to comment on the proposed text before
approval.
I do have concerns with the proposed text. Some of the new requirements
are overly burdensome. In other places, it is not clear what is expected.
Some notes below:
Sam Hartman wrote:
Hi, folks.
Sam,
The problem I see is that when AAA is used as a key distribution
protocol there are 3 parties involved (peer, AAA server and authenticator)
and it's a 2 party model. For existing protocols-- the peer is speaking
to a NAS and the NAS obtains a key for the peer from the AAA server-- the
Since there is no binding of identities it allows an
authenticator to say give me the key for authenticator FOO
even though it is actually authenticator BAR. For instance
the NAS-Id is put into a RADIUS request to ask for a specific
key and the key is sent back protected by the shared
If you have a 3 party key distribution scheme and at the
end of it the 3 parties do not share ALL THE SAME STATE yet
believe the protocol has successfully completed then your
key distribution scheme is flawed.
Dan.
On Wed, March 7, 2007 8:32 pm, Narayanan, Vidya wrote:
Since there is no
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
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
Hi Vidya,
On Sat, February 17, 2007 11:43 pm, Narayanan, Vidya wrote:
Yes, the problem of an authenticator providing different identities to
the peer and the server is the typical channel binding problem and can
be detected by simply doing a protected exchange of the identity between
the
Hi,
I understand this draft is in IESG evaluation and would like to register
some comments. I apologize for the tardiness of this email.
This draft is well-written and much needed but I feel it does not
completely address the issue of using AAA for key distribution. Let me
summarize the
Lakshminath == Lakshminath Dondeti [EMAIL PROTECTED] writes:
Lakshminath Dan, We are discussing the case of the authenticator
Lakshminath providing a different identity to the peer and the
Lakshminath server here. Sam raised that issue.
This is probably the last message you'll hear
Vidya,
On Sun, Feb 18, 2007 at 11:20:54PM -0800, Narayanan, Vidya wrote:
(snip)
Going back to your proposed text:
It is RECOMMENDED that the key transport protocol be able to detect
impersonation. When it is not feasible to guarantee that, every key
handed out from the server
Sam,
Please read the thread again and make a convincing case as to why my
message -- and please consider the entire message -- is disgusting, and
I shall apologize.
Some notes inline:
Sam Hartman wrote:
Lakshminath == Lakshminath Dondeti [EMAIL PROTECTED] writes:
Lakshminath Dan, We
-houseley-aaa-key-mgmt-07.txt
Vidya said:
In my understanding, Dan's claim is that the server is unable
to detect
that an authenticator is claiming an incorrect identity and by
virtue of
that, if the authenticator claims the false identity
Dan,
We are discussing the case of the authenticator providing a different
identity to the peer and the server here. Sam raised that issue.
Earlier Vidya described the problem you raise below: that of an
authenticator (or an entity in the middle) providing the wrong identity,
but the same
-aaa-key-mgmt-07.txt
Sam,
The problem of an entity in the middle giving disparate
information to the peer and the server is in fact easier to
solve than the problem Vidya summarized. The disparate
information problem has been described in the EAP Keying
Framework document
, February 17, 2007 9:36 AM
To: Sam Hartman
Cc: Narayanan, Vidya; [EMAIL PROTECTED]; Dan Harkins;
ietf@ietf.org
Subject: Re: comments on draft-houseley-aaa-key-mgmt-07.txt
Sam,
The problem of an entity in the middle giving disparate
information
to the peer and the server
Vidya, I found the model you proposed didn't fit what Dan was talking
about very well. In particular, Dan wants to focus on problems
resulting from the fact that the name of the authenticator used
between the peer and the authenticator may be different than the name
of the authenticator used
Sam,
The problem of an entity in the middle giving disparate information to
the peer and the server is in fact easier to solve than the problem
Vidya summarized. The disparate information problem has been described
in the EAP Keying Framework document and elsewhere too.
To my
on draft-houseley-aaa-key-mgmt-07.txt
Sam,
The problem of an entity in the middle giving disparate
information to the peer and the server is in fact easier to
solve than the problem Vidya summarized. The disparate
information problem has been described in the EAP Keying
Framework document
Speaking as an individual:
I believe the attack Dan is concerned about is very important and I
believe it is important that this draft make it clear that
distributing keys to the wrong parties does not meet the requirements
of the draft.
I take no position on whether the draft does accomplish
1:32 PM
To: Dan Harkins
Cc: [EMAIL PROTECTED]; ietf@ietf.org
Subject: Re: comments on draft-houseley-aaa-key-mgmt-07.txt
Speaking as an individual:
I believe the attack Dan is concerned about is very important
and I believe it is important that this draft make it clear
28 matches
Mail list logo
