RE: Last Call: 'Guidance for AAA Key Management' to BCP (draft-housley-aaa-key-mgmt)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > 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 provided
> to two parties,  the peer (identified by the Peer-Id) and the server
> (identified
> by the Server-Id).

And to the authenticator (via AAA protocols). That's the issue I'm trying to
highlight. The third legitimate owner of the key is not identifiable by the
time the key is made available to all the parties. I don't see a definition
of "Authenticator-Id".


> 
> > > Is there an issue with the explanation in the document?
> >
> > The I-D currently does not have any text describing this. So, it'd be
> useful
> > to include one. Russ had agreed with me, but I had a question about the
> > normative language. Your above text clarifies it all. Thanks.
> 
> Ideally this should be clarified in the document itself, not just in an
> email on the IETF list :)

Yes please :-)

Alper



_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]