Subject: [Emu] WGLC for draft-ietf-emu-rfc5448bis

From: Joseph Salowey <[email-masked]>
Date: Thu, 8 Nov 2018 10:14:10 +0700

This is the working group last call for the draft revision of "Improved
Extensible Authentication Protocol Method for 3rd Generation Authentication
and Key Agreement (EAP-AKA')" available at
https://datatracker.ietf.org/doc/draft-ietf-emu-rfc5448bis/

Please review the document and send your comments to the list by 2359
UTC on 30 November 2018.

Thanks,

Mohit and Joe

---

From: Jim Schaad <[email-masked]>
Date: Sat, 10 Nov 2018 10:36:42 +0700

Any issues that I have here might have already been raised and discussed.  If so just not that and ignore.

Section 3.4 - I am curious why you did not make the hash function a property of the HKDF function rather than making it a hard coded value.  I would kind of expect that section 3.4 (top) and 3.4.1 would be part of the KDF function and not stand alone values.   I am not sure if I think that the MAC function should also be defined by this as well.  Doing so would allow for an easier jump to SHA3 at a later date if needed.   

Other than that question the document is clear and the EMU parts seem to be correct.  I cannot comment on any of the 3GPP parts.

Jim

---

From: Jari Arkko <[email-masked]>
Date: Wed, 14 Nov 2018 18:47:13 +0100

Thanks for your review, Jim.

> Other than that question the document is clear and the EMU parts seem to be correct.  I cannot comment on any of the 3GPP parts.

Good questions.

I’m not sure I can entirely answer what the thinking was without going through past correspondence; I can’t recall. I’m not sure we were clever enough to do what you suggested back then, this could be just a missed opportunity. But I could be missing some reason why we didn’t do it.

Thinking about it now, tying AT_MAC, AT_CHECKCODE, PRF, *and* KDF all to AT_KDF value would make sense. However, that would seem like a change to a design that was in RFC 5448, and if we change that there will be two questions: (a) can we do it and (b) should we do it? 

It seems like that answer to the first question is that we can, because even if (e.g.) AT_MAC appears before KDF negotiation is completed, if the peer does not want to do the requested KDF/hash functions, it will in any case propose new KDF before running the actual crypto.

The answer to the second question may be trickier. If I’m right above, we could make a change without requiring any new code lines in existing implementations, but it would still be a change. And if we made that kind of change, there’d probably be a wish from 3GPP to review that change as well. And possibly a request to discuss the change, or do further development. This is what makes me hesitate a bit.

But I’ll also observe that a future document that introduces SHA-16384 could certainly define all this anyway; peers that can not do the KDF/hash that is proposed would suggested the older algorithms instead, and crypto would only run once both parties agree on what is negotiated in AT_KDF. I’ll think about this some more, but this seems at the moment preferable to me.

Jari

---

From: Jim Schaad <[email-masked]>
Date: Wed, 14 Nov 2018 12:00:07 -0800

> -----Original Message-----
> From: Jari Arkko <[email-masked]>
> Sent: Wednesday, November 14, 2018 9:47 AM
> To: Jim Schaad <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Emu] WGLC for draft-ietf-emu-rfc5448bis
> 
> > Section 3.4 - I am curious why you did not make the hash function a
> property of the HKDF function rather than making it a hard coded value.  I
> would kind of expect that section 3.4 (top) and 3.4.1 would be part of the
> KDF function and not stand alone values.   I am not sure if I think that the
> MAC function should also be defined by this as well.  Doing so would allow
> for an easier jump to SHA3 at a later date if needed.
> >
> > Other than that question the document is clear and the EMU parts seem to
> be correct.  I cannot comment on any of the 3GPP parts.
> 
> Good questions.
> 
> I’m not sure I can entirely answer what the thinking was without going
> through past correspondence; I can’t recall. I’m not sure we were clever
> enough to do what you suggested back then, this could be just a missed
> opportunity. But I could be missing some reason why we didn’t do it.
> 
> Thinking about it now, tying AT_MAC, AT_CHECKCODE, PRF, *and* KDF all to
> AT_KDF value would make sense. However, that would seem like a change to
> a design that was in RFC 5448, and if we change that there will be two
> questions: (a) can we do it and (b) should we do it?
> 
> It seems like that answer to the first question is that we can, because even if
> (e.g.) AT_MAC appears before KDF negotiation is completed, if the peer does
> not want to do the requested KDF/hash functions, it will in any case propose
> new KDF before running the actual crypto.
> 
> The answer to the second question may be trickier. If I’m right above, we
> could make a change without requiring any new code lines in existing
> implementations, but it would still be a change. And if we made that kind of
> change, there’d probably be a wish from 3GPP to review that change as well.
> And possibly a request to discuss the change, or do further development. This
> is what makes me hesitate a bit.
> 
> But I’ll also observe that a future document that introduces SHA-16384 could
> certainly define all this anyway; peers that can not do the KDF/hash that is
> proposed would suggested the older algorithms instead, and crypto would
> only run once both parties agree on what is negotiated in AT_KDF. I’ll think
> about this some more, but this seems at the moment preferable to me.

Jari,

All of what you said makes complete sense to me.  As I said I was asking for curiosity value and not because I thought this should hold up the document from progressing.

The one change I think you might consider doing is to put a "future version note" into the document with the suggestion that this be considered.  If the reason was just oversight I would hate for the same oversight to be made later and a new EAP method be registered.

Jim

---

From: Jari Arkko <[email-masked]>
Date: Wed, 14 Nov 2018 23:23:56 +0100

> The one change I think you might consider doing is to put a "future version note" into the document with the suggestion that this be considered. 

Good idea. I will write something.

Jari