|
RE: [HOKEY] Last Call: draft-ietf-hokey-erx (EAP Extensions for EAP Re-authentication Protocol (ERP)) to Proposed Standard
2008-02-05 15:25:41
-----Original Message-----
From: Dan Harkins [mailto:dharkins(_at_)lounge(_dot_)org]
Sent: Tuesday, February 05, 2008 12:23 PM
To: Joseph Salowey (jsalowey)
Cc: Dan Harkins; ietf(_at_)ietf(_dot_)org; hokey(_at_)ietf(_dot_)org
Subject: RE: [HOKEY] Last Call: draft-ietf-hokey-erx (EAP
Extensions for EAP Re-authentication Protocol (ERP)) to
Proposed Standard
So there's something else besides key name that is used to
identify keys. Great, so that means these hashed key names
are unnecessary. No need to do HMAC-SHA256 to generate a
random string, throw away 3/4 of that result and come up with
something that is unusable.
Let's get rid of this stuff since it serves no useful
purpose and is computationally expensive.
[Joe] That something else mat not be sufficient to disambiguate keys.
For example if MAC address or username is used it is possible that there
is more than one session with that entity.
Yes, EAP Session ID (or Username, as Glen suggests) will be
hashed. So if you have an rIK and an rRK and 5 or 6 rMSKs all
derived from the same EMSK then the EAP Session ID (or
Username, as Glen suggests) that identifies that EMSK can be
used as the index in the hash table and all the derivatives
are guaranteed to end up in the same bucket. You look up
based on an identifier on the root and everything is right
there in your hands. If the namespace is completely flat then
searching for all related keys is a pain.
Dan.
On Tue, February 5, 2008 12:02 pm, Joseph Salowey (jsalowey) wrote:
There is nothing in the document that says you must index
keys only by
key id. I don't really understand the problem here, there is other
context associated with a key besides a name that can be used for
indexing. The key name provides a fixed length unique
identifier for
the key. EAP Session-ID is not fixed length and can be
awkward to use
in protocols, most likely you will end up hashing it anyway.
Joe
-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org]
On Behalf
Of Dan Harkins
Sent: Friday, February 01, 2008 5:46 PM
To: Dan Harkins
Cc: ietf(_at_)ietf(_dot_)org; hokey(_at_)ietf(_dot_)org
Subject: Re: [HOKEY] Last Call: draft-ietf-hokey-erx (EAP
Extensions
for EAP Re-authentication Protocol (ERP)) to Proposed Standard
Hello again,
Pardon my repetition but I have come up with a very valid reason
why naming keys using HMAC-SHA-256 is a bad idea.
If one wants to administratively remove all keys in a particular
key hierarchy (which seems like an entirely reasonable
request) one
must do a linear search of all keys in all key hierarchies that a
particular server maintains!
This is because HMAC-SHA-256 has mapped all identifying key
information for all key hierarchies to the same name space.
It precludes using something like a hash table for fast
lookup of all
related keys.
If keys were named by concatenating the EAP Session-ID with a
string that identified the particular key in the key
hierarchy rooted
at the MK derived in that EAP Session-ID then the EAP Session-ID
could be used as an index into a hash table and all keys for that
particular key hierarchy could be looked up very efficiently.
regards,
Dan.
On Fri, February 1, 2008 5:16 pm, Dan Harkins wrote:
Hello,
I believe this is a well organized and complete document. On
numerous occasions while reviewing it I made a mental question
regarding something only to have the question answered in a
subsequent
paragraph.
I do have several comments though:
1. this protocol can be used in the presence of AAA proxies. Due
to the nature of AAA proxies a peer or authenticator may not
even know whether they are part of the communication chain.
Therefore, from the view of a security threat their presence
must be assumed by the peer and authenticator.
The Domain referred to in section 2 (part of the EMSK key
hierarchy draft) specifically allows for proxies as part of
the distributed system of computers that define the Domain.
This brings up many significant issues that are not addressed
in this draft.
- It cannot be claimed that a key is being bound to its
context when the context cannot even be scoped. (Section 6)
- The domino effect is not prevented because compromise of a
proxy will compromise keying material on (other)
authenticators.
- A pairwise key is being given by one of the entities
that share
it, e.g. the server, to a 3rd entity, e.g. a proxy,
without the
consent of the other peer that shares the key,
e.g. the peer.
This brings up security considerations that are
not discussed.
- During discussions at a HOKEY meeting and on the list
the rationale
that justified proxies was that the peer is more
concerned about
receiving network access (which is confirmed in the
ERP document
when it says, "The primary purpose [of ERP] is
network access
control.") than about specifically authenticating
"the network".
Provided that service is obtained with no surprises
in the bill at
the end of the month the rationale was that the peer
didn't care
if the key was distributed to proxies if it was
necessary to
continue to provide network access. Which is a
reasonable rationale.
But it needs to be mentioned in this document. It
has a unique
threat model that is not discussed anywhere.
- The aforementioned rationale begs the question of why have
"Domain Specific Keys". If the peer doesn't care
whether proxies
have a key, potentially for a different domain, then
it doesn't
care about key separation between domains. This is
significant
added complexity for no benefit.
- RFC4962 REQUIRES things-- bind key to its context,
prevent the
domino effect-- that ERP cannot support. ERP is a AAA key
management protocol though and falls under the scope
of RFC4962.
There needs to be justification for why ERP is not
meeting the
mandatory requirements of RFC4962.
I think all of these issues need addressing before
advancement of this
Internet-Draft.
2. Inter-Domain ERP
It is this reviewers recollection that consensus was
reached in HOKEY
to require a peer to reauthenticate back to the home AAA
server every
time it attached to a POP in different domain.
Therefore, I wonder why a "Domain-Specific" key, the
DSRK, and all it's
progeny-- DS-rIK, DS-rRK, DSUSRK, etc.-- continue to be
used by this
protocol. A "HOKEY-KEY", a USRK, should be derived
from the EMSK
and that is the key given, through proxies if need be,
to the ER
server in the visited domain. If the peer goes to a
different domain
then it does a full reauthentication resulting in a _new_
USRK, that
has no relation to the previous USRK, being given to
the ER server
in the new domain. Again, it was my understanding that
the group
already reached consensus on this matter.
3. HMAC-SHA256 as a key naming technique
SHA-256 is a computationally intensive operation;
HMAC-SHA256 doubly
so. There should, therefore, be some justification to
use such a
strong cryptographic mixing function if all one wants to do is
"uniquely name a key". EAP methods export a
Session-ID. An rIK can
be named by the concatenation of Session-ID and "rIK".
Similarly for
the rMSK, rRK and the other keys being generated in ERP.
This has the added benefit of allowing for key management
to quickly
identify keys based on common queries-- all the keys for
a specific
Session-ID, or all rIKs held by a particular entity. By using a
strong cryptographic mixing function all specificity of
the key names
has been lost across every single key hierarchy that a
HOKEY server
may end up managing.
This is a really bad idea and it should be changed before this
Internet-Draft is advanced.
4. Section 5.3.2 EAP-Initiate/Re-Auth Packet
This packet has the following field:
+-+-+-+-+-+-+-+-+
|R|B|L| Reserved|
+-+-+-+-+-+-+-+-+
And "R" is, itself, reserved. This makes no sense. Please << 1
this field.
regards,
Dan.
_______________________________________________
HOKEY mailing list
HOKEY(_at_)ietf(_dot_)org
http://www.ietf.org/mailman/listinfo/hokey
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
http://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
http://www.ietf.org/mailman/listinfo/ietf
|
|