Subject: [eap] Re: KDF Negotiation for AMSK derivation

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 20 Mar 2006 05:37:37 -0800

Vidya said:

"It is a yet-to-be-defined thing and the computation is only done by the EAP
server and peer - could we just not pick a KDF and mandate it?"

One problem is that the KDF currently suggested for use in computing AMSKs
is based on SHA-1, which
NIST has suggested will be deprecated by 2010.  Given the movement of the US
and other governments 
toward the deployment of EAP-based access control, it is important that
FIPS-certifiable EAP-based 
solutions continue to be available going forward.  

Without the possibility of negotiation,  the adoption of a
soon-to-be-deprecated KDF implies 
that EAP itself will be deprecated by 2010.  As has been noted by others,
existing EAP methods 
do not negotiate KDFs either for their own use or for use in AMSK
generation, and adding this 
feature to existing or even new methods would be very difficult.  For
example, TLS (on which many
EAP methods are based) does not yet support KDF negotiation for its own use,
let along
for use in AMSK generation. 

These problems largely evaporate if AMSKs are generated by the lower layer,
since the lower layer
can then negotiate the appropriate KDF for their generation.  No changes
would be required for existing or 
new EAP methods.  No changes would be required to RFC 4137.  

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 21 Mar 2006 08:39:27 -0800

My terminology may be mixed up, but are we talking about the base 
algorithm for a PRF and not the negotiation of the full key 
derivation function?

To give an example,

IKEv2's KDF (although 4306 doesn't call it a KDF) is defined as:

prf+ (K,S) = T1 | T2 | T3 | T4 | ...

    where:
    T1 = prf (K, S | 0x01)
    T2 = prf (K, T1 | S | 0x02)
    T3 = prf (K, T2 | S | 0x03)
    T4 = prf (K, T3 | S | 0x04)

4307 lists the PRF base algorithms:

PRF_HMAC_MD5        1          [RFC2104]    MAY
PRF_HMAC_SHA1       2          [RFC2104]    MUST
PRF_AES128_CBC      4          [AESPRF]     SHOULD+

We could be talking about negotiating the "KDF" which to me means 
either IKEv2's prf+ or TLS prf and so on.  If we are talking about 
the underlying algorithm negotiation (which is my preference) then we 
have a choice of a hash or a cipher based PRF.  Bernard's concern 
seems to be about a particular hash algorithm.

A clarification will be useful for me to follow this discussion.

Oh, another thing here is (this came up in a discussion between Vidya 
N, Joe S and David M) whether we can just rely on the EAP methods to 
handle this.  I do note the comment about existing methods don't 
support negotiation, but from my recollection they are also all over 
the place in EMSK generation also.

Finally, Bernard, I was wondering if you can provide more details on 
why lower layers can negotiate the algorithms, while it is difficult 
for even new methods?  Thanks.

best regards,
Lakshminath

---

From: Jari Arkko <[email-masked]>
Date: Wed, 22 Mar 2006 06:48:43 -0600

>new EAP methods.  No changes would be required to RFC 4137. 

These are good arguments. Just to clarify what you are proposing --
are you saying that (a) we should deliver both MSK and EMSK to the
lower layer and that (b) in addition prohibit AAA from transporting
the EMSK?

If yes, I think I agree and maybe that's the way forward. I have
also re-read the relevant parts of the keying framework document
and I did not see any text changes that we would need to do.
It already says that the EMSK is exported to the lower layer and
that AAA transport of the EMSK is prohibited. Is there something
else that we need?

--Jari

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 22 Mar 2006 07:48:14 -0800

>lower layer and that (b) in addition prohibit AAA from transporting

Yes.

>that AAA transport of the EMSK is prohibited. Is there something

We might consider removing or changing some of the figures.  For example, it 
is not clear to me that Figure 4 adds value, so that it can be removed.

Figure 3 shows the flow of keying material and parameters within an EAP 
implementation.   Figure 1 already shows the parameters and keying material 
exported by methods, so this figure may not add very much that could not be 
contributed with some text.  For example:

1. Figure 1 shows the EAP method outputting the Method-ID, while Figure 3 
shows the lower layer obtaining the Session-ID.  In this case the observable 
behavior is that the lower layer and AAA layer is provided with a Session-ID 
which uniquely identifies the EAP conversation.   My suggestion is that we 
change figure 1 to show the EAP method outputting the Session-ID, while 
indicating that since the Session-ID uniquely identifies an EAP 
conversation, implementations should take care to prevent EAP methods from 
writing into each other's Session-ID space.   It is not necessary to get 
into the implementation details of how this accomplished (e.g. only letting 
the method process output the Method-ID, while having the EAP Type code 
automatically concatenated outside the method process space).

2.  Figure 3 also gets into the details of the flow of keying 
material/parameters to the lower layer.  To avoid potential conflicts with 
RFC 4137, my recommendation would be to focus on the externally verifiable 
behavior, which is that the EMSK must be protected from compromise.   The 
EMSK is available only to the EAP peer and server, is never transported to a 
third party.  While the lower layer can compute keying material from the 
EMSK using a one-way funciton, the EMSK MUST NOT be used to directly to 
protect data.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 22 Mar 2006 10:03:07 -0600

Bernard Aboba wrote:

> We might consider removing or changing some of the figures.

Right.

> For example, it is not clear to me that Figure 4 adds value, so that
> it can be removed.

Fine by me.

> Figure 3 shows the flow of keying material and parameters within an
> EAP implementation.   Figure 1 already shows the parameters and keying
> material exported by methods, so this figure may not add very much
> that could not be contributed with some text.  For example:
>
> 1. Figure 1 shows the EAP method outputting the Method-ID, while
> Figure 3 shows the lower layer obtaining the Session-ID.  In this case
> the observable behavior is that the lower layer and AAA layer is
> provided with a Session-ID which uniquely identifies the EAP
> conversation.   My suggestion is that we change figure 1 to show the
> EAP method outputting the Session-ID, while indicating that since the
> Session-ID uniquely identifies an EAP conversation, implementations
> should take care to prevent EAP methods from writing into each other's
> Session-ID space.   It is not necessary to get into the implementation
> details of how this accomplished (e.g. only letting the method process
> output the Method-ID, while having the EAP Type code automatically
> concatenated outside the method process space).
>
> material/parameters to the lower layer.  To avoid potential conflicts
> with RFC 4137, my recommendation would be to focus on the externally
> verifiable behavior, which is that the EMSK must be protected from
> compromise.   The EMSK is available only to the EAP peer and server,
> is never transported to a third party.  While the lower layer can
> compute keying material from the EMSK using a one-way funciton, the
> EMSK MUST NOT be used to directly to protect data.

Also fine.

--Jari

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 22 Mar 2006 08:14:45 -0800

>Also fine.

Here are the proposed changes:

Remove figures 3 and 4.

Rewrite Section 2.2 as follows:

2.2  Layering

   On completion of EAP authentication, keying material and
   material and parameters exported by the EAP method are provided
   to the lower layer and AAA layer (if present).  These include the
   Master Session Key (MSK), Extended Master Session Key (EMSK),
   Peer-ID, Server-ID, Session-ID and Key-Lifetime. The Initialization
   Vector (IV) is deprecated.

   In order to preserve the security of keys derived within EAP methods,
   lower layers MUST NOT export keys passed down by EAP methods.  This
   implies that EAP keying material or parameters passed down to a lower
   layer are for the exclusive use of that lower layer and MUST NOT be
   used within another lower layer.  This prevents compromise of one
   lower layer from compromising other applications using EAP keying
   parameters.

   EAP keying material and parameters provided to a lower layer MUST NOT
   be transported to another entity.  For example, EAP keying material
   and parameters passed down to the EAP peer lower layer MUST NOT leave
   the peer;  EAP keying material and parameters passed down or
   transported to the EAP authenticator lower layer MUST NOT leave the
   authenticator.

   On the EAP server, keying material requested by and passed down to
   the AAA layer may be replicated to the AAA layer on the
   authenticator.   On the authenticator, the AAA layer provides the
   replicated keying material to the lower layer over which the EAP
   authentication conversation took place.  This enables "mode
   independence" to be maintained.

   The EMSK MUST NOT be provided to an entity outside the EAP server or
   peer,  nor is it permitted to pass any quantity to an entity outside
   the EAP server or peer from which the EMSK could be computed without
   breaking some cryptographic assumption, such as inverting a one-way
   function.  The EMSK MUST NOT be transported by the AAA layer.
   As noted in [RFC3748] Section 7.10:

      The EMSK is reserved for future use and MUST remain on the EAP
      peer and EAP server where it is derived; it MUST NOT be
      transported to, or shared with, additional parties, or used to
      derive any other keys.

   The EAP layer as well as the peer and authenticator layers MUST NOT
   modify or cache keying material or parameters (including Channel
   Bindings) passing in either direction between the EAP method layer
   and the lower layer or AAA layer.

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 22 Mar 2006 08:40:26 -0800

Also:

Change "Method-ID" to "Session-ID" in Figure 1.

>From: "Bernard Aboba" <[email-masked]>
>To: [email-masked]
>CC: [email-masked]
>Subject: [eap] Re: potential resolution to Issue 317
>Date: Wed, 22 Mar 2006 08:14:45 -0800
>
>>Also fine.
>