> > I'm talking about MSK, not TSK. By the time EAP authentication is
> completed
> > successfully, there is an MSK but the EAP peer does not know the
> "identifier
> > of the parties to whom the session key is available."
>
> At the completion of the EAP method conversation, the MSK/EMSK is provi
> MSK is exported by the EAP method. So, I'd think the EAP method shall
> provide the authenticator identity.
EAP methods (optionally) export the Peer-Id and Server-Id. They don't
export the authenticator identity, since the authenticator is not a party
in the EAP method conversation; it only a
> > Through the exchange of such identifiers one can bind the MSK to the
> > identity of the authenticator. But this has issues, imho. RFC 3748
> does
> > not mandate such a feature on the EAP lower layers.
>
> RFC 3748 doesn't talk about this because it isn't an EAP issue -- EAP
> methods tre
> Through the exchange of such identifiers one can bind the MSK to the
> identity of the authenticator. But this has issues, imho. RFC 3748 does
> not mandate such a feature on the EAP lower layers.
RFC 3748 doesn't talk about this because it isn't an EAP issue -- EAP
methods treat the authe
> >Can you please provide a pointer?
>
> Authenticator and peer identication issues are discussed in Section
> 2.2.1 of draft-ietf-eap-keying-15.txt
According to my reading, we rely on this piece of text:
The following steps enable lower layer identities to be securely
verified by all part
>Can you please provide a pointer?
Authenticator and peer identication issues are discussed in Section
2.2.1 of draft-ietf-eap-keying-15.txt
>I'm wondering why we open the door for children keys living longer than the
>parent key.
There is a distinction between maximum and actual lifetime which
Alper:
> >And how would we apply this to EAP? There is no authenticator ID known to
> >EAP peer, yet they share an MSK.
>
> I believe that this is being addressed in draft-ietf-eap-keying.
Can you please provide a pointer?
It has peer-id and server-ids defined. But even that has issues, as the
Hi Russ,
> >And how would we apply this to EAP? There is no authenticator ID known to
> >EAP peer, yet they share an MSK.
>
> I believe that this is being addressed in draft-ietf-eap-keying.
Can you please provide a pointer?
It has peer-id and server-ids defined. But even that has issues, as t
Joe:
> 5. Unique Key Names
>
> This section states "the key name MUST NOT be based on the
> keying material itself." 802.11i uses this technique; are
> there vulnerabilities associated with this?
Does this proposed text resolve your concern?
AAA key management proposals require a robust key n
Thanks Bernard,
Comments inline.
> -Original Message-
> From: Bernard Aboba [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 08, 2006 2:00 PM
> To: ietf@ietf.org
> Cc: Joseph Salowey (jsalowey)
> Subject: Re: Last Call: 'Guidance for AAA Key management&#x
> -Original Message-
> From: Russ Housley [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 08, 2006 10:48 AM
> To: Joseph Salowey (jsalowey); ietf@ietf.org
> Subject: RE: Last Call: 'Guidance for AAA Key Management' to
> BCP (draft-housley-aaa-key-mg
> "Yoshihiro" == Yoshihiro Ohba <[EMAIL PROTECTED]> writes:
Yoshihiro> On Wed, Nov 08, 2006 at 02:00:14PM -0800, Bernard Aboba
Yoshihiro> wrote:
>> I believe that the document will have implications for the
>> RADIUS protocol. For example, during the RADEXT WG meeting at
>
On Wed, Nov 08, 2006 at 02:00:14PM -0800, Bernard Aboba wrote:
> I believe that the document will have implications for the RADIUS
> protocol. For example, during the RADEXT WG meeting at IETF 67, we
> discussed the need for crypto-agility in RADIUS, and the current lack of
> ability to negotia
I believe that the document will have implications for the RADIUS
protocol. For example, during the RADEXT WG meeting at IETF 67, we
discussed the need for crypto-agility in RADIUS, and the current lack of
ability to negotiate cryptographic algorithms. This is why Crypto-agility
was added as
Joe:
I'm not really clear on the purpose of the document. What does it apply
to? Does it require changes to existing AAA protocols? Does it add new
requirements to EAP methods that are not in RFC3748? It would probably
be good to reference 3748 when it applies to a requirement in this
document
t the authenticator can be separated from a AAA client as long as the
context of the request is communicated correctly between parties. Is
this it?
Joe
> -Original Message-
> From: Russ Housley [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, November 07, 2006 8:00 AM
> To: Na
I agree that such a section on key management claims makes sense, but
that should go in security considerations. I have some of the
reservations that Sam has, but this is a necessary evil, IMO.
Lakshminath
At 03:08 PM 11/7/2006, Bernard Aboba wrote:
>
Adding such a statement would at l
As an individual I would prefer not having this level of formality.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
> Bernard:
>
> Your rewording of section 2 seems fine to me. As co-author, you could have
> provided it many months ago ;-)
>
> Are you suggesting the addition of something like:
>
> Authors who follow these guidelines specified in this document
> should incorporate this phrase near the beginni
Vidya:
My concern is the origins of this whole effort.
In March 2003, I was asked to put together criteria for acceptable
AAA key management. I received this request at the beginning of IETF
56, and it resulted in the "Key Management in AAA" presentation to
the AAA WG a few days later. This
Bernard:
Your rewording of section 2 seems fine to me. As co-author, you
could have provided it many months ago ;-)
Are you suggesting the addition of something like:
Authors who follow these guidelines specified in this document
should incorporate this phrase near the beginning of the
Here are my comments on the document:
Overall Comments
While this document includes a lot of useful requirements, it does not
provide guidance on how document authors should demonstrate adherence to
the principles that are described. For example, a AAA key management
document may not include
> Vidya:
>
> > > I agree, the document is really addressing AAA/EAP key management.
> >
> >Why would the scope be limited to EAP? It seems to me that
> most, if not
> >all, of the requirements would be applicable to just about any
> >AAA-based key management protocol. Would it not be useful to
Vidya:
> I agree, the document is really addressing AAA/EAP key management.
Why would the scope be limited to EAP? It seems to me that most, if not
all, of the requirements would be applicable to just about any AAA-based
key management protocol. Would it not be useful to generalize it?
You ar
Hi Russ,
> I agree, the document is really addressing AAA/EAP key management.
>
Why would the scope be limited to EAP? It seems to me that most, if not
all, of the requirements would be applicable to just about any AAA-based
key management protocol. Would it not be useful to generalize it?
Vi
Alper:
I think this is a good and much-needed document. Thanks to the authors and
whoever else contributed to it.
Thanks for your review.
The title and the abstract starts reading like a general AAA key management
guideline, but later the document gets too EAP-specific. Is the intent to
prov
I think this is a good and much-needed document. Thanks to the authors and
whoever else contributed to it.
The title and the abstract starts reading like a general AAA key management
guideline, but later the document gets too EAP-specific. Is the intent to
provide general guidelines that should
27 matches
Mail list logo
