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

"Jim Schaad" <ietf@augustcellars.com> Sun, 24 February 2013 21:46 UTC

From: Jim Schaad <ietf@augustcellars.com>
To: 'Sam Hartman' <hartmans-ietf@mit.edu>
References: <tslvc9kaqdn.fsf@mit.edu> <007c01ce1185$1f46a890$5dd3f9b0$@augustcellars.com> <tslfw0l5yn8.fsf@mit.edu>
In-Reply-To: <tslfw0l5yn8.fsf@mit.edu>
Date: Sun, 24 Feb 2013 13:46:27 -0800
Message-ID: <004c01ce12d8$6670d6b0$33528410$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AQMrSgD1lRu1hEo5/aw5Z5fI/5nqzwC+O+68AgjWO8mVuONwEA==
Content-Language: en-us
Cc: emu@ietf.org, draft-ietf-emu-crypto-binding@tools.ietf.org
Subject: Re: [Emu] crypto binding: why did I want a survey of methods
Precedence: list

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


> -----Original Message-----
> From: Sam Hartman [mailto:hartmans-ietf@mit.edu]
> Sent: Sunday, February 24, 2013 10:56 AM
> To: Jim Schaad
> Cc: 'Sam Hartman'; emu@ietf.org; draft-ietf-emu-crypto-
> binding@tools.ietf.org
> 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).
> 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.

[Emu] crypto binding: why did I want a survey of … Sam Hartman
Re: [Emu] crypto binding: why did I want a survey… Jim Schaad
Re: [Emu] crypto binding: why did I want a survey… Sam Hartman
Re: [Emu] crypto binding: why did I want a survey… Jim Schaad