- From: Peter Saint-Andre <stpeter@stpeter.im>
- Date: Tue, 27 Mar 2012 14:14:36 +0200
- To: Alexey Melnikov <alexey.melnikov@isode.com>
- CC: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
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
Received on Tuesday, 27 March 2012 12:15:11 UTC