Subject: WGLC #349: "strength"

From: Mark Nottingham <[email-masked]>
Date: Thu, 31 May 2012 22:20:36 +1000

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

Proposal: change

>    Both the Authorization field value and the Proxy-Authorization field
>    value consist of credentials containing the authentication
>    information of the client for the realm of the resource being
>    requested.  The user agent MUST choose to use one of the challenges
>    with the strongest auth-scheme it understands and request credentials
>    from the user based upon that challenge.

to

"""
Both the Authorization field value and the Proxy-Authorization field value contain the client's credentials for the realm of the resource being requested, based upon a challenge received from the server (possibly at some point in the past). When creating their values, the user agent ought to do so by selecting the challenge with what it considers to be the most secure auth-scheme that it understands, obtaining credentials from the user as appropriate.
"""

On 27/03/2012, at 11:14 PM, Peter Saint-Andre wrote:

> On 3/23/12 1:27 PM, Alexey Melnikov wrote:
>> On 21/03/2012 23:55, Mark Nottingham wrote:
>>> Now<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/349>.
>>> 
>>> 
>>> On 16/03/2012, at 7:53 PM, Mark Nottingham 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?
>> 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.
> 
> +1
> 
> /psa
> 

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

---

From: Julian Reschke <[email-masked]>
Date: Thu, 31 May 2012 15:35:40 +0200

> Both the Authorization field value and the Proxy-Authorization field value contain the client's credentials for the realm of the resource being requested, based upon a challenge received from the s…

Sounds good to me.

Best regards, Julian

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 31 May 2012 14:59:26 +0100

> Both the Authorization field value and the Proxy-Authorization field value contain the client's credentials for the realm of the resource being requested, based upon a challenge received from the s…

Could be a can of worms so feel free to ignore me, but is
the term credentials there correct? Perhaps authenticator
would be better? If we do manage to get better schemes
defined then someday not all of these would allow derivation
of an underlying password credential.

S

---

From: Julian Reschke <[email-masked]>
Date: Thu, 31 May 2012 16:09:03 +0200

> of an underlying password credential.

It's the term we currently use throughout.

Best regards, Julian

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 31 May 2012 15:16:30 +0100

On 05/31/2012 03:09 PM, Julian Reschke wrote:
>>> value contain the client's credentials for the realm of the resource
>>> being requested, based upon a challenge received from the server
>>> (possibly at some point in the past). When creating their values, the
>>> user agent ought to do so by selecting the challenge with what it
>>> considers to be the most secure auth-scheme that it understands,
>>> obtaining credentials from the user as appropriate.
>>> """
>>

I said feel free to ignore me, not to feel free to give a
non-answer:-)

I can understand that it might take work to change, and
that that might not be worthwhile. But if in fact its not
the right term for some of those uses then it might be
worth changing to avoid future confusion.

Just saying "its that way now" isn't an answer to the
question asked.

Cheers,
S

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 31 May 2012 15:21:20 +0100

Hi Stephen,

> of an underlying password credential.

I don't think the proposed text equates credentials with password 
credentials. I interpreted the text as allowing for Kerberos tickets, 
X.509 certificates, etc.

---

From: "Musatov, Martin - CW" <[email-masked]>
Date: Thu, 31 May 2012 14:41:12 +0000

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Thursday, May 31, 2012 9:17 AM
To: Julian Reschke
Cc: Mark Nottingham; HTTP Working Group
Subject: Re: WGLC #349: "strength"

>>>>     from the user based upon that challenge.
What exactly is the significance of the three lines immediately above? What purpose is the blank line after to and before the two sets of quotes?
>>> (possibly at some point in the past). When creating their values, 
>>> the user agent ought to do so by selecting the challenge with what 
>>> it considers to be the most secure auth-scheme that it understands, 
>> Could be a can of worms so feel free to ignore me, but is the term 
>> credentials there correct? Perhaps authenticator would be better? If 
>> we do manage to get better schemes defined then someday not all of 
>> these would allow derivation of an underlying password credential.
> 

I can understand that it might take work to change, and that that might not be worthwhile. But if in fact its not the right term for some of those uses then it might be worth changing to avoid future confusion.

Just saying "its that way now" isn't an answer to the question asked.

Cheers,
S

---

From: David Morris <[email-masked]>
Date: Thu, 31 May 2012 07:45:01 -0700 (PDT)

> of an underlying password credential.

I think credentials is well understood to mean more than username
password, but what ever means of user identification and 
verification authority verification is understood by all
parties to the processs. 

Dave Morris

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 1 Jun 2012 10:50:17 +1000

On 31/05/2012, at 11:59 PM, Stephen Farrell wrote:
> Could be a can of worms so feel free to ignore me

I suspect it's a bit of one. 

> but is

How about a nice generic "details", as in "obtaining details from the user as appropriate."?

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 1 Jun 2012 10:50:56 +1000

We're using that to explicitly NOT trigger an interpretation of it as a conformance requirement.

Cheers,

On 01/06/2012, at 2:19 AM, James French wrote:

> On Thu, May 31, 2012 at 5:20 AM, Mark Nottingham <[email-masked]> wrote:
> Perhaps this phrase "ought to" should be an all-caps (RFC 2119) SHOULD?