Subject: Re: [Emu] Issue #7: Password Authentication

From: Alan DeKok <[email-masked]>
Date: Tue, 01 Dec 2009 11:03:28 +0100

Dan Harkins wrote:
>   I guess it depends on what you mean by "expose". If it means a kind
> of flashing-- here's the username and password!-- then no this is not
> sufficient. Such an exposure is certainly a problem but popular ways to
> get around this exposure are not satisfactory. What I'm saying is that
> Jeff Schiller's old maxim of "NO PLAINTEXT PASSWORDS!" is necessary but
> not sufficient. Password-derived data-- "I'll hash in the password and
> a couple of nonces so it's not a plaintext password anymore"-- also poses
> a problem. So to answer your question of whether any modification is
> needed, yes it is.

  OK, but which attacks are we preventing?

  The current text says that the only parties who can see the plain-text
password are EAP peer and server.  i.e. the ones at either end of the
TLS connection.

  Do you think that this is OK, or insecure?

>   Password-based authentication methods are flawed by definition because
> the attacker can always be wildly lucky and guess the password at any
> time-- whether the attack is on-line or off-line. Therefore the definition
> should say _exactly_ what kind of property is desired in a tunneled method
> that employs username and password for authentication.

  OK.

>   What needs to be said is that when using password-based authentication,
> each attack MUST NOT leak more than a single bit of information-- that
> single bit being whether a singular guess is correct or not. I suggest
> using the canonical definition of "dictionary attack" from the
> cryptographic literature:
> 
>      "The advantage any attacker gains against the tunneled method
>       when employing a username and password for authentication MUST
>       be through interaction and not computation".

  The current text doesn't say that, but it is a property of the
authentication method.  We have two attack scenarios:  peer and server.

  As peer, the attacker suggests a password, and the server either ACKs
it or NAKs it.  That is a single bit of data.

  As a server, the attacker must set up a TLS connection to the peer.
Since the attacker is presumed to *not* be able to spoof the
certificates, the peer will never send a password, and the attacker
gains nothing.

  If we presume that the attacker can successfully attack TLS, then we
have issues larger than exposing user passwords.  If the peer does not
properly validate TLS certificates (via user intervention or programmer
error), then yes... the complete password can leak.

  Preventing attacks due to user error is hard.  The only thing we can
safely do here is suggest ways to minimize the attacks.  e.g. The peer
can request authentication for a realm (@example.com), and validate that
the server certificate is "owned" by that realm.  This practice is in
wide-spread use today.

  Alan DeKok.

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 1 Dec 2009 02:44:00 -0800 (PST)

Hi Alan,

>   OK, but which attacks are we preventing?

  Don't think of it as "which attacks are we preventing", we're modeling
the protocol and ascribing a desired property to the modeled protocol.
What is that property? "Not exposed" is not a property.

>   Do you think that this is OK, or insecure?

  If the world only consisted of EAP peers and servers then we would not
have to worry. Sadly, that is not the case. The text says the method
"MUST NOT expose" the username and password. The word "expose" is not
defined and is very vague and open to interpretations that would result
in an insecure protocol. I think there is a property in a properly modeled
protocol that could replace that vague term.

> authentication method.  We have two attack scenarios:  peer and server.

  I know it doesn't say that! I'm proposing that it does!

> it or NAKs it.  That is a single bit of data.

  Yes.

> certificates, the peer will never send a password, and the attacker

  Yes.

> error), then yes... the complete password can leak.

  Let's assume TLS is secure.

> the server certificate is "owned" by that realm.  This practice is in

  What I don't think you seem to realize is that the definition I
proposed works for the 2 situations you came up with. I am offering a
suggestion for a more accurate definition of what we want out of this
protocol. I am not suggesting that TLS is insecure nor am I suggesting
that the 2 apparent candidates for coronation as The New EMU-approved EAP
Tunneling Method have flaws. I am saying that the current requirement is
vague and may not be accurate for some reasonable definitions of "expose".
I suggest a better, and more accurate description of this property. Is
there a problem with my suggestion?

  Dan.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 01 Dec 2009 11:52:00 +0100

Dan Harkins wrote:
> The text says the method

  OK.

> I am saying that the current requirement is

  No.  I just want to be sure I understand what you're getting at.

  Can you propose specific modifications to the text?  i.e. quote the
current text, and then write what you think it should say.

  Alan DeKok.

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 1 Dec 2009 13:33:23 -0800 (PST)

Alan,

  Yes, I can propose a specific modification. In fact, I did already.
It just got truncated from the thread. What I suggest is that in
section 3.1, in the middle of the first paragraph (the text that Joe
was quoting originally), remove this:

    "The tunnel method MUST support transporting the username
     and password to the authentication server. However, it
     MUST NOT expose the username and password to parties in the
     communication path between the peer and the EAP server and
     it MUST provide protection against man-in-the-middle and
     dictionary attacks."

and put this in its stead:

I believe that captures the property we want the tunnel method to
have and is not so vague. It applies to active attacks against the
authenticator, active attacks against the client, passive attacks
between them and between the authenticator and any authentication
server that may exist, and all forms of man-in-the-middle and
dictionary attack that could be launched against the legitimate
participants in this tunnel method.

  Dan.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 02 Dec 2009 11:48:45 +0100

>   Yes, I can propose a specific modification. In fact, I did already.

  It wasn't clear that the text was the suggested replacement.

> have and is not so vague.

  Except it *removes* the requirement that the tunneled method transport
the username and password.  Given the capabilities of widely deployed
systems, I think that this requirement should be kept.

> It applies to active attacks against the

  How about simply adding your text?:

    "The tunnel method MUST support transporting the username
     and password to the authentication server. However, it
     MUST NOT expose the username and password to parties in the
     communication path between the peer and the EAP server and
     it MUST provide protection against man-in-the-middle and
     dictionary attacks.  That is, the advantage any attacker gains
     against the tunneled method when employing a username and password
     for authentication MUST be through interaction and not
     computation".

  I think this addresses your concerns, while simultaneously stating
clearly the specific requirements.

  Alan DeKok.

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 2 Dec 2009 12:08:16 -0800 (PST)

Hi Alan,

  My heartburn over the "MUST tranport the username and password" text
is that it seems to be mandating some particular deployment and not
mandating functionality. The introductory text talks about cases where
the authentication server does not have cleartext access to, or a
consistent transform of, the password. If the authentication server
doesn't have cleartext access or a consistent transform of the password
then what does requiring that the tunnel method transport the username
and password to it solve? This requirement just seems to say that the
tunnel method must be implemented in a way that it can separate the
tunnel establishment stuff from the password authentication stuff and
that is not a functional requirement.

  If the requirement is that the tunnel method MUST support username and
password authentication where the authentication server doesn't have
cleartext access to, or a consistent transform of, the password then why
not just say it directly?

  You have added a "That is," as an introduction to my suggested text
which implies that it's just a restatement of the previous text; it
isn't. The existing text says the tunnel method "MUST NOT expose the
username and password to parties in the communication path between the
peer and the EAP server...." As I said, exposing password-derived data
is a way to comply with this requirement but it is flawed and insecure.
That text also doesn't state anything about protecting the username and
password when it's transporting it to the authentication server (which
come to think of it is quite odd). My text does.

  I think it is better to just state what property we want in a tunnel
method without ambiguity. I think my suggested replacement text is better
than your compromise.

  Dan.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 02 Dec 2009 22:35:19 +0100

Dan Harkins wrote:
> mandating functionality.

  Any authentication system that stores passwords has a limited set of
choices.  They can store clear-text, or versions modified by a
particular cryptographic algorithm (md5, unix crypt, salted, SRP, etc.).
 From the point of view of the client, the only authentication method
which is *known* to be compatible with all possible storage mechanisms
is to send clear-text passwords.

  I would wager that the majority of systems today store passwords in
non-clear-text form.  Unix crypt, Active Directory, etc. are all widely
used examples of this.

  So no, I do not believe that the requirement is mandating a particular
deployment.  I believe it is mandating the lowest-common denominator,
where clients can be sure that they will be authenticated everywhere
that they have credentials stored.

  In any case, Section 4.5 of the draft discusses the reasons for
transport of clear-text passwords in more detail.

> The introductory text talks about cases where
> and password to it solve?

  A huge number of real-world deployment problems.

  If the server has access to the clear-text password, it can implement
the client side for *any* authentication method.  It's not too much of
stretch to believe that a server with access to password transform X can
implement *both* the client and server side.

> not just say it directly?

  Because that's a *reason* for the requirement.  It's not a
requirement.   The reasons are given earlier in the draft (Section 4.5),
and do not need to be repeated here.

> peer and the EAP server...."

  Yes...

> As I said, exposing password-derived data

  We already discussed the security in a previous exchange.  You had
agreed that there were no *new* security problems from using this method.

> come to think of it is quite odd). My text does.

  Section 4.5.1.1 gives that requirement.  There is no need to re-state
it in other places.

> method without ambiguity. I think my suggested replacement text is better

  The draft addresses your other concerns (historical reasons for using
clear-text passwords, requirements on security of clear-text passwords,
etc.).

  I find your suggested text vague, and would prefer to see specific
requirements.  My guess is that if you extend your text to describe the
requirements for clear-text password security, you will be simply
reproducing existing text from elsewhere in the document.

  Alan DeKok.

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 2 Dec 2009 15:09:55 -0800 (PST)

Alan,

  Slicing up my posts and building up a straw man army is very
distracting. You attempted to help by adding my comment to the
problematic text. That didn't help, thanks for the effort though.

  Joe, Katrin, Steve, my comment remains. There is a property we need
in the tunnel method and the requirements at the beginning of 3.1 do
not, in my opinion, adequately describe that property. My text does.

  Dan.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 03 Dec 2009 07:50:18 +0100

> problematic text. That didn't help, thanks for the effort though.

  You brought up specific concerns, and I pointed out that the document
already addresses them.  I asked for clarification on any concerns you
had that *weren't* addressed by the document.  We're back to:

> ... There is a property we need

  I could ask for clarificiation again on what *exactly* do you mean by
"a property", but that's how this "straw man army" got started.

  I think I understand what properties you want to be required.  I think
that you already agreed the properties are satisfied by the requirements
as written.  The main disagreement appears to be simply how best to
phrase those requirements.

  Alan DeKok.

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 3 Dec 2009 00:58:51 -0800 (PST)

You are wrong. But let me just give my best John Major impression
from "Prime Minister's Question Time":

<approach podium>

   I refer the right-honourable gentleman to the answer I gave
   some moments ago.

</approach podium>

---

From: Alan DeKok <[email-masked]>
Date: Thu, 03 Dec 2009 11:53:14 +0100

Dan Harkins wrote:
>   You are wrong.

  Are you opposed to sending clear-text passwords in the tunnel?

  Alan DeKok.

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 3 Dec 2009 09:41:13 -0800 (PST)

<approach podium>

</approach podium>

---

From: Alan DeKok <[email-masked]>
Date: Thu, 03 Dec 2009 20:41:21 +0100

>    I refer the right-honourable gentleman to the answer I gave

  Since there has been no new information, I can only conclude that my
previous summary was correct, and that you have no additional concerns
with the document.

  Alan DeKok.

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 3 Dec 2009 12:02:19 -0800 (PST)

Once again Alan, you are wrong. Your previous summary went off on
tangents, made statements that were irrelevant and inferred things
that I never said. Responding to it would not be productive. I have
made my comments on the draft and stand by them.

  I refer you to my previous statements made on this list for my
concerns with the document which are current and unaddressed.

  Dan.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 03 Dec 2009 21:24:55 +0100

> concerns with the document which are current and unaddressed.

  I asked for clarification, and you claim that my attempts to discuss
those clarifications are "tangents" and "straw men".

  This doesn't make me believe that there are issues with the document.

  I suggest posting a detailed review of the document, explaining why
the current text is inadequate, and which text you suggest as
replacement.  Simply replacing one paragraph out of context is
insufficient.  Your stated concerns with that paragraph are directly
addressed by existing text elsewhere in the document.

  Alan DeKok.

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 3 Dec 2009 13:10:57 -0800 (PST)

> those clarifications are "tangents" and "straw men".

  Because they are, in fact, tangents and straw men. I have no desire
to enter into those discussions.

>   This doesn't make me believe that there are issues with the document.

  So what?

> addressed by existing text elsewhere in the document.

  I already said why the text is inadequate-- once again, I refer you
to the statements I previously made on this list. And I even backed up my
use of the word "vague" to describe the problematic text (which you did
not when you, cutely, turned around and used that same term to describe
my suggested text).

  My concerns are not addressed elsewhere in the document.

  Dan.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 03 Dec 2009 22:20:40 +0100

The document states a clear requirement: the tunneled method MUST be
capable of sending clear-text passwords in the tunnel.

  You agree that the attacks against this requirement are adequately
covered by existing text in the document:

http://www.ietf.org/mail-archive/web/emu/current/msg01327.html

  However, you then suggest your text as a "more accurate" definition of
the requirements.  I have asked for clarification as to why your text is
better, and received (a) repetitions of the same text, and (b)
suggestions to go read your previous messages.

  Your text removes the requirement to send a clear-text password in a
tunnel. I am therefore opposed to it, for reasons I have outlined
earlier.  I understand that you find your text more specific than the
current text in the document.  I do not.

  Alan DeKok.

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 3 Dec 2009 14:25:05 -0800 (PST)

Alan,

  You are misrepresenting my concerns with this draft and (intentionally)
misunderstanding my post.

> capable of sending clear-text passwords in the tunnel.

  A "clear-text" password will have to be sent "in the tunnel" because
otherwise authentication would not be possible! I am not against a
requirement to have an authentication protocol that is capable of
authentication. In fact, I am very much opposed to an authentication
protocol that would be incapable of authenticating. OK? Is this clear
enough?

  My issue is with the text saying "[the tunnel method] MUST NOT expose
the username and password to parties in the communication path between
the peer and the EAP server...." As I have repeatedly stated, that is
vague and a reasonable interpretation of that statement could end up
with an insecure protocol by exposing password-derived data but not
the password.

  I happen to think that this can be reworded to not be vague and in
a way that concisely expresses the desired property we want the tunnel
method to have.

  I later mentioned a side issue ("heartburn") in that requiring the
password to be sent to an authentication server seems to be requiring a
particular implementation and that is not appropriate for a protocol
requirements draft since whether you have an authentication server or
not is a deployment optimization. Now particular implementations may
solve real-world deployment issues and that's great. That's a fine
reason to implement a protocol in such a fashion. It's not a requirement
of the protocol though, it's an implementation optimization.

> http://www.ietf.org/mail-archive/web/emu/current/msg01327.html

  No, that is not what I said. You provided "two attack scenarios"
and all I did was say that my suggested text covered them both. That
was an effort on my part to demonstrate that we were not losing anything
by going with my text.

> suggestions to go read your previous messages.

  Your chronology is a bit off. I suggested my text was more accurate
in my first post of this lamentable thread. You should: (b) go read my
previous message.

  My first email on this topic, to Joe, explains why my text is better.
Apparently you did not read that post very closely before slicing it up
and responding to bits and pieces. That belief in confirmed by your
subsequent statements: like how my suggested text is not in the draft--
no kidding, that's why it's suggested text, or asking what text it is
replacing-- the text you removed from the post you obviously didn't
fully read, that's what.

  So when you ask me why my text is more accurate when you obviously have
failed to fully read a post I made where I explain why it's more accurate
I tell you to go back and read the post. And I am telling you again: go
back and read the post. Here it is:

    http://www.ietf.org/mail-archive/web/emu/current/msg01325.html

> current text in the document.  I do not.

  My text does not remove a requirement to send a clear-text password
in a tunnel! You're opposed to a straw man of your own creation.

  Dan.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 04 Dec 2009 08:36:14 +0100

Dan Harkins wrote:
> otherwise authentication would not be possible!

  There are many authentication protocols which do not require the
sending of a clear-text password.  CHAP, MS-CHAP, EKE, SRP, or your own
proposal.  So I'm a little surprised that you think authentication can
happen only via sending a clear-text password.

  Your suggested text permits the tunneled protocol to support *only*
one of these other methods, and to *not* support sending of a clear-text
password.  For reasons I gave before, we cannot standardize on a
tunneled protocol that fails to support clear-text passwords.

  I welcome text to clarify the security requirements.  But I am opposed
to removing the stated requirement for clear-text passwords.  Everything
else we've discussed is secondary to that point.

  Alan DeKok.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Fri, 4 Dec 2009 08:44:30 -0800

This section is about transporting clear text usernames and passwords
within the tunnel, so password transport requirement needs to stay.  I'm
fine with more accurate text for describing the attacks.  I propose the
following text:

"The tunnel method MUST support transporting clear text username and
password to the authentication server.  It MUST NOT reveal information
about the username and password to parties in the communication path
between the peer and the EAP Server.  The advantage any attacker gains
against the tunneled method when employing a username and password for
authentication MUST be through interaction and not computation. "
 
Cheers,

Joe

> -----Original Message-----
> From: Alan DeKok [mailto:[email-masked]] 
> Sent: Thursday, December 03, 2009 11:36 PM
> To: Dan Harkins
> Cc: Joseph Salowey (jsalowey); [email-masked]
> Subject: Re: [Emu] Issue #7: Password Authentication
> 
> Dan Harkins wrote:
>   There are many authentication protocols which do not 
> require the sending of a clear-text password.  CHAP, MS-CHAP, 
> EKE, SRP, or your own proposal.  So I'm a little surprised 
> that you think authentication can happen only via sending a 
> clear-text password.
> 
>   Your suggested text permits the tunneled protocol to 
> support *only* one of these other methods, and to *not* 
> support sending of a clear-text password.  For reasons I gave 
> before, we cannot standardize on a tunneled protocol that 
> fails to support clear-text passwords.
> 
>   I welcome text to clarify the security requirements.  But I 
> am opposed to removing the stated requirement for clear-text 
> passwords.  Everything else we've discussed is secondary to 
> that point.
> 
>   Alan DeKok.
>

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 4 Dec 2009 09:50:34 -0800 (PST)

Hi Joe,

  An authentication server is an optional optimization. Do you agree
that it should be possible to deploy "the tunnel method" without having
such a thing? If that's the case then why the mention of this thing?
If the section is about transporting clear text usernames and passwords
then why not just say "The tunnel method MUST support clear text
username and password authentication"? Like I said, this whole thing
about transporting stuff to an authentication server sounds, to me
at least, like it's mandating a particular deployment.

  (It's odd, I'm hung up on the words "authentication server", and there
is insistence that that phrase remain to support clear text passwords.
Authentication server...clear text passwords...no I don't see the
connection).

  I should be able to implement "the tunnel method", including support
for clear text passwords!, such that it does not support a stand-alone
authentication server, which is how EAP has traditionally been defined.
It may not be particularly useful for many "real-world deployments" but
it might be very useful for some particular situation. And I don't know
why such a thing should be disallowed if all you really want to say is
that clear text passwords MUST be supported.

  Regarding the 2nd paragraph, "reveal information about" is certainly
better text "expose" and I can live with this. And I appreciate the
inclusion of my text. Thanks.

  regards,

  Dan.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 04 Dec 2009 19:00:07 +0100

> authentication MUST be through interaction and not computation. "

  The first sentence refers to "authentication server", while the second
 uses "EAP server".  I suggest using "EAP server" for both, as it is
used elsewhere in the document, too.

  Alan DeKok.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Fri, 4 Dec 2009 11:56:17 -0800

OK good points.  I can see the problem with the authentication server
wording.  I think EAP server is more correct in this case as it leaves
deployment options open.   Is the text OK if we change Authentication
Server to EAP server in this paragraph?

Joe

> Sent: Friday, December 04, 2009 10:00 AM
> To: Joseph Salowey (jsalowey)
> Cc: Dan Harkins; [email-masked]
> > within the tunnel, so password transport requirement needs 
> to stay.  
> > I'm fine with more accurate text for describing the attacks.  I 
> > propose the following text:
> > 
>   The first sentence refers to "authentication server", while 
> the second  uses "EAP server".  I suggest using "EAP server" 
> for both, as it is used elsewhere in the document, too.
> 
>   Alan DeKok.
>

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 4 Dec 2009 13:11:26 -0800 (PST)

Hi Joe,

  I like your suggestion. Using "EAP server" would satisfy my concern.

  thanks,

  Dan.