Subject: [Emu] crypto binding: why did I want a survey of methods

From: Sam Hartman <[email-masked]>
Date: Fri, 22 Feb 2013 18:19:16 -0500

So, the current crypto binding draft has empty sections for a survey of
tunnel methods and a survey of inner methods.

Does anyone have an idea what was going to go in those sections?  I'm
guessing I put those section headers there, but I cannot remember what I
was going to survey for.

If there's something we want to collect about methods I'm happy to do
it.  Otherwise, though, I'd prefer to drop the sections.

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 22 Feb 2013 21:17:48 -0800

Sam,

I made an assumption you were going to do a survey of the existing EAP
methods and  compare them against a set of criteria that the document has
outlined.

As an example:  outer EAP methods should
1) have channel binding, 2) should talk about TLS certificate naming, 3)
setup for mixing key material

Inner EAP methods need to produce MSKs or EMSKs and maybe do other things.

This gives a quick overview for selection by people of which methods you
believe will deal with the problems outlined in this document and which do
not and why.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Sam Hartman
> Sent: Friday, February 22, 2013 3:19 PM
> To: [email-masked]; [email-masked]
> Subject: [Emu] crypto binding: why did I want a survey of methods
> 
> 
tunnel
> methods and a survey of inner methods.
> 
> If there's something we want to collect about methods I'm happy to do it.
> Otherwise, though, I'd prefer to drop the sections.
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu

---

From: Sam Hartman <[email-masked]>
Date: Sun, 24 Feb 2013 13:56:27 -0500

Hi.  I've included a survey of tunnel methods that have made it to RFC
and TEAP.  It's quite possible that people want to cover more tunnel
methods in the summary (LEAP, PEAP, EAP-TTLS v1).
People who want to supply text are welcome to do so.

After looking at it, I don't feel comfortable volunteering to do the
inner method summary.  For the more modern methods the answer tends to
always be "yeah, nothing wrong there."  Now, the method itself may be
weaker than you'd like, but the mutual authentication and key handling
tends not to be of particular note.  At least that seems to be true for
the PAKE methods, for GPSK and for revised AKA.  Note that is an initial
guess, I don't have enough confidence in that statement to go write it
down in the draft, and I'm not convinced it's all that useful.

As you get into older methods, say EAP-SIM and EAP-MSCHAPV2, it gets
more complex. EAP-SIM has some significant challenges with mutual
authentication and I think with key generation. Being able to summary
more than what is in the eap-sim security considerations section would
involve a lot more operational knowledge than I have.

I don't even know where to find documentation for EAP-MSCHAPv2. I'm
strongly suspecting it's got problems, given its age and attachment to
md4 and rc4. However, the mschapv2 PPP extensions got away with a one
sentence security considerations section, so it's definitely not just
summarizing already current security analysis.

So, I don't think what I could do with inner method surveys is going to
be helpful enough to write up.

I'm dropping that section but if text emerges within the WG I'd be happy
to include it.
I think though that we're doing a good enough job with security
considerations sections for post-RFC 3748 EAp inner methods that we
don't need such a summary.

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 24 Feb 2013 13:46:27 -0800

Sam,

I think it would be useful to do a partial survey and just say that it is a
partial survey.  In part I think this would be useful just so that the
points that you feel are important for the CB are highlighted.  I would be
perfectly  willing for such a survey to cover only a couple of the most
recent EAP methods with a statement that it is a partial survey and stating
why.

However I can also understand why you would not want to do this because I
would be afraid that the IESG would want to know why it is not a more
complete survey.

Jim

> From: Sam Hartman [mailto:[email-masked]]
> Sent: Sunday, February 24, 2013 10:56 AM
> To: Jim Schaad
> Cc: 'Sam Hartman'; [email-masked]; draft-ietf-emu-crypto-
> [email-masked]
> Subject: Re: [Emu] crypto binding: why did I want a survey of methods
> 
> Hi.  I've included a survey of tunnel methods that have made it to RFC and
> TEAP.  It's quite possible that people want to cover more tunnel methods
in
> the summary (LEAP, PEAP, EAP-TTLS v1).
> After looking at it, I don't feel comfortable volunteering to do the inner
> method summary.  For the more modern methods the answer tends to
the
> PAKE methods, for GPSK and for revised AKA.  Note that is an initial
guess, I
> don't have enough confidence in that statement to go write it down in the
> draft, and I'm not convinced it's all that useful.
> 
> authentication and I think with key generation. Being able to summary more
> than what is in the eap-sim security considerations section would involve
a
> lot more operational knowledge than I have.
> 
> So, I don't think what I could do with inner method surveys is going to be
> helpful enough to write up.
> 
to
> include it.
> considerations sections for post-RFC 3748 EAp inner methods that we don't
> need such a summary.