FWIW, I agree with Glen's take here. To avoid repeating myself, here
are pointers to emails that I sent in response to this thread on the
IETF list (for the benefit of those not on the list):
http://www.ietf.org/mail-archive/web/ietf/current/msg50860.html
http://www.ietf.org/mail-archive/web/ietf/current/msg50880.html
- Vidya
-----Original Message-----
From: hokey-bounces(_at_)ietf(_dot_)org
[mailto:hokey-bounces(_at_)ietf(_dot_)org]
On Behalf Of Glen Zorn
Sent: Tuesday, March 18, 2008 8:31 AM
To: Charles Clancy
Cc: ietf(_at_)ietf(_dot_)org; hokey(_at_)ietf(_dot_)org; Bernard Aboba
Subject: Re: [HOKEY] EMSK Issue
Charles Clancy <> scribbled on :
HOKEY,
From Bernard's "walled garden" LC comments, I've created
the following
issue below in the issue tracker.
Some of us don't subscribe to the IETF list (due to the
extremely poor S/N ratio). Someone did forward me Bernard's
original message & to me it appears to fall squarely into the
N category (either that or it is an early April 1 RFC
candidate). I understand, though, that it is actually
receiving serious discussion on the IETF list, so I'm happy
that you are bringing some of that discussion to this forum.
Of course, common courtesy would have required that the WG
the work of which is being disparaged in outrageous fashion
be included in the discussion but courtesy seems to be in
short supply.
http://www.ltsnet.net:8080/hokey/issue39
EMSK: applicability statement, scope
The EMSK document, as-is, allows (or more precisely does not
disallow) for broader use of keys than it should.
That may be somebody's claim; however, RFC 3748 says:
Extended Master Session Key (EMSK)
Additional keying material derived between the EAP client and
server that is exported by the EAP method. The EMSK is at least
64 octets in length. The EMSK is not shared with the
authenticator or any other third party. The EMSK is
reserved for
future uses that are not defined yet.
This doesn't appear to me to constrain the uses of the EMSK;
furthermore, since Bernard is not just one of the authors of
3748 but also a co-Chair of the working group that published
it, it seems like the time & place to constrain the usage of
the EMSK would have been during the drafting of the RFC and
in the eap WG.
There could
be interoperability issues if applications require
EAP-generated keys,
breaking the layering of the Internet protocol stack.
What does that mean? How can _keys_ cause layer violations?
Some sort of statement regarding applicability and scoping
of derived
keys is necessary for this document.
--
t. charles clancy, ph.d. eng.umd.edu/~tcc
electrical & computer engineering, university of maryland
_______________________________________________
HOKEY mailing list
HOKEY(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/hokey
_______________________________________________
HOKEY mailing list
HOKEY(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/hokey
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf