On 2/3/2008 1:23 AM, Glen Zorn wrote:
Lakshminath Dondeti <> scribbled on Sunday, February 03, 2008 1:30 PM:
...
There was also the issue of not being able to export EAP session IDs
(IIRC) that I referred to in my other message.
Hmmm. draft-ietf-eap-keying-22.txt says
EAP methods supporting key derivation and mutual authentication
SHOULD export a method-specific EAP conversation identifier known as
the Session-Id, as well as one or more method-specific peer
identifiers (Peer-Id(s)) and MAY export one or more method-specific
server identifiers (Server-Id(s)). EAP methods MAY also support the
import and export of channel binding parameters. EAP method
specifications developed after the publication of this document MUST
define the Peer-Id, Server-Id and Session-Id. The Peer-Id(s) and
Server-Id(s), when provided, identify the entities involved in
generating EAP keying material. For existing EAP methods the Peer-Id,
Server-Id and Session-Id are defined in Appendix A.
Not sure where the "can't export session IDs" idea came from, but the
above would seem to contradict it.
...
Hi Glen,
Yeah, that was my recollection from an old discussion (that SHOULD was a
MAY not too long ago). In any event, it appears that my statements were
incorrect or at least ambiguous. My sincere apologies!
If the session-id based keyname derivation can be made to work, I have
no objection to use it. I looked at draft and in fact, this is what is
stated there:
NameDerivationKey = EAP Session-ID, when K used in rRK derivation is
the EMSK,
NameDerivationKey = DSRK Name, when K used in rRK derivation is the
DSRK.
I looked at some old versions and there was an explanation "Unlike the
rRK_name, the EAP session ID is not used to derive the
rIK_name. This is done in order to avoid any collisions with USRK
names. The key label used for USRKs is IANA registered, while the
string "rIK Name" is not. " We probably need to mix in the domain name
too to avoid key label collision.
I also recall (I know my recollection is bad :) ) Vidya and I discussing
that ID collisions may be likely due to at least a couple of other
reasons too when the domain specific keying is considered. The various
EAP servers do not coordinate session ID derivation and not all methods
derive sufficiently long and random session IDs. I now checked session
ID derivation in some methods again and it seems reasonably random in
methods that I care about (I know that's irresponsible :), but the
generic solution is already in the draft).
Any suggestions on the direction here?
Would it help if we used the following?
NameDerivationKey = f(EAP Session-ID, domain-name), when K used in rRK
derivation is the
DSRK.
regards,
Lakshminath
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
http://www.ietf.org/mailman/listinfo/ietf