Subject: [Emu] server unauthenticated provisioning mode

From: "Dan Harkins" <[email-masked]>
Date: Tue, 23 Aug 2011 12:04:48 -0700 (PDT)

Hello,

  The tunnel method draft indicates that an anonymous TLS ciphersuite
should only be used in accordance with the server unauthenticated
provisioning mode described in RFC 5422. This is unfortunate because
the technique described in RFC 5422 requires changes to an existing
EAP method, which is unnecessarily confusing, and it is also susceptible
to attack.

  I propose we fix this problem by defining a server unauthenticated
provisioning mode in the draft itself, something similar to the technique
used by TEAM.

  To do this there are a couple places that need to get touched.

  - Section 3.2 says,
     "Other ciphersuites MAY be supported.  It is RECOMMENDED that
      anonymous ciphersuites such as TLS_DH_anon_WITH_AES_128_CBC_SHA only
      be used in the context of the provisioning described in [RFC5422]."

    I suggest it say,
     "Other ciphersuites MAY be supported.  It is REQUIRED that anonymous
      ciphersuites such as TLS_DH_anon_WITH_AES_128_CBC_SHA only be used
      in the context of the provisioning described in <new section>."

  - Adding a new section to describe the technique. I suggest making
    this a new 3.4 and bumping 3.4-7 to 3.5-8. New section should read:

    "3.4 Server Unauthenticated Provisioning Mode

    "In Server Unauthenticated Provisioning Mode, an unauthenticated
     tunnel is established in phase 1 and the peer and server negotiate
     an EAP method in phase 2 that supports mutual authentication and
     key derivation that is resistant to dictionary attack. This
     provisioning mode enables the bootstrapping of peers when the
     peer lacks a strong credential usable for mutual authentication with
     the server during phase 1.

    "Upon successful completion of the EAP method in phase 2, the peer
     and server exchange a Crypto-Binding TLV to bind the inner method
     with the outer method and ensure that a man-in-the-middle attack has
     not been attempted.

    "Support for the Server Unauthenticated Provisioning Mode is
     optional but to ensure interoperability, an implementation that does
     support Server Unauthenticated Provisioning Mode MUST support
     TLS_DH_anon_WITH_AES_128_CBC_SHA as a TLS ciphersuite and MUST
     support EAP-pwd [RFC 5931] as a phase 2 method.

    "Other anonymous ciphersuites MAY be supported. Phase 2 EAP
     methods used in Server Unauthenticated Provisioning Mode MUST
     provide mutual authentication, key generation, and be resistant
     to dictionary attack."

  regards,

  Dan.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 24 Aug 2011 15:15:28 -0400

>>>>> "Dan" == Dan Harkins <[email-masked]> writes:

    Dan> and MUST support EAP-pwd [RFC 5931] as a phase 2 method.

I support all of dan's changes regarding unauthenticated server mode
with the exception of the quoted text above.  I do not generally support
a down-reference to an informational document in a case like this.  (It
would need to be a normative reference in that context).  I don't think
RFc 5931 is an appropriate mandatory-to-implement.  I'm not sure we have
any MTI choices for this other than GPSK.

I'd be happy either with GPSK or leaving the MTI eap method unspecified.

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 24 Aug 2011 13:22:24 -0700 (PDT)

> I'd be happy either with GPSK or leaving the MTI eap method unspecified.

  EAP-GPSK is not resistant to dictionary attack and therefore would
be unqualifed to be used according to the changes I propose that you
already support (i.e. that the EAP method be resistant to dictionary
attack).

  Regarding what it means to be resistant to a dictionary attack, let me
quote some experts in the field [1], "One sees whether or not one has
security against dictionary attacks by looking to see if maximal
adversarial advantage grows primarily with the ratio of interaction to
the size of the password space."

  You will note that with GPSK it does not. Given a password space of X
(all numbers less than 2^128, or the words from Webster's, whatever)
there can be one single interaction followed by computational work to
exhaustively go through the password space seeing if a guess is correct.
The adversarial advantage grows through computation and not interaction.

  Increasing the size of the password space (which is what EAP-GPSK
recommends) may make a successful dictionary attack harder but it does
not magically make a protocol resistant to dictionary attack.

  On the other hand, EAP-pwd is resistant to dictionary attack.

  Normative reference to Informational RFCs is done all the time. What
would we do without RFC 2104!

  regards,

  Dan.

[1] Mihir Bellare, David Pointcheval, and Phillip Rogaway in "Authenticated
Key Exchange Secure Against Dictionary Attack".

---

From: Sam Hartman <[email-masked]>
Date: Wed, 24 Aug 2011 16:33:43 -0400

>> 
    >> 
    >> I support all of dan's changes regarding unauthenticated server
    >> mode with the exception of the quoted text above.  I do not
    >> generally support a down-reference to an informational document
    >> in a case like this.  (It would need to be a normative reference
    >> in that context).  I don't think RFc 5931 is an appropriate
    >> mandatory-to-implement.  I'm not sure we have any MTI choices for
    >> this other than GPSK.
    >> 

  EAP-GPSK is not resistant to dictionary attack and therefore would
    Dan> be unqualifed to be used according to the changes I propose
    Dan> that you already support (i.e. that the EAP method be resistant
    Dan> to dictionary attack).
OK.  Then I think we need to broaden up your text somewhat.  I think
GPSK is fine in a deployment where you expect random keys.  I think
something that has offline dictionary attack resistance would be fine in
  an area where passwords might be used.
I'd like to relax your text to permit both.

    Dan>   Regarding what it means to be resistant to a dictionary
    Dan> attack, let me quote some experts in the field [1], "One sees
    Dan> whether or not one has security against dictionary attacks by
    Dan> looking to see if maximal adversarial advantage grows primarily
    Dan> with the ratio of interaction to the size of the password
    Dan> space."

I think that definition is OK.  I don't want us to require ZKPP to get
the dictionary attack resistance security claim. I agree GPSK should not
have the dictionary attack resistance security claim.

I do want GPSK to be permitted in environments where it is appropriate.

I absolutely do not support EAP-PWD as a MTI for this document unless
EAP-PWD is moved to the standards track.

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 24 Aug 2011 15:49:45 -0700 (PDT)

The distinction between "passwords" and "random keys" is really open
to interpretation using them in email is therefore somewhat problematic.
A "random key" could be 8 uniformly random bits while a "password"
could be drawn from a pool (each having equal likelihood of being chosen)
of 2^16 entries. So let me interpret your email to mean that "passwords"
are easy to guess and "random keys" are not.

>   an area where passwords might be used.

  But areas where passwords "might be used" are more expansive, and I
might add include, the areas where one might have random keys. So something
that has resistance to dictionary attack is "fine" everywhere that any
secret blob credential (i.e. "password" or "random key") is used.

  In fact, if you have the ability to to provision 128-bit (or greater)
blobs in disparate places then you have the ability to provision a
certificate or something that makes EAP-GPSK pointless. If, on the other
hand, you really really want to provision 128-bit blobs in lieu of
certificates then you really have no need to do the tunneled method
with an anonymous DH ciphersuite in phase 1. Just do EAP-GPSK and be done
with it.

> I do want GPSK to be permitted in environments where it is appropriate.

  No one is banning EAP-GPSK. You're free to use it. It just doesn't
seem to make sense relaxing security requirements to provide solutions
to problems that don't really exist.

> EAP-PWD is moved to the standards track.

  So you're drawing a line in the sand over the capricious nature of a
past IESG decision and not on security? Really? Why are you not running
around insisting that RFC 2104 be moved to standards track?

  Dan.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 24 Aug 2011 20:19:44 -0400

>>>>> "Dan" == Dan Harkins <[email-masked]> writes:

    Dan>   In fact, if you have the ability to to provision 128-bit (or
    Dan> greater) blobs in disparate places then you have the ability to
    Dan> provision a certificate or something that makes EAP-GPSK
    Dan> pointless. If, on the other hand, you really really want to
    Dan> provision 128-bit blobs in lieu of certificates then you really
    Dan> have no need to do the tunneled method with an anonymous DH
    Dan> ciphersuite in phase 1. Just do EAP-GPSK and be done with it.

I can think of a lot of reasons I might want a tunnel with EAP-GPSK.
Examples including wanting channel bindings that don't fit in the 200
bytes or whatever GPSK gives me, wanting to do NEA, etc.

So, I think it is reasonable to configure a policy that uses EAP-GPSK
with an anonymous ciphersuite in exactly the  cases where GPSK is
appropriate to use at all.

If you'd like text suggestions I'd be happy to provide.

    >> I absolutely do not support EAP-PWD as a MTI for this document
    >> unless EAP-PWD is moved to the standards track.

    Dan>   So you're drawing a line in the sand over the capricious
    Dan> nature of a past IESG decision and not on security? Really? Why
    Dan> are you not running around insisting that RFC 2104 be moved to
    Dan> standards track?

I don't consider the decision capricious.
EAP-PWD has not met process hurtles that are important for IETF
standards. In particular there are a number of approaches for doing that
sort of password method; we haven't decided that's the one we want to
use.

If EAP-PWD had the sort of deployment MSCHAPv2 had, I'd support an RFC
3967 down-ref to it: the market has spoken and MSCHAPv2 has significant
deployment.  However, a normative down-ref to EAP-PWD would be an
end-run around the question of whether EAP-PWD is the method that does
approximately what it does that we want to recommend.  That decision
should be faced directly not as part of some other spec.

    Dan>   Dan.

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 24 Aug 2011 19:28:16 -0700 (PDT)

On Wed, August 24, 2011 5:19 pm, Sam Hartman wrote:
> standards.

  Thanks, in part, to you.

>            In particular there are a number of approaches for doing that

  That's right "we" haven't decided on One Way To Do It(tm). Nor are
"we" planning to. So you're appealing to wait for the conclusion of a
process that does not exist and has no plans of being started? That's
absurd.

  There are security properties that you said you agreed are important.
I am suggesting to use a method that satisfies those properties for the
purposes of interoperability. Just because you don't like my choice
(and apparently "we" haven't used a non-existent process to choose)
doesn't mean the security properties should be downgraded.

> deployment.

  I refer you to section 4 of RFC 3967, "On the other hand...."

>               However, a normative down-ref to EAP-PWD would be an

  I can assure you that EAP-pwd is "the method that does approximately
what it does". That is tautologically true.

  First you were opposed because it amounted to a normative reference to
an Informational RFC, but that's not a consistent position to take (see
RFC 2104). So now it's that "we" haven't decided on what password method
to use. But "we" have not decided to use MSCHAPv2 or EAP-GPSK to handle
password authentication either. Using either of those is likewise an
"end-run around the question [of] what we want to recommend." But for
some reason you bring these flawed protocols up as alternatives to
EAP-pwd.

  So why are you really opposed to protocols being resistant to
dictionary attack?

  Dan.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 25 Aug 2011 11:35:25 -0400

Dan:

1) My desire to use GPSK with anonymous server authentication is more or
less unrelated to any other part of this discussion.  I want to be able
to do it because I think I might deploy it and I don't want the spec to
forbid a deployment I consider reasonable. There is no security
justification for forbidding GPSK with strong keys combined with
anonymous authentication. Again I'd be happy to provide text.

2) You've convinced me that GPSK is not a good MTI choice because of the
dictionary attack resistance issue.  I didn't carefully consider before
suggesting GPSK as an MTI mechanism.  I do think GPSK should be
permitted to use (point 1) but I agree that's a kind of obscure
deployment.

3) I think MSCHAPv2 is an entirely inappropriate MTI for this
mechanism. I brought that up as an example about how under certain
conditions the fact that something is the kind of thing the IETF
standardizes but is never the less informational should not block a
downward reference. I was attempting to explain my thinking on the
process issue to you, not to suggest MSCHAPv2 for this document.
Apparently I failed to explain my thinking on the process issue.

4) I don't think we have any generally appropriate MTI mechanisms here,
so we should not choose one.  I think it would be fine to say
implementations MAY implement [EAP-PWD] [EAP-EKE] or other methods of
their choice.

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 25 Aug 2011 14:22:03 -0700 (PDT)

Sam,

> anonymous authentication. Again I'd be happy to provide text.

  If you have a scalable way to securely deploy large uniformly random
blobs of bits in multiple disparate locations you have the ability to
deploy a PKCS#12 containing everything you need to use the tunnel
method with nice strong certificate-based authentication.

> permitted to use (point 1) but I agree that's a kind of obscure

  The rare, and obscure, deployment in which it is appropriate to
use EAP-GPSK would also be quite appropriate to use EAP-pwd. But the
converse does not hold. The more common, and unobscure, deployment
that is inappropriate for EAP-GPSK would still be quite appropriate
for EAP-pwd.

  So there's no use case that EAP-GPSK is uniquely appropriate for,
but there are plenty that EAP-pwd is uniquely appropriate for.

> Apparently I failed to explain my thinking on the process issue.

  I completely missed that. Sorry. But if the IETF standardized a
wholly inappropriate protocol like MSCHAPv2 (it doesn't even generate a
shared key) then I really don't understand your opposition to EAP-pwd.
MSCHAPv2 became widespread solely due to Windows. A fait acomplii is
much more of an "end run" than a down-ref to EAP-pwd.

> implementations MAY implement [EAP-PWD] [EAP-EKE] or other methods of

  Like EAP-GPSK? Why stop there? How about EAP-MD5! It's their choice
after all.

  The thing is, EAP-GPSK allows for using short, low entropy, ASCII
strings as the shared secret. You may say that your particular use is
gonna have large uniformly random hexadecimal blobs of bits as the shared
secret but the RFC says the UI must support ASCII and sets no lower limit
on the size of the shared secret. So, effectively, you're insisting that
the tunnel method be susceptible to dictionary attack!

  Maybe my frustration is getting the better of me but RFC 3967 (which
clarifies when standards track documents may refer normatively to
documents at a lower level) says in its security considerations that:

    "inappropriate or excessive use of the process might be considered a
     downgrade attack on the quality of IETF standards or, worse, on the
     rigorous review of security aspects of standards."

and I'd like to know:

  - why it is not inappropriate to insist on the completion of a
    non-existent process before we require the use of any ZKPP; and,

  - why making it possible to launch a dictionary attack against the
    tunnel method is not a downgrade attack on the quality of this IETF
    standard.

  Dan.

---

From: Glen Zorn <[email-masked]>
Date: Fri, 26 Aug 2011 12:32:04 +0700

On 8/26/2011 4:22 AM, Dan Harkins wrote:

> shared key) 

Please check your sources & refrain from spouting nonsense; if EAP-pwd
is really so wonderful you shouldn't need to disparage other work, it
should stand on its own merit.

> then I really don't understand your opposition to EAP-pwd.
> MSCHAPv2 became widespread solely due to Windows. 

Hardly.  The fact that the IETF was busy a) insisting that there was no,
and never would be, any need for dynamic key generation (let alone
mutual authentication) in network access protocols (specifically PPP;
how could there be, since the only appropriate usage of PPP was to
connect two routers which can easily be configured with telnet) and b)
waiting with baited breath for the magical genesis of the universal PKI
(which would happen because IPsec required it & that hamstrung niche
protocol was so wonderful that the world would change to satisfy its
requirements) certainly had a lot to do with it.  MS-CHAPv2 succeeded
because it satisfied a need that the IETF was simultaneously too
ignorant and arrogant to see.

...

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 25 Aug 2011 23:13:05 -0700 (PDT)

> should stand on its own merit.

  I stand corrected. That must be why draft-zorn-emu-team proposed using
MSCHAPv2. Oh wait, it didn't. It proposed using EAP-pwd.

> ignorant and arrogant to see.

  That's great Glen. You accuse me of disparaging other work and then
you go and disparage other work. "Do as I say and not as I do". OK,
I promise.

  Dan.

---

From: Glen Zorn <[email-masked]>
Date: Fri, 26 Aug 2011 13:27:39 +0700

> MSCHAPv2. Oh wait, it didn't. It proposed using EAP-pwd.

& this has a relation to your misrepresentation  how?

> you go and disparage other work. "Do as I say and not as I do". OK,

Actually, Dan, I disparaged the _lack_ of work (in PPP) and the
unrealistic expectations of the "leaders" (in IPsec).  IPsec need not
have been hamstrung by an unrealistic dependency upon PKI and needn't
have been turned into a niche protocol either.

---

From: Glen Zorn <[email-masked]>
Date: Fri, 26 Aug 2011 13:59:34 +0700

On 8/26/2011 1:27 PM, Glen Zorn wrote:

...

> have been turned into a niche protocol either.

& in any case, you can disparage other work (esp. MS-CHAP) all day long;
all I really want is that you do it with some accuracy.

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 26 Aug 2011 08:56:59 -0700 (PDT)

> & this has a relation to your misrepresentation  how?

  It doesn't really, it was a reference to your implication that EAP-pwd
cannot stand on its own merit, and requires the disparagement of other
work to prop it up. Which I think we can both agree is not the case.

  Anyway, yes I misrepresented MSCHAPv2. It does produce a key. I was
wrong.

  But I still think the statement that MSCHAPv2 is inappropriate for
doing server unauthenticated provisioning mode is valid even with a
secret key output by MSCHAPv2. I hope we can both agree on that too.

  Dan.

---

From: Glen Zorn <[email-masked]>
Date: Sat, 27 Aug 2011 12:21:32 +0700

On 8/26/2011 10:56 PM, Dan Harkins wrote:

...

> work to prop it up. Which I think we can both agree is not the case.

Actually, Dan, I implied (or intended to imply) no such thing.  My point
was that making demonstrably false claims about other protocols doesn't
strengthen your case but only weakens it, making it appear that EAP-pwd
cannot stand on its own merits.  MS-CHAPv2 was not specifically _not_
standardized by the IETF, the protocol was documented in a purely
informational document ("This memo provides information for the Internet
community. It does not specify an Internet standard of any kind.").
While the ubiquity of Windows undoubtedly had an influence on its
adoption, the main reason IMHO was that it solved a real problem which
was widely disparaged within the IETF as either nonexistent or
inappropriate (i.e., "if you would just change everything you do the way
we told you to, that problem wouldn't exist").

> secret key output by MSCHAPv2. I hope we can both agree on that too.

I am inclined to think that resistance to attack is a valuable thing in
this case; EAP-pwd is demonstrably less susceptible to a variety of
attacks than MS-CHAPv2 (or for that matter, EAP-GPSK).  Furthermore, I
think that constraining the choice of a MTI type on the basis of a
single academic project (instead of security) is basically unconscionable.