Subject: Re: Last Call: draft-arkko-eap-aka-kdf (Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA')) to Informational RFC

From: Lakshminath Dondeti <[email-masked]>
Date: Sun, 12 Oct 2008 23:32:21 -0700

Sorry for the last minute nature of this email, but I was checking with 
folks active in the standards bodies that use EAP-AKA.

After some conversations and thought, I think that the goal of "limiting 
the effects of compromised access network nodes and keys" (should that 
be clarified?) can be achieved with fewer changes to AKA.  I like that 
we are trying to define a new method.  I guess I can appreciate the move 
to SHA-256 (although are we claiming that HMAC-SHA-1 is a problem?). 
However, it is quite confusing in that the new method AKA's tries to be 
backward compatible and forward compatible (KDF negotiation).

AKA' with old KDF, AT_KDF set to 1, seems to cause quite a bit of 
confusion by raising the issue of how would the backward compatibility 
really work.  Why is the old KDF needed with AKA'?

The channel bindings and the CK' and IK' stuff seems also to be 
confusing.  It was interpreted at least in one context as using key 
derivation to enforce EAP channel bindings (which is really not 
necessary).  As it is, we are talking about method-level channel 
bindings, which then seems to be confusing elsewhere.

I am wondering whether we can fix this all up before going forward with 
approval.

For simplicity, I believe, we should just specify AKA' as a new method 
with no attempt at backward compatibility.  Next, I think we should work 
on channel bindings at EAP level and not at the method level, especially 
given that AKA is used so widely.

thanks,
Lakshminath

On 9/15/2008 7:50 AM, The IESG wrote:
> The IESG has received a request from an individual submitter to consider
> the following document:
> 
> - 'Improved Extensible Authentication Protocol Method for 3rd Generation
> 
>    Authentication and Key Agreement (EAP-AKA') '
>    <draft-arkko-eap-aka-kdf-05.txt> as an Informational RFC
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> [email-masked] mailing lists by 2008-10-13. Exceptionally, 
> comments may be sent to [email-masked] instead. In either case, please 
> retain the beginning of the Subject line to allow automated sorting.
> 
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-arkko-eap-aka-kdf-05.txt
> 
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17483&rfc_flag=0
> 
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
> 
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Jari Arkko <[email-masked]>
Date: Mon, 13 Oct 2008 16:35:48 +0300

Hi Lakshminath,

and thanks for your review.

> After some conversations and thought, I think that the goal of 
> "limiting the effects of compromised access network nodes and keys" 
> (should that be clarified?) can be achieved with fewer changes to AKA. 

Fewer is better, lets talk about this.

> I like that we are trying to define a new method.  I guess I can 
> appreciate the move to SHA-256 (although are we claiming that 
> HMAC-SHA-1 is a problem?).

We are not. It is merely an engineering decision. If we are changing the 
behavior and specification for other reasons, updating the hash 
functions to newer ones is easy at the same time. Updating them at 
another time would be significantly more painful, e.g., possibly 
involving another new EAP Type code, backwards compatibility problems, etc.

> However, it is quite confusing in that the new method AKA's tries to 
> be backward compatible and forward compatible (KDF negotiation).
>

This is a feature of EAP-AKA' that we do not strictly speaking require 
in any of the uses cases that I'm aware of. So if you have some evidence 
that it is causing significant confusion, we could re-consider whether 
it needs to stay in the document.

But let me explain the rationale. We designed EAP-AKA' not just because 
3GPP wanted to use new key derivation functions, but also because 
EAP-AKA had no ability to negotiate key derivation functions to begin 
with. (I predict that we have not seen the last update to the key 
derivation functions.) Once you have this ability, EAP-AKA' is merely a 
superset of EAP-AKA, capable of using EAP-AKA KDF (KDF=1), the new KDF 
(KDF=2), or some future KDF.

Again, choosing to use plain old EAP-AKA is also possible by negotiating 
it at the EAP method level. So you could argue that its superfluous to 
do this. However, if there is confusion I want to understand if its 
because of the ability to use EAP-AKA within EAP-AKA' or because the 
negotiation mechanism itself is confusingly described. If its the 
former, we can reconsider. If its the latter, we need to fix the text. 
Please see -06 that was posted today, as it includes some additional 
explanation of the negotiation mechanism, based on last call input we 
have gotten.

> I am wondering whether we can fix this all up before going forward 
> with approval.
>
> with no attempt at backward compatibility.  Next, I think we should 
> work on channel bindings at EAP level and not at the method level, 
> especially given that AKA is used so widely.
If you think removing KDF=1 helps, we can do that, but its a very small 
part of the specification.

I agree that the IETF should work on EAP channel bindings, but as 
someone who has trying to do that for 5-6 years I do not think we should 
hold our breath. I think we may actually make some progress on that, but 
EAP-AKA' binding model is a very limited one compared to what a 
generalized channel binding mechanism would do. You could even argue 
that its a different concept, see what Pasi said in EMU discussion about 
this: http://www.ietf.org/mail-archive/web/emu/current/msg00929.html

The use of CK' and IK' is central to the entire idea of 3GPP's new 
authentication model for AKA. What I want to ensure is that we have an 
interoperable IETF specification for running AKA in EAP under their new 
system. I did not design AKA or the new system, but I do want to ensure 
that the use of the new system does not break EAP. If we do not deliver 
a spec that is capable of doing this, there is a ready made set of hacks 
that some people want to use instead of a new EAP method. Of course, 
those hacks would destroy interoperability with RFC 4187. I do not want 
that to happen, so perhaps you understand why I want to make the minimal 
change to a method that we can change, and move on.

Jari

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 14 Oct 2008 15:22:08 -0700

Hi Jari,

Thanks for your response.  I am sorry I am still slow to respond.

I agree we are better off standardizing a new method at the IETF.  I 
think we should get rid of the AKA KDF in AKA' so that these are two 
separate methods.  Method-level negotiation is easier IMO.

However, if you are after the idea of having a single EAP method 
implementation in mobiles (just AKA' with support for AKA inside it), 
please let me know.  I would prefer that.  That would require a bit of 
coordination with 3GPP and 3GPP2 folks however.

thanks,
Lakshminath

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 15 Oct 2008 14:21:52 -0700

Hi Jari,

This discussion has prompted me to look at the spec again.  Is there a
need to fall back to the AKA derivation?  It seems that the AAA
providing AKA or AKA' support would know what is supported by the
infrastructure.  Having the fallback to AKA is confusing.  If you chose
the alternate approach of using the same EAP ID then it would be
necessary. 

I have a another comment on the AT_KDF_INPUT field.  Are the contents of
this field dependent upon the value of AT_KDF?  It seems that they
should be, in the future perhaps there would need to be additional
information as input to the KDF.  I think the document should either
make the AT_KDF_INPUT specific to the AKA' KDF by changing it to
AT_NETWORK_NAME or AT_KDF_INPUT attribute should be defined more
generically so it can handle changes in KDF in the future (this would
probably be just to define the attribute as an octet string whose
contents is defined by the AT_KDF and more the network name to a section
defining the input for KDF 2).  

Also, how does the peer know what the value of the network name should
be?  Is this a parameter that needs to be configured on the peer?  It
seems that the protocol should allow for the peer's notion of the
network name to be sent to the server so the server is also informed if
there is a mismatch.  Troubleshooting problems would be easier on the
server side instead of relying on obtaining peer logs or relying upon
inconsistent client behavior.  Actually verifying the name is just a
SHOULD so some peers may fail and others may not.

Joe

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Lakshminath Dondeti
> Sent: Tuesday, October 14, 2008 3:22 PM
> To: Jari Arkko
> Cc: Pasi Eronen; [email-masked]; [email-masked]'
> Subject: Re: Last Call: draft-arkko-eap-aka-kdf 
> (ImprovedExtensible AuthenticationProtocol Method for 3rd 
> Generation Authentication and KeyAgreement (EAP-AKA')) to 
> Informational RFC
> 
> Hi Jari,
> 
> I agree we are better off standardizing a new method at the 
> IETF.  I think we should get rid of the AKA KDF in AKA' so 
> that these are two separate methods.  Method-level 
> negotiation is easier IMO.
> 
> However, if you are after the idea of having a single EAP 
> method implementation in mobiles (just AKA' with support for 
> AKA inside it), please let me know.  I would prefer that.  
> That would require a bit of coordination with 3GPP and 3GPP2 
> folks however.
> 
> thanks,
> Lakshminath
> 
> > We are not. It is merely an engineering decision. If we are 
> changing 
> > the behavior and specification for other reasons, updating the hash 
> >> confusion by raising the issue of how would the backward 
> >> compatibility really work.  Why is the old KDF needed with AKA'?
> > 
> > in any of the uses cases that I'm aware of. So if you have some 
> > evidence that it is causing significant confusion, we could 
> > re-consider whether it needs to stay in the document.
> > 
> > But let me explain the rationale. We designed EAP-AKA' not just 
> > because 3GPP wanted to use new key derivation functions, but also 
> > because EAP-AKA had no ability to negotiate key derivation 
> functions 
> > to begin with. (I predict that we have not seen the last 
> update to the 
> > key derivation functions.) Once you have this ability, EAP-AKA' is 
> > merely a superset of EAP-AKA, capable of using EAP-AKA KDF (KDF=1), 
> > the new KDF (KDF=2), or some future KDF.
> > 
> > Again, choosing to use plain old EAP-AKA is also possible by 
> > negotiating it at the EAP method level. So you could argue that its 
> > superfluous to do this. However, if there is confusion I want to 
> > understand if its because of the ability to use EAP-AKA within 
> > EAP-AKA' or because the negotiation mechanism itself is confusingly 
> > described. If its the former, we can reconsider. If its the 
> latter, we need to fix the text.
> >> For simplicity, I believe, we should just specify AKA' as a new 
> >> method with no attempt at backward compatibility.  Next, I 
> think we 
> >> should work on channel bindings at EAP level and not at the method 
> >> level, especially given that AKA is used so widely.
> > If you think removing KDF=1 helps, we can do that, but its a very 
> > small part of the specification.
> > 
> > someone who has trying to do that for 5-6 years I do not think we 
> > should hold our breath. I think we may actually make some 
> progress on 
> > that, but EAP-AKA' binding model is a very limited one compared to 
> > what a generalized channel binding mechanism would do. You 
> could even 
> > argue that its a different concept, see what Pasi said in EMU 
> > discussion about
> > interoperable IETF specification for running AKA in EAP under their 
> > new system. I did not design AKA or the new system, but I 
> do want to 
> > ensure that the use of the new system does not break EAP. 
> If we do not 
> > deliver a spec that is capable of doing this, there is a ready made 
> > set of hacks that some people want to use instead of a new 
> EAP method. 
> > Of course, those hacks would destroy interoperability with 
> RFC 4187. I 
> > do not want that to happen, so perhaps you understand why I want to 
> > make the minimal change to a method that we can change, and move on.
> > 
> > Jari
> > 
> >

---

From: Jari Arkko <[email-masked]>
Date: Thu, 16 Oct 2008 12:24:22 +0300

Joe,

First, after some discussion with some of the users of this spec from 
3GPP, we have decided that AT_KDF=1 or the AKA fallback mode should be 
removed.

AT_KDF_INPUT field values would indeed be dependent on which KDF is 
used. I will make the second change you suggested to fix this.

On the network name: the client and the network execute the same 
algorithm to determine the network name. It has to be done by both, as 
otherwise we could not compare the two and the key derivation would not 
be very useful. There are obviously several ways in which the comparison 
could be carried out, transporting information in one or the other 
direction or both. The authors have chosen a particular model which is 
simple from a protocol perspective and gives more responsibility for the 
end host to deal with policy decisions upon a mismatch. There are 
different tradeoffs with other models, but I'm not necessarily convinced 
that they would be superior. I do note as well that centralized policy 
and other management tools blur the distinctions a bit. I will, however, 
change the text because the intent was to require that the check be 
always made, but allow a policy driven decision on whether to abort or 
to continue with a warning.

Jari

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 16 Oct 2008 06:39:19 -0700

Hi Jari,

> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Thursday, October 16, 2008 2:24 AM
> To: Joseph Salowey (jsalowey)
> Cc: Pasi Eronen; [email-masked]; [email-masked]
> First, after some discussion with some of the users of this 
> spec from 3GPP, we have decided that AT_KDF=1 or the AKA 
> fallback mode should be removed.
> 
> AT_KDF_INPUT field values would indeed be dependent on which 
> KDF is used. I will make the second change you suggested to fix this.
> 
[Joe] Thanks. 

> On the network name: the client and the network execute the 
> same algorithm to determine the network name. It has to be 
> done by both, as otherwise we could not compare the two and 
> the key derivation would not be very useful. There are 
> obviously several ways in which the comparison could be 
> carried out, transporting information in one or the other 
> direction or both. The authors have chosen a particular model 
> which is simple from a protocol perspective and gives more 
> responsibility for the end host to deal with policy decisions 
> upon a mismatch. There are different tradeoffs with other 
> models, but I'm not necessarily convinced that they would be 
> superior. I do note as well that centralized policy and other 
> management tools blur the distinctions a bit. I will, 
> however, change the text because the intent was to require 
> that the check be always made, but allow a policy driven 
> decision on whether to abort or to continue with a warning.
> 
[Joe]Its not clear to me that the peer will have access to the
information for verification, however it seems that the server side
will.  This would increase the management burden on the peer.  If
centralized management is in place then I guess this is not as much of a
problem. The management protocol can be used to provide the client with
information to determine the network name and inform the server if there
is a mismatch encountered on the client.  It would be good to state some
of these assumptions on the reliance on an external system to handle
this.