Subject: WGLC issue for p7: "strength"

From: Mark Nottingham <[email-masked]>
Date: Fri, 16 Mar 2012 19:53:18 +1100

2.1 Challenge and Response - "The user agent MUST choose to use one of the challenges with the strongest auth-scheme it understands..." What does "strongest" mean here? Should we have an index of auth scheme strength as a registry field? This may seem like nit-picking, but we place a MUST against it.

--
Mark Nottingham   http://www.mnot.net/

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 22 Mar 2012 10:55:10 +1100

Now <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/349>.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 23 Mar 2012 13:27:32 +0100

On 21/03/2012 23:55, Mark Nottingham wrote:
> Now<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/349>.
>
>
>> 2.1 Challenge and Response - "The user agent MUST choose to use one of the challenges with the strongest auth-scheme it understands..." What does "strongest" mean here? Should we have an index of auth scheme strength as a registry field?
Definitely not. The measure of strength a) might change over the time 
(e.g. new vulnerabilities might be discovered) and b) might depend on 
client's capabilities and preferences (e.g. is use of smartcard-related 
authentication methods more secure than entering a password).

In SASL we tried to use SSF (Strength Security Factor) to describe the 
level of protection provided by an encryption mechanism associated with 
an authentication mechanism. (Before you stop me, I know this doesn't 
apply to HTTP as is, but there are some similarities.) SSF is a number 
that roughly correspond to the symmetric cipher key length in bits. So 
guess what, describing "strength" of SASL mechanisms based on just SSF 
doesn't work, because there are other security properties that might be 
considered more important to the client/user, such as support for mutual 
authentication, not being susceptible to passive dictionary attack, etc.
>> This may seem like nit-picking, but we place a MUST against it.
You have a point. I suggest adding an explanatory paragraph showing what 
might be considered the strongest, without being too prescriptive. And 
maybe the use of MUST is not appropriate here.

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 24 Mar 2012 09:55:28 +1100

On 23/03/2012, at 11:27 PM, Alexey Melnikov wrote:

> Definitely not. The measure of strength a) might change over the time (e.g. new vulnerabilities might be discovered) and b) might depend on client's capabilities and preferences (e.g. is use of smartcard-related authentication methods more secure than entering a password).
> 
> In SASL we tried to use SSF (Strength Security Factor) to describe the level of protection provided by an encryption mechanism associated with an authentication mechanism. (Before you stop me, I know this doesn't apply to HTTP as is, but there are some similarities.) SSF is a number that roughly correspond to the symmetric cipher key length in bits. So guess what, describing "strength" of SASL mechanisms based on just SSF doesn't work, because there are other security properties that might be considered more important to the client/user, such as support for mutual authentication, not being susceptible to passive dictionary attack, etc.
> You have a point. I suggest adding an explanatory paragraph showing what might be considered the strongest, without being too prescriptive.

Ack.

> And maybe the use of MUST is not appropriate here.

That's what I was thinking too.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 23 Mar 2012 16:27:40 -0700

> That's what I was thinking too.

Saying nothing works.  "The user agent MUST select one auth-scheme
that it understands..."

Or you remove the MUST altogether, there's nothing saying that a user
agent couldn't just go off and make a cup of tea when it encounters an
WWW-Authenticate.

"The user agent selects one challenge that it can use..."

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 24 Mar 2012 12:51:45 +1300

> "The user agent selects one challenge that it can use..."

Was not the reasoning behind that MUST to prevent mishaps like IE6 
selecting the first presented option even if it was the worst security-wise?

I would think this is a case for the auth scheme specifictions to ouline 
which alternative schemes they are stronger/weaker than, and in what ways.
It does not really matter to HTTP which scheme is selected, only that 
any security resulting is the best available.

AYJ

---

From: Martin Thomson <[email-masked]>
Date: Sat, 24 Mar 2012 16:56:51 -0700

On 23 March 2012 16:51, Amos Jeffries <[email-masked]> wrote:
> Was not the reasoning behind that MUST to prevent mishaps like IE6 selecting
> the first presented option even if it was the worst security-wise?

I don't think that there is much you can do to prevent this other than
to note that some UAs do bad things like this.  The UA should be
acting in the best interests of its users and picking what it thinks
is best.  Putting that statement in the specification with a MUST
would be an interesting (and totally untestable) choice.

As Alexey notes, you can do a few things to describe the security of a
particular scheme, but absolute statements of the sort "this is better
than that" are not wise.

--Martin

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 27 Mar 2012 14:14:36 +0200

On 3/23/12 1:27 PM, Alexey Melnikov wrote:
>>> 2.1 Challenge and Response - "The user agent MUST choose to use one
>>> of the challenges with the strongest auth-scheme it understands..."
>>> What does "strongest" mean here? Should we have an index of auth
>>> scheme strength as a registry field?

+1

/psa