Subject: [eap] EAP key naming

From: [email-masked] (Bernard Aboba)
Date: Wed, 9 Jul 2003 00:52:04 -0700 (PDT)

At IETF 56, during the AAA WG meeting, Russ Housley the Security
Area Director, provided a roadmap for EAP and AAA keying, by listing the
characteristics that a proposed solution MUST satisfy.

This message summarizes current thinking on how the EAP Keying Framework
satisfies those requirements.  As noted below, we have a better handle on
some of the Issues than others;  in particular Issue 12 needs more work.
The most current version of the EAP Keying Framework is available at:

http://www.drizzle.com/~aboba/EAP/draft-aboba-pppext-key-problem-07.txt

Requirements for EAP Key Management

A proposed solution MUST:

1. Be an algorithm independent protocol
2. For interoperability, select at least one suite of algorithms that MUST
  be implemented
3. Establish strong, fresh session keys
4. Maintain algorithm independence
5. Include replay detection mechanism
6. Authenticate all parties
7. Maintain confidentiality of authenticator
8. NO plaintext passwords
9. Perform client and NAS authorization
10. Maintain confidentiality of session keys
11. Confirm selection of best ciphersuite
12. Uniquely name session keys
13. Compromise of a single NAS cannot compromise any other part of the
    system, including session keys and long-term keys
14. Bind key to appropriate context

The EAP Keying Framework document
(http://www.drizzle.com/~aboba/EAP/draft-aboba-pppext-key-problem-07.txt)
has made progress on most of these items.

For example, EAP supports multiple methods (algorithms), as well as
ciphersuites and ensures that any method can work with any ciphersuite and
media. So #1, and #4 are covered.

RFC 2284bis includes a mandatory to implement algorithm, albeit one which
does not generate keys or do mutual authentication.  At IETF 56, EAP WG
received a request from IEEE 802.11 to change the mandatory-to-implement
algorithm to one which does derive keys.  However, as discussed by Erik
Nordmark, while it might make sense for EAP usage communities to define
their own mandatory algorithms, it is likely that those communities would
resist having a single mandatory-to-implement algorithm imposed on all of
them.  So Issue #2, appears to be the responsibility of individual EAP
usage communities.

Issue #3 can be handled by requiring that EAP methods generating keys
provide freshness -- such as by including an exchange of nonces.  It also
makes sense to require that secure association protocols running after EAP
(e.g. IEEE 802.11i 4-way handshake) provide freshness, so that TSKs are
fresh, even if the MSK and EMSK are not. So overall, I think we've got a
good handle on this one.

Issue #5 relates to replay protection in EAP, in the secure association
protocol as well as in AAA.  RADIUS over IPsec with replay protection is
now a SHOULD in RFC 2869bis; this is already supported in Diameter. So I
think that AAA is covered. We will add a requirement for replay protection
in the Secure Association protocol, as well as a requirement that key
generating EAP methods support replay protection. If we do this, I think
we are covered on Issue #5.

Issue #6 requires mutual auth in all three legs -- EAP, AAA, and the
secure association protocol. AAA protocols already do mutual
authentication -- both RADIUS & Diameter handle this.  So I think we need
a requirement that EAP key deriving methods and secure association
protocols support mutual authentication, and Issue #6 is handled.

I believe that Issue #7 relates to AAA protocol confidentiality. RADIUS
over IPsec and Diameter both support confidentiality.  If this also
encompasses Identity Protection this can be satisfied by methods which
provide for a protected Identity exchange (e.g. EAP-Request/Identity is
optional).

EAP does not support plaintext passwords (no PAP). So Issue #8 is handled.

On Issue #9, we have added language in both Diameter NASREQ and RFC
2869bis relating to NAS authorization. Client authorization is an
intrinsic part of EAP, not just authentication. So I think we have some
progress here as well.

One Issue #10, we have discussed the use of Redirects in Diameter to
ensure that the MSK is only available to the AAA Server, NAS and EAP peer.
That is, through redirect the NAS and AAA Server can exchange keys
directly. RADIUS does not support redirect, so that for Issue #10 to be
satisfied it is necessary to have NAS devices talk directly to RADIUS
servers.

Since neither EAP nor AAA are involved in secure capabilities negotiation,
Issue #11 is really a problem for the secure association protocol.
Currently IEEE 802.11i does securely negotiate the ciphersuite, but
unfortunately does not securely confirm the other capabilities -- creating
a potential security vulnerability.  But the basic requirements of Issue
#11 appear to be met.

Issue #13 appears to be met if the MSKs generated at each NAS are
cryptographically independent of each other, OR if the EMSK is used to
generate keys in such a way that a NAS with knowledge of its own key
cannot guess the key of another NAS. Since the EMSK is never transported,
a simple PRF construction can achieve this. So I think we can satisfy
Issue #13.

The remaining Issues are #12 and #14.  These are a number of issues here
and we will discuss these at IETF 57.

Issue #12 is really about how to name the EAP SA and the associated key
hierarchy (MSK, EMSK, etc.).  Fundamentally, an EAP SA is negotiated
between the EAP peer and EAP server, and is "named" by the individual EAP
method. For example, EAP-TLS, PEAP, and EAP-TTLS use the TLS "Session-Id"
to name the keys.

So it would appear to me that the 3-tuple of the (Peer NAI, Server Name,
EAP method key name) is sufficient to name the EAP SA. Note that this
scheme assumes that it is possible for an EAP peer and EAP server to have
more than one valid EAP SA at a time.

One issue that arises here is that EAP, unlike IKE Phase 1, does not have
an SA deletion operation. So once an EAP SA is formed, it stays around
until its lifetime expires.  However, there is no way for the peer and EAP
server to negotiate exactly what that lifetime is, particularly since a
NAS may decide to reboot or flush key state at any time.

One interesting question is whether the NAS name enters into the EAP SA
naming scheme. It is possible for the EAP client to learn the NAS name
(e.g. through the EAP-Request/Identity), and while Issue #11 would be
violated if the same MSK were to be reused on multiple NASes, I don't
think that it is a good idea to tie an EAP SA to a particular NAS. If NAS
devices provide failover, it well might be possible for an EAP SA to migrate from
one NAS to a backup during a fault. Tying the EAP SA name to the NAS name
would prevent such a migration from occuring.

Since a secure association (Phase 2 SA) is derived from keying material
established by EAP authentication (Phase 1 SA), to "bind" the two phases
together, it is necessary for the secure association protocol to name the
EAP keying material that it is based on.  The EAP SA name may not be
sufficiently granular for this -- since it doesn't distinguish between the
MSK (or portions thereof, such as the PMK) and the EMSK. So some
additional qualifiers may be needed to make this specific enough.

One question is how all parties (EAP peer, AAA server, NAS) come to know
the EAP SA name. The peer and EAP server come to know it via the EAP
method conversation -- they exchange identities and the method provides a
session identifier.  One must then presume that the EAP server exports the
EAP SA name along with the MSK and EMSK and binds this together within the
AAA protocol packet sent to the NAS.  That way the NAS not only gets the
keys, but also the name associated with those keys, for use in the secure
association protocol.

The secure association protocol is where the binding of the EAP SA keying
material to the "context" (e.g. Phase 2 secure association) occurs. This
is how Issue #14 is addressed. While EAP is responsible for mutual auth,
replay protection, and derivation of key material, including freshness
and EAP SA key naming, the secure association protocol (Phase 2) does the heavy lifting.
It is responsible for:

a. Secure capabilities negotiation (including ciphersuites)
b. Mutual authentication
c. Transient session key derivation (including freshness)
d. Secure association naming
e. Binding of the EAP SA to the secure association (Phase 2 SA). This
occurs by utilizing the EAP SA name within the Phase 2 exchange.
f. TSK activation, deletion, and rekey.

Since the secure association protocol handles secure capabilities
negotiation there is no need for EAP or AAA to handle this. By supporing
mutual auth, the secure association protocol confirms possession of the
named EAP SA keying material on both sides.  Note that if there is any
vaguness in the naming of the EAP SA keying material, then this step might
fail by mistake.  By including freshness (e.g. a two-way nonce exchange)
in the secure association protocol, the TSKs can be guaranteed to be fresh
even if for some reason the EAP MSK and EMSK are not. So we have "belt and
suspenders" protection against TSK reuse.

We need to name the secure association (Phase 2) so that the derived TSKs
can be bound to subsequent data traffic. In IPsec this is handled via the
SPI and destination address; 802.10 had the SAID; 802.11 only has the
keyID which is not a very good substitute.

To make it clear which EAP SA is used to derive the Phase 2 SA, it becomes
possible to bind the EAP SA to the "context" (e.g. secure associations)
with which it will be used.

Secure association protocols need to support both activation and deletion
of transient session keys.  Deletion is useful so that a NAS that needs to
purge key state can securely notify peers that it is deleting their key
state. This is not strictly required (the NAS could just age out the
keys), but it does make it more possible for a highly secure EAP peer to
refuse to act on insecure deletion messages.  In effect, the IEEE 802.11
Disassociate and Deauthenticate messages are deletion messages, but they
are not secured in IEEE 802.11i.

TSK activation is equivalent to activating the Phase 2 (secure
association), and as part of that process, an EAP peer is formally
"joined" to the network -- data traffic can now be sent since keys are
synchronized. That's why we call Phase 2 a secure association protocol --
it really is about creating a secure association, both in the IPsec (SA)
sense (e.g. security parameters negotiated and bound), as well as in the
IEEE 802.11 "Association" sense (peer negotiates capabilities and joins
the network).

---

From: [email-masked] (Joseph Salowey)
Date: Wed, 9 Jul 2003 21:50:47 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Bernard Aboba
> Sent: Wednesday, July 09, 2003 12:52 AM
> To: [email-masked]
> Subject: [eap] EAP key naming
> 
> 
> At IETF 56, during the AAA WG meeting, Russ Housley the 
> Security Area Director, provided a roadmap for EAP and AAA 
> keying, by listing the characteristics that a proposed 
> solution MUST satisfy.
> 
> This message summarizes current thinking on how the EAP 
> Keying Framework satisfies those requirements.  As noted 
> below, we have a better handle on some of the Issues than 
> others;  in particular Issue 12 needs more work. The most 
> current version of the EAP Keying Framework is available at:
> 

[Joe] I am confused by requirement 7, what does this mean?

> 14. Bind key to appropriate context
<snip>

> RFC 2284bis includes a mandatory to implement algorithm, 
> albeit one which does not generate keys or do mutual 
> authentication.  At IETF 56, EAP WG received a request from 
> IEEE 802.11 to change the mandatory-to-implement algorithm to 
> one which does derive keys.  However, as discussed by Erik 
> Nordmark, while it might make sense for EAP usage communities 
> to define their own mandatory algorithms, it is likely that 
> those communities would resist having a single 
> mandatory-to-implement algorithm imposed on all of them.  So 
> Issue #2, appears to be the responsibility of individual EAP 
> usage communities.
> 

[Joe] I'm not sure that this is sufficient to meet the requirement.
EAP-MD5 does not cut it, there should be at least one generally
applicable method that is widely implemented.  Perhaps EAP-TLS would be
good.

<snip>
> 
> I believe that Issue #7 relates to AAA protocol 
> confidentiality. RADIUS over IPsec and Diameter both support 
> confidentiality.  If this also encompasses Identity 
> Protection this can be satisfied by methods which provide for 
> a protected Identity exchange (e.g. EAP-Request/Identity is optional).
> 
[Joe] I have no idea what #7 is referring to.

<snip>

> Since neither EAP nor AAA are involved in secure capabilities 
> negotiation, Issue #11 is really a problem for the secure 
> association protocol. Currently IEEE 802.11i does securely 
> negotiate the ciphersuite, but unfortunately does not 
> securely confirm the other capabilities -- creating a 
> potential security vulnerability.  But the basic requirements 
> of Issue #11 appear to be met.
> 

[Joe] Individual EAP methods are responsible for securing the
negotiation of ciphersuites they use such as TLS.  In addition the same
would be true for AAA protocols.

<snip>

> Issue #12 is really about how to name the EAP SA and the 
> associated key hierarchy (MSK, EMSK, etc.).  Fundamentally, 
> an EAP SA is negotiated between the EAP peer and EAP server, 
> and is "named" by the individual EAP method. For example, 
> EAP-TLS, PEAP, and EAP-TTLS use the TLS "Session-Id" to name the keys.
> 
[Joe] If I remember correctly the TLS session-ID lasts through session
resumption so it is associated with more than one MSK.  The client and
server randoms can be used to identify an MSK.

> So it would appear to me that the 3-tuple of the (Peer NAI, 
> Server Name, EAP method key name) is sufficient to name the 
> EAP SA. Note that this scheme assumes that it is possible for 
> an EAP peer and EAP server to have more than one valid EAP SA 
> at a time.
> 

[Joe]If the EAP method key name includes information such as nonces that
uniquely identify an EAP exchange it would seem that this is sufficient.

How are these quantities derived? 

Is the Peer NAI from the identity request? What happens if there is no
identity request? 
Then the name is method specific. This should be part of the EAP method
key name.

Where does the server name come from?  This name is also EAP method
specific and should be part of the EAP method key name.

Perhaps the EAP method should export x number of bytes as the key name.
The name would be derived from quantities know to the EAP method such as
nonces identities etc.   The method would explain how this dervation is
done.  For existing methods they keying draft could suggest something. 

> One issue that arises here is that EAP, unlike IKE Phase 1, 
> does not have an SA deletion operation. So once an EAP SA is 
> formed, it stays around until its lifetime expires.  However, 
> there is no way for the peer and EAP server to negotiate 
> exactly what that lifetime is, particularly since a NAS may 
> decide to reboot or flush key state at any time.
> 
> One interesting question is whether the NAS name enters into 
> the EAP SA naming scheme. It is possible for the EAP client 
> to learn the NAS name (e.g. through the 
> EAP-Request/Identity), and while Issue #11 would be violated 
> if the same MSK were to be reused on multiple NASes, I don't 
> think that it is a good idea to tie an EAP SA to a particular 
> NAS. If NAS devices provide failover, it well might be 
> possible for an EAP SA to migrate from one NAS to a backup 
> during a fault. Tying the EAP SA name to the NAS name would 
> prevent such a migration from occuring.
> 

[Joe] An EAP SA is between the EAP-PEER and EAP-Server.  The base SA is
not NAS dependent.  Since MSK should be transmitted to one and only one
NAS perhaps the MSK can involve the NAS name, but the EMSK should not.

> Since a secure association (Phase 2 SA) is derived from 
> keying material established by EAP authentication (Phase 1 
> SA), to "bind" the two phases together, it is necessary for 
> the secure association protocol to name the EAP keying 
> material that it is based on.  The EAP SA name may not be 
> sufficiently granular for this -- since it doesn't 
> distinguish between the MSK (or portions thereof, such as the 
> PMK) and the EMSK. So some additional qualifiers may be 
> needed to make this specific enough.
> 

[Joe] I think you will need more granularity than this, the EMSK should
not be used by itself additional application specific master keys (AMSK)
should be derived from it.  In any case the EAP SA name should be the
base name.  This can be extended in a standard to refer to keys derived
from this base SA (MSK,EMSK,AMSK).  This naming is also necessary when
keys must be requested from the EAP server.  

> One question is how all parties (EAP peer, AAA server, NAS) 
> come to know the EAP SA name. The peer and EAP server come to 
> know it via the EAP method conversation -- they exchange 
> identities and the method provides a session identifier.  One 
> must then presume that the EAP server exports the EAP SA name 
> along with the MSK and EMSK and binds this together within 
> the AAA protocol packet sent to the NAS.  That way the NAS 
> not only gets the keys, but also the name associated with 
> those keys, for use in the secure association protocol.
> 
> The secure association protocol is where the binding of the 
> EAP SA keying material to the "context" (e.g. Phase 2 secure 
> association) occurs. This is how Issue #14 is addressed. 
> While EAP is responsible for mutual auth, replay protection, 
> and derivation of key material, including freshness and EAP 
> SA key naming, the secure association protocol (Phase 2) does 
> the heavy lifting. It is responsible for:
> 
> e. Binding of the EAP SA to the secure association (Phase 2 
> SA). This occurs by utilizing the EAP SA name within the 
> Phase 2 exchange. f. TSK activation, deletion, and rekey.
> 
> Since the secure association protocol handles secure 
> capabilities negotiation there is no need for EAP or AAA to 
> handle this. By supporing mutual auth, the secure association 
> protocol confirms possession of the named EAP SA keying 
> material on both sides.  Note that if there is any vaguness 
> in the naming of the EAP SA keying material, then this step 
> might fail by mistake.  By including freshness (e.g. a 
> two-way nonce exchange) in the secure association protocol, 
> the TSKs can be guaranteed to be fresh even if for some 
> reason the EAP MSK and EMSK are not. So we have "belt and 
[Joe] It should be a requirement that the EAP MSK and EMSK are fresh
every time an EAP method is run.

> We need to name the secure association (Phase 2) so that the 
> derived TSKs can be bound to subsequent data traffic. In 
> IPsec this is handled via the SPI and destination address; 
> 802.10 had the SAID; 802.11 only has the keyID which is not a 
> very good substitute.
> 
> To make it clear which EAP SA is used to derive the Phase 2 
> SA, it becomes possible to bind the EAP SA to the "context" 
> (e.g. secure associations) with which it will be used.
> 
> Secure association protocols need to support both activation 
> and deletion of transient session keys.  Deletion is useful 
> so that a NAS that needs to purge key state can securely 
> notify peers that it is deleting their key state. This is not 
> strictly required (the NAS could just age out the keys), but 
> it does make it more possible for a highly secure EAP peer to 
> refuse to act on insecure deletion messages.  In effect, the 
> IEEE 802.11 Disassociate and Deauthenticate messages are 
> deletion messages, but they are not secured in IEEE 802.11i.
> 
> TSK activation is equivalent to activating the Phase 2 
> (secure association), and as part of that process, an EAP 
> peer is formally "joined" to the network -- data traffic can 
> now be sent since keys are synchronized. That's why we call 
> Phase 2 a secure association protocol -- it really is about 
> creating a secure association, both in the IPsec (SA) sense 
> (e.g. security parameters negotiated and bound), as well as 
> in the IEEE 802.11 "Association" sense (peer negotiates 
> capabilities and joins the network). 
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
>

---

From: [email-masked] (Bernard Aboba)
Date: Wed, 9 Jul 2003 21:48:00 -0700 (PDT)

> [Joe] I am confused by requirement 7, what does this mean?

I obvious don't know either :) Will probably need to ask Russ for an
explanation.

> applicable method that is widely implemented.  Perhaps EAP-TLS would be

EAP-TLS may not work in all circumstances -- it requires certificates, is
client/server, not peer-to-peer, takes quite a few round-trips. I suspect
that quite a few communities would object to one or more of these
properties.

> [Joe] I have no idea what #7 is referring to.

I took a guess, based on what was in Russ's slides. If that's not the
right guess, we can try another one :)

> would be true for AAA protocols.

Sure.  We should probably state that explicitly.

> server randoms can be used to identify an MSK.

Yes, the session-Id really names the MK, and the client and server randoms
identify the MSK.

> uniquely identify an EAP exchange it would seem that this is sufficient.

Yes, I think that makes sense.

> Then the name is method specific. This should be part of the EAP method

I think we get ourselves into trouble if the EAP SA name depends on an
unsecured exchange such as EAP Identity Request/Response. So it makes
sense to me to require some kind of method-specific protected name
exchange and to base the EAP SA name on that.

> specific and should be part of the EAP method key name.

Yes, I think so. It certainly can't be expected to be provided in the
EAP-Request/Identity -- that is created by the NAS in most cases.

> done.  For existing methods they keying draft could suggest something.

Yes.  That has the advantage of allowing the EAP SA and MSK names to be
sent across to the NAS by the AAA server.

> NAS perhaps the MSK can involve the NAS name, but the EMSK should not.

Yes, I agree with this.

> keys must be requested from the EAP server.

Yes. The question is how to name the derivatives of the EMSK.

> every time an EAP method is run.

Yes.

---

From: [email-masked] (Robert Moskowitz)
Date: Thu, 10 Jul 2003 11:20:13 -0400

>more than one valid EAP SA at a time.

Here is what I am working up as the key name:

KeyID = Truncate-128(SHA1(NAI || EAP Method Type || Key || 
Called-Station-Id || Calling-Station-Id || "The name is the game"))

And for 'Key' you can substitute:

MK
MSK
EMSK
PMK

Not all of these may need Ids, but the option should be there.

Note that this names the key as:

Who is the key for
 From What system
Through What authenticator
         (optionally on what network see Annex D of 802.1aa)
Via What methodology

It produces very unique KeyIDs, and peer and AS will have very few IDs 
built on the same information (AS will be timing old ones out, the peer 
will have to use heiristics to age old IDs).

There are a few problems with this.

Which NAI?  The method 'knows' and should provide that going outward.  E.G. 
PEAP/MSCHAPv2, it is the NAI in the MSCHAPv2 part.

Which EAP Method Type?  What would you use for PEAP/MSCHAPv2 compared to 
PEAP/TLS?  I don't have the answer to that one.

Robert Moskowitz
TruSecure Corporation
Security Interest EMail: [email-masked]

---

From: [email-masked] (Joseph Salowey)
Date: Thu, 10 Jul 2003 09:40:16 -0700

What are the requirements for naming?  Is something required beyond a
unique identifier?  If there are other requirements we need to
explicitly state them.

If it is uniquness that we are after then I don't see what is wrong with
requiring the method to gereate a name from the random nonces it uses
(it could use other data as well).  

Joe 

> On Behalf Of Robert Moskowitz
> Sent: Thursday, July 10, 2003 8:20 AM
> To: Bernard Aboba; [email-masked]
> Subject: Re: [eap] EAP key naming
> 
> 
> >So it would appear to me that the 3-tuple of the (Peer NAI, Server 
> >Name, EAP method key name) is sufficient to name the EAP SA. 
> Note that 
> >this scheme assumes that it is possible for an EAP peer and 
> EAP server 
> >to have more than one valid EAP SA at a time.
> 

[Joe] I don't think the

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 10 Jul 2003 09:51:40 -0700 (PDT)

> And for 'Key' you can substitute:

I don't think that this formula works.

As Joe noted, the MK is named by the EAP method, and
since it is purely between the EAP peer and EAP server, it can have no
dependence on Called-Station-Id, Calling-Station-Id and least of all the
MK itself, which can't be exported. EAP methods have their own MK names
(in TLS this is the session-id).

As Jesse noted, the EAP SA is uniquely named by the combination of EAP peer NAI,
the EAP server name, and the nonces.  The called-station-id and
calling-station-id do not play a role.

As Jesse also noted, the MSK is named by the EAP SA name + a NAS name (for
which the Called-Station-Id may be used as a surrogate). The
Calling-Station-Id does not play a part, and neither does the actual MSK
itself.

The EMSK has a name of the EAP SA name + a static string. So the formula
looks off there too.

It would seem to me that the PMK has no unique name of its own, just the
name of its parent + potentially an additional string.  So if the PMK is
derived from the MSK, then it has a name of the MSK name + "lower 32 bits"
or something like that, whereas if it is derived from the EMSK, it has a
name of the EMSK name + a static string.

---

From: [email-masked] (Robert Moskowitz)
Date: Fri, 11 Jul 2003 11:45:04 -0400

>I don't think that this formula works.

Your. right. It only works for the PMK.  A little too fast with the fingers 
there.

>(in TLS this is the session-id).

It can be based on the MK, as in a hash, it is not being 'exported', no mor 
that creating the MSK.

Not the Called-Station-Id, granted.  But I argue that the peer is on a 
station and the MK is only for the peer on that station.  So I get:

MKID = Truncate-128(SHA1(NAI || EAP Method Type || MK || Calling-Station-Id 
|| "The Master name is the game"))

>calling-station-id do not play a role.

Nonces?  What Nonces?  Do all EAP methods have nonces?

EAP server name is nice, but does the peer 'know' it?  The closest is the 
domain part of the NAI.

Again, I was wrong on the called-Station-id, the MSK and EMSK are 
independent of the peer's connection to the network.  It would be valuable 
to include the network name in here, but the PANA people seem to think 
that  SAs will be portable across billing domains (I don't), and anyway 
there is no direct variable to get the network name into the process (in 
802.11, the SSID is appended to the called-station-id).  So I get:

[E]MSKID = Truncate-128(SHA1(NAI || EAP Method Type || [E]MSK || 
Calling-Station-Id || "The Session name is the game"))

>Calling-Station-Id does not play a part, and neither does the actual MSK

The MSK can't have the NAS name in it, as that would limit the portablity 
of it across NASs for roaming.  Though that may not really matter so much.

>The EMSK has a name of the EAP SA name + a static string. So the formula

Even though the method may not have the information about its environment, 
that information can readily be made available to it by making 
called-station-id and calling-station-id global variables.  As I noted, 
called-station-id may not apply, other than to pick off the network 
name.  Naming SAs in this manner is very valuable.  Of course it is not 
necessary, as these values will be variables in the SA anyway.

>name of the EMSK name + a static string.

Again.  a name by any name.  these values are available at the time of name 
construction.  they are part of the PMK.  THere is no reason NOT to include 
them.  Given the way hash functions supposedly work, it would seem that 
including the addional bytes don't hurt and should help.

PMKID = Truncate-128(SHA1(NAI || EAP Method Type || PMK || 
Called-Station-Id || Calling-Station-Id || "The name is the game"))

Robert Moskowitz
ICSAlabs/A Division of TruSecure Corporation
Security Interest EMail: [email-masked]