Re: [secdir] additional mechanisms on top of the auth framework, was: SECDIR review of draft-ietf-httpbis-p7-auth-24

[Julian Reschke <[e-mail]>]

On 2013-10-31 15:44, Bjoern Hoehrmann wrote:
> * Julian Reschke wrote:
>> On 2013-10-29 20:35, Stephen Kent wrote:
>>> ...
>>> Later on page 6 the text says:
>>>
>>> The HTTP protocol does not restrict applications to this simple
>>> challenge-response framework for access authentication.Additional
>>> mechanisms MAY be used, such as encryption at the transport level or
>>> via message encapsulation, and with additional header fields
>>> specifying authentication information.However, such additional
>>> mechanisms are not defined by this specification.
>>>
>>> Encryption is not, per se, an authentication mechanism. Please revise
>>> this text.
>>> ...
>>
>> OK. Maybe:
>>
>> "HTTP does not restrict applications to this simple challenge-response
>> framework. Additional mechanisms can be used, such as additional header
>> fields carrying authentication information, or encryption on the
>> transport layer in order to provide confidentiality. However, such
>> additional mechanisms are not defined by this specification."
>>
>> ?
>
> I think doing s/encryption/authentication/ instead would be better.
> There is no reason to discuss confidentiality here. Encryption and other
> cryptographic techniques are used in many authentication schemes, like
> with client certificates; that may have been the idea behind the text.

"authentication on the transport layer"?

That wouldn't cover Basic auth (plain text passwords) over https:, which 
I think this paragraph is hinting at...

Best regards, Julian



-- 
<green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany
Amtsgericht Münster: HRB5782