Subject: [eap] EAP key naming

From: [email-masked] (Walker, Jesse)
Date: Wed, 9 Jul 2003 13:52:24 -0700

Bernard,

This is a good summary. Thanks. I have a few comments below.

> 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

There is (at least) one missing requirement: a key deriving EAP method must, if it completes successfully, leave the EAP Server and EAP Peer with synchronized session state. At the very least the EAP Server and EAP Peer must believe that the same NAIs have been authenticated, must share the same session key, and must have the same name for the session key. This does not follow necessarily from the other requirements.

It may be worth devoting a few words to the effect that the requirements are system requirements. Some of them apply to EAP methods, some to the backend protocols like RADIUS or DIAMETER, some to system design, etc. It is not clear to me that any of them apply to EAP per se.

<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.

This misconstrues IEEE 802.11's request. The observation is that the base EAP document requires IEEE 802.11 systems with 802.1X Supplicants to implement MD5 Challenge, when in fact it should expressly prohibit their use in this context. Mandating its implementation without prohibiting its use in certain contexts demands that users decide for themselves in many contexts, and many users are not equipped to make this decision.

The mandatory-to-implement method either should be safe in all environments, or else there should be no mandatory-to-implement method. The line of reasoning you make above suggests you would support removing MD5 Challenge as mandatory-to-implement. That would probably be an acceptable resolution. However, the status quo is not acceptable.

<snip>

> 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.

We should make random nonce exchange an explicit requirement for key deriving EAP methods, so that everyone knows what we are really talking about. We can require at least 128 bit random nonces, with 256 bits being a should--random objects are subject to birthday attack. See more below regarding issue #12.

<snip>

> 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.

This is not an EAP issue; it relates to the back-end. The key draft can dismiss it as out of scope and point to some other document, e.g., a AAA keying document.

Even though it is out of scope, it is worth pointing out that the assumption that IPsec can be used for replay protection is not valid for key management protocols; key distribution isn't merely distributing so many bits of data, which is the assumption behind IPsec. The use of IPsec for replay in the key management function assumes that the entire system at each end of the link has been evaluated to be secure. Such an assumption would deny a great many markets to almost all servers made by your company.

> 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.

Again, this is not an EAP issue, and I think it fair if the EAP key naming draft punts on it.

> 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).

Issue #7 bears more discussion; I'm confused by it, any way. I don't know what issue #7 is trying to say, but data confidentiality is a radically different thing from "Identity Protection." Either the discussion is wrong or the issue is not stated correctly, because the two do not coincide.

<snip>

> 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.

This one is outside the scope of EAP and should be dealt with in AAA or RADIUS and the like. The EAP document should say this is a requirement on the overall system design, not EAP or the EAP method.

Having said that, if I understand what you wrote, it misses the point. The point of issue #10 is that if the EAP Server generates a key for the NAS, then the key is compromised from the EAP Peer's perspective if the EAP Server shares the key with ***ANY*** party besides the particular NAS the EAP Peer is dealing with. Indeed, we could reword Issue #10 to "EAP Server will honor the EAP Peer's trust assumption, by not (intentionally) revealing the MSK to any party but the Peer's NAS." When symmetric keys are used to secure the channel between the EAP Server and the NAS, this says that the EAP Server and NAS share a security association directly between them for the express purpose of key distribution. This is a requirement that most vendors and operators hate, but it is what #10 is trying to say. People want public/private key semantics at the cost of symmetric keys. No one has suggested how to make such a design work.

<snip>

> 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.

This almost but not quite right. Such a naming scheme does not distinguish names across sessions between the same EAP Peer and EAP Server. Think of the case where there is key roll-over due to reauthentication. Does the name refer to the old or to the new key? It refers to both, the scheme does not unambiguously identify the key, and the parties will not be able to tell which to use (they will not necessarily share the same notion of which one is current). There does not seem to be any choice but to (a) mandate that key-deriving EAP methods exchange nonces and (b) the nonces are part of the name.

<snip>
> 
> 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.

The NAS name is not germane. The relationship is between the EAP Peer and the EAP Server.

> 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.

Since the MSK and ESMK are wholly compromised from the EAP Peer's perspective if either is ever shared with more than one NAS, we know that such key sharing cannot be allowed, so it is safe to use the NAS name as part of the MSK name; indeed, it would be rather odd if this were not the case.

This would make the key name something like <Peer NAI, Server NAI, Peer Nonce, Server Nonce, NAS NAI>. If we are unlucky this can consume 832 octets, assuming 32 octet nonces and full size NAIs. This may be too heavy-weight to use in many of the contexts (e.g., roaming) that motivate its definition. It would therefore be useful to define a standard identifier similar to an X.509 certificate's fingerprint, e.g.,

	KeyID = SHA1(Peer NAI | Server NAI | Peer Nonce | Server Nonce |NAS NAI)

This, of course, is not the question you were asking. To distinguish the MSK from the EMSK, add an arbitrary label to the end of the tuple.

<snip>

> 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

I'm not sure I follow this. There are at least two levels of security association, at least implicitly, and it is not clear which issue #14 refers to.

If the "binding" language refers to the key derived by the EAP method, then the binding is the collection of synchronized state. It is within EAP's purview to establish requirements for this, as I indicated above by pointing out that we missed the synchronization requirement.

If issue #14 is refering to key distribution, then your discussion is reasonable, but the whole thing falls outside of EAP's scope, as it relates to the key distribution mechanism. I think?

> 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)

I think the EAP method should only be made accountable for negotiating the cipher suites it uses itself?

> 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.

No. 802.11i uses the MAC addresses of the STA and the AP to identify the key. The (pairwise) key is always bound to WEP KeyID 0 in 802.11i, so the KeyID does not tell us anything except that it is a pairwise key.

In the case of 802.11, what is important is the right key gets delivered to the right AP, and never to any other party whatsoever. Vis-a-vis the binding discussion, this translates into a requirement for the EAP Server to be able assert that the key is bound to the pair <STA MAC Address, AP MAC Address>, because that is the only meaningful key identifier at the MAC layer. This is what the Bindings field is for in the Archie Response and Confirm messages. An alternate approach might be to modify EAP directly to convey this information instead, since your standard run-of-the-mill EAP method does not have this exchange built in like Archie does.

For other cases besides 802.11, mileage will vary; how to do the binding will be protocol specific.

<snip>

That's my two cents, for what it is worth.

-- Jesse

---

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

> There is (at least) one missing requirement: a key deriving EAP method must,
> if it completes successfully, leave the EAP Server and EAP Peer with
> synchronized session state. At the very least the EAP Server and EAP
> Peer must believe that the same NAIs have been authenticated, must share the
> same session key, and must have the same name for the session key. This
> does not follow necessarily from the other requirements.

That seems reasonable, although I am not clear that synchronization can be
maintained beyond the initial exchange, since either the peer or EAP
server can age out key state and there is no EAP "delete" message to
ensure synchronization.

> It may be worth devoting a few words to the effect that the requirements
> are system requirements. Some of them apply to EAP methods, some to the
> backend protocols like RADIUS or DIAMETER, some to system design, etc.
> It is not clear to me that any of them apply to EAP per se.

Yes. We'll need to make it clear what requirements apply to what
protocols.  There are some grey areas that may be worth discussing.

> This misconstrues IEEE 802.11's request. The observation is that the base EAP
> document requires IEEE 802.11 systems with 802.1X Supplicants to
> implement MD5 Challenge, when in fact it should expressly prohibit their
> use in this context. Mandating its implementation without prohibiting
> its use in certain contexts demands that users decide for themselves in many
> contexts, and many users are not equipped to make this decision.

It seems reasonable to indicate that MD5 Challenge is inappropriate in
some circumstances.  Would you care to file an issue indicating what text
you'd like to add?

> The mandatory-to-implement method either should be safe in all environments,
> or else there should be no mandatory-to-implement method. The line of
> reasoning you make above suggests you would support removing MD5
> Challenge as mandatory-to-implement. That would probably be an
> acceptable resolution. However, the status quo is not acceptable.

I don't think that having no mandatory-to-implement method is an
acceptable alternative. As noted in Erik Nordmark's presentation at IETF
56, we can add text to RFC 2284bis indicating the minimum requirements for
various circumstances, and the security claims language should make it
clear what methods meet those requirements (no methods defined in RFC
2284bis are appropriate for use with 802.11).

There are lots of examples of mandatory-to-implement methods in IETF
protocols that can be used inappropriately or may not work in all
circumstances. So I'm not sure that it's necessary (or even possible) to
create a single method that would be suitable for all potential uses of
EAP.

That's part of the problem -- getting agreement on what the mandatory
method should be would probably require a formal beauty contest that could
consume up to a year of the WG's time.  As Erik suggested at IETF 56, our
time would probably be better spent reviewing and publishing a variety of
methods, and making sure their security properties were well
understood and letting the market decide.

> We should make random nonce exchange an explicit requirement for
> key deriving EAP methods, so that everyone knows what we are really
> talking about. We can require at least 128 bit random nonces, with 256
> bits being a should--random objects are subject to birthday attack. See
> more below regarding issue #12.

Yes, I think this makes sense.

> This is not an EAP issue; it relates to the back-end. The key draft can
> dismiss it as out of scope and point to some other document, e.g., a AAA
> keying document.

I wasn't clear what replay threat was to being referred to, so I assumed
that it was all potential threats. It's not unreasonable to require replay
protection in all three "legs", though.

> Even though it is out of scope, it is worth pointing out that the
> assumption that IPsec can be used for replay protection is not valid for
> key management protocols; key distribution isn't merely distributing so
> many bits of data, which is the assumption behind IPsec. The use of
> IPsec for replay in the key management function assumes that the
> entire system at each end of the link has been evaluated to be secure.

It's true that IPsec typically only provides "machine authentication" and
that IPsec SAs, once created, can be used by any process on the machine.
So one has to depend on facilities of the operating system in order to
make sure that keying material isn't leaked within the machine.
Application layer confidentiality is better in that respect.  It's worth
noting that Diameter supports TLS so that an application-specific SA can
be used to protect the keys.

> > protocols support mutual authentication, and Issue #6 is handled.

Russ's requirements apply to the system as a whole, so it probably makes
sense to describe the requirements for each piece.  I don't think we can
punt on this particular issue.

> Issue #7 bears more discussion; I'm confused by it, any way.
> I don't know what issue #7 is trying to say, but data confidentiality is
> a radically different thing from "Identity Protection." Either the
> discussion is wrong or the issue is not stated correctly, because the
> two do not coincide.

I'm obviously confused by Issue #7 too.  I just took a guess at what it
*might* mean.

> This one is outside the scope of EAP and should be dealt with in AAA or
> RADIUS and the like. The EAP document should say this is a requirement
> on the overall system design, not EAP or the EAP method.

Sure, that's reasonable.

> Having said that, if I understand what you wrote, it misses the point.
> The point of issue #10 is that if the EAP Server generates a key for the
> NAS, then the key is compromised from the EAP Peer's perspective if the
> EAP Server shares the key with ***ANY*** party besides the particular
> NAS the EAP Peer is dealing with. Indeed, we could reword Issue #10
> to "EAP Server will honor the EAP Peer's trust assumption, by not
> (intentionally) revealing the MSK to any party but the Peer's NAS." When
> symmetric keys are used to secure the channel between the EAP Server and
> the NAS, this says that the EAP Server and NAS share a security
> association directly between them for the express purpose of key
> distribution. This is a requirement that most vendors and operators
> hate, but it is what #10 is trying to say. People want public/private
> key semantics at the cost of symmetric keys. No one has suggested how to
> make such a design work.

Yes, I think this is what #10 is trying to say.

> This almost but not quite right. Such a naming scheme does not
> distinguish names across sessions between the same EAP Peer and EAP
> Server. Think of the case where there is key roll-over due to
> reauthentication. Does the name refer to the old or to the new key? It
> refers to both, the scheme does not unambiguously identify the key, and
> the parties will not be able to tell which to use (they will not
> necessarily share the same notion of which one is current). There does
> not seem to be any choice but to (a) mandate that key-deriving EAP
> methods exchange nonces and (b) the nonces are part of the name.

I agree that the EAP peer and EAP server names do not uniquely define the
EAP SA. However, EAP method such as EAP-TLS often have a session-id or its
equivalent.  Certainly a nonce exchange can help, and since we are going
to require that, perhaps your suggestions a) and b) are a way to guarantee
that the requirements are satisfied.

> The NAS name is not germane. The relationship is between the EAP Peer

Yes, I agree.

> Since the MSK and ESMK are wholly compromised from the EAP Peer's perspective
> if either is ever shared with more than one NAS, we know that such key
> sharing cannot be allowed

The EMSK is compromised if it is known by *any* NAS.  The MSK is
compromised if it is shared by more than one NAS.

> so it is safe to use the NAS name as part of
> the MSK name; indeed, it would be rather odd if this were not the case.

So you're saying that the MSK name is different from the EAP SA
name? Is this solely because the EAP SA is not "bound" to a NAS while the
MSK is bound?  What about the EMSK?  This is not "bound" to a particular
NAS -- so is it's name the same as the EAP SA name? What about quantities
derived from the EMSK?  How do we name those?

> This would make the key name something like <Peer NAI, Server NAI, Peer Nonce, Server Nonce, NAS NAI>

So the first 4 quantities are the EAP SA name, and the MSK name is the EAP
SA name + the NAS NAI.  Is it fair to say that the EMSK name is the same
as the EAP SA name?

> If we are unlucky this can consume 832 octets, assuming 32 octet nonces
> and full size NAIs. This may be too heavy-weight to use in many of the
> contexts (e.g., roaming) that motivate its definition. It would
> therefore be useful to define a standard identifier similar to an X.509
> certificate's fingerprint, e.g.,
>

OK -- at least the KeyID is a hash of the MSK name, and not a hash of the
key itself as was originally proposed (shudder).

> This, of course, is not the question you were asking.

Actually, it is part of the question.

> To distinguish the MSK from the EMSK, add an arbitrary label to the end
> of the tuple.

I think you mean "to distinguish the EAP SA from the EMSK" add an
arbitrary label on the end of the EAP SA. I think that this would work as
long as that label is guaranteed not to conflict with the NAS NAI. Since
the EMSK is not bound to a NAS, I don't think that the NAS NAI can be part
of its name.

---

From: [email-masked] (Joseph Salowey)
Date: Wed, 9 Jul 2003 22:09:44 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Walker, Jesse
> Sent: Wednesday, July 09, 2003 1:52 PM
> To: Bernard Aboba; [email-masked]
> Subject: RE: [eap] EAP key naming
> 
> 
> Bernard,
> 

<snip>

> Since the MSK and ESMK are wholly compromised from the EAP 
> Peer's perspective if either is ever shared with more than 
> one NAS, we know that such key sharing cannot be allowed, so 
> it is safe to use the NAS name as part of the MSK name; 
> indeed, it would be rather odd if this were not the case.
>
[Joe] You are absolutely correct for the MSK, but the EMSK should not be
shared with anyone. It should only be know to the EAP-Peer and
EAP-Server.  Keys derived from the EMSK may be shared with other
parties.  The NAS name should not be used in a base identifier for the
EAP Keys.  Perhaps the base identifier can be augmented with the NAS
name to identify the MSK.

> This would make the key name something like <Peer NAI, Server 
> NAI, Peer Nonce, Server Nonce, NAS NAI>. If we are unlucky 
> this can consume 832 octets, assuming 32 octet nonces and 
> full size NAIs. This may be too heavy-weight to use in many 
> of the contexts (e.g., roaming) that motivate its definition. 
> It would therefore be useful to define a standard identifier 
> similar to an X.509 certificate's fingerprint, e.g.,
> 

[Joe] EAP method should be required define a base SA id that is derived
in a method specific way from its nonces, identities, etc.  This id is
fixed  16  bytes (perhaps more is better, but I'm feeling stingy and the
moment).   A hashing scheme like you propose above is an excellent way
to get the appropriate length.  This name can be decorated to refer to
keys associated with this base SA such as the MSK and application master
session keys (AMSK) derived from the EMSK.  This decoration can involve
the NAS NAI.  

> This, of course, is not the question you were asking. To 
> distinguish the MSK from the EMSK, add an arbitrary label to 
> the end of the tuple.
> 
> <snip>
> 
> I'm not sure I follow this. There are at least two levels of 
> security association, at least implicitly, and it is not 
> clear which issue #14 refers to.
> 
> If the "binding" language refers to the key derived by the 
> EAP method, then the binding is the collection of 
> synchronized state. It is within EAP's purview to establish 
> requirements for this, as I indicated above by pointing out 
> that we missed the synchronization requirement.
> 
> If issue #14 is refering to key distribution, then your 
> discussion is reasonable, but the whole thing falls outside 
> of EAP's scope, as it relates to the key distribution 
> mechanism. I think?
> 
> I think the EAP method should only be made accountable for 
> negotiating the cipher suites it uses itself?
> 
> No. 802.11i uses the MAC addresses of the STA and the AP to 
> identify the key. The (pairwise) key is always bound to WEP 
> KeyID 0 in 802.11i, so the KeyID does not tell us anything 
> except that it is a pairwise key.
> 
> In the case of 802.11, what is important is the right key 
> gets delivered to the right AP, and never to any other party 
> whatsoever. Vis-a-vis the binding discussion, this translates 
> into a requirement for the EAP Server to be able assert that 
> the key is bound to the pair <STA MAC Address, AP MAC 
> Address>, because that is the only meaningful key identifier 
> at the MAC layer. This is what the Bindings field is for in 
> the Archie Response and Confirm messages. An alternate 
> approach might be to modify EAP directly to convey this 
> information instead, since your standard run-of-the-mill EAP 
> method does not have this exchange built in like Archie does.
> 
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
>

---

From: [email-masked] (Joseph Salowey)
Date: Wed, 9 Jul 2003 23:05:14 -0700

<snip>

> the binding will be protocol specific.

[Joe] This is one area where chaining of additional messages after an
EAP method can be really useful.  Instead of having each method having
to define channel bindings and other bindings for n different
environments you define an EAP extension (for example an EAP-TLV message
with a Channel-Binding TLV) to carry this information.  It is
authenticated and possibly encrypted using keys derived from the EMSK
(shared only between the EAP-Peer and EAP-Server).  This extension could
be used with any key deriving EAP method.  These two drafts provide some
of the framework for this:

http://www.ietf.org/internet-drafts/draft-salowey-eap-key-deriv-01.txt
http://www.ietf.org/internet-drafts/draft-salowey-eap-protectedtlv-02.tx
t

What is left is to define a channel-binding-TLV (I think Jose may have
one in his binding problem draft, if not I have one sketched out based
on archie) and resolve the chaining issue (this requires a little bit
more work).

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 10 Jul 2003 04:41:52 -0700 (PDT)

> at the MAC layer.

I'm not clear that the MSK is bound to the Calling-Station-Id. As
we discussed previously, the MSK name is based on the <Peer name, AS name,
NAS Name> tuple. That implies that the MSK is bound to the Peer, not to a
particular interface.  The question is whether a peer with multiple 802.11
interfaces could use an MSK derived through one interface on another
interface. Intrinsically, I don't see anything wrong with this, although
it does seem to imply that we have "late binding" -- the TSKs are bound to
the pair <Calling-Station-Id, Called-Station-Id> but the the MSK is not.

> This is what the Bindings field is for in

We've discussed how the EAP SA is between the EAP peer and EAP server, and
therefore is not bound to a NAS.  The MSK name is the EAP SA name + the
NAS name. One issue is that is possible that the EAP peer may not know the NAS name,
only the Called-Station-Id, because the NAS name may not be  provided in
the EAP-Request/Identity. So I think that the MSK name probably needs to
include the Called-Station-Id as the NAS name. This also has an
implication for encapsulations of EAP that use a multicast destination
address, because in that case the Called-Station-Id may not be known -- I
think this implies that if key derivation is required then unicast
addresses must be used.

> > binding will be protocol specific.

EAP and AAA are media independent, so I don't think that this can be
media specific. One way to deal with this is to require
that the authentication server include the <Called-Station-Id,
Calling-Station-Id> tuple in the Access Accept, along with the MSK Name.
The Peer also has this information.

Then during the secure association protocol exchange (4-way handshake),
the EAP peer and NAS verify that they are using the same MSK and TSK
names.

This implies that the binding is verified during the secure association
exchange (Phase 2), not in the EAP exchange (Phase 1).  If so, then EAP
methods don't need to include a binding exchange.

---

From: [email-masked] (Jari Arkko)
Date: Sun, 13 Jul 2003 01:17:27 +0300

> It may be worth devoting a few words to the effect that the requirements are system requirements. Some of them apply to EAP methods, some to the backend protocols like RADIUS or DIAMETER, some to s…

Yes.

> This is not an EAP issue; it relates to the back-end. The key draft can dismiss it as out of scope and point to some other document, e.g., a AAA keying document.
...
> Again, this is not an EAP issue, and I think it fair if the EAP key naming draft punts on it.

I agree that some of the requirements that Bernard listed are not EAP
issues. However, the requirements put forward from the IESG are clearly
system requirements, and attempts to ensure that we understand the
properties of the system as a whole. I think we need to document
these issues in the keying draft, even if parts of the actual
realization of the requirements may fall on AAA or link layers.

--Jari