Re: WGLC #349: "strength"

On 05/31/2012 01:20 PM, Mark Nottingham wrote:
> <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.
> """

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

> 
> 
> 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/
> 
> 
> 
> 
> 
>

Received on Thursday, 31 May 2012 13:59:55 UTC