[asterisk-dev] [Code Review] SIP authentication support

[Olle E. Johansson]

11 feb 2013 kl. 23:49 skrev Mark Michelson <mmichelson at digium.com>:

> On 02/11/2013 04:09 PM, Olle E. Johansson wrote:
>> 
>> 11 feb 2013 kl. 22:08 skrev "Mark Michelson" <reviewboard at asterisk.org>:
>> 
>>> This means that Asterisk may send multiple WWW-Authenticate headers out in an authentication challenge and can cope with multiple Authorization headers in requests.
>> Hi!
>> A small clarification:
>> 
>> An endpoint that wants to authenticate a request should only send ONE www-authenticate in one response.
>> 
>> It can receive multiple proxy-authenticate and ONE www-authenticate in a response, and thus needs to send multiple proxyauth and one www auth in a request.
>> 
>> Now, if we have multiple auth methods as a server, like md5 and SHA256 I don't know what to do really... This needs to be investigated.
>> 
>> Cheers
>> /O
>> 
> 
> RFC 2617 mentions the possibility to send multiple WWW-Authenticate headers in an HTTP 401 response. It specifically mentions the case where multiple authentication schemes are offered (see section 4.6).
> 
> Looking through RFC 3261, I can't see anything that explicitly prohibits more than one WWW-Authenticate header being sent. Looking in section 22.3 (which is about proxy to user authentication), it says the following:
> 
> "When resubmitting its request in response to a 401 (Unauthorized) or 407 (Proxy Authentication Required) that contains multiple challenges, a UAC MAY include an Authorization value for each WWW- Authenticate value and a Proxy-Authorization value for each Proxy- Authenticate value for which the UAC wishes to supply a credential. As noted above, multiple credentials in a request SHOULD be differentiated by the "realm" parameter.
> 
> It is possible for multiple challenges associated with the same realm to appear in the same 401 (Unauthorized) or 407 (Proxy Authentication Required). This can occur, for example, when multiple proxies within the same administrative domain, which use a common realm, are reached by a forking request. When it retries a request, a UAC MAY therefore supply multiple credentials in Authorization or Proxy-Authorization header fields with the same "realm" parameter value. The same credentials SHOULD be used for the same realm."
> 
> It mentions an example of multiple proxies being reached by a forking request, but it does not necessarily mean that that is the only reason multiple challenges may be present in a response. And in the previous paragraph, the mention of "for each WWW-Authenticate value" means that there can be more than one present.
> 
> Is there a newer RFC that obsoletes or clarifies what RFC 3261 says here? Or have I misinterpreted things in some way?

Multiple proxy auth are always possible, that's right - even in the same realm. What I questioned was multiple WWW-auth.

I had missed the face that you can have multiple WWW-auth - but only where the authentication schemes are different. As long as you are using only MD5, you only have one . 

There is a corner case where the proxy forks to multiple devices and both answers with a challenge, then you have two challenges in the same dialog if the proxy is transaction stateful. You should only issue ONE challenge (using one auth mech), but you may receive two. I've never seen that happening or seen that in a bug report. Wonder if we can force that scenario?

However, that quote answers my question about migrating to SHA256, even though I think there's a policy issue here - why would you want to offer a bad auth mech when you have a better. How should a client respond? I think there is work to be done here. Let's discuss that at SIPit.

/O

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130213/6ab31506/attachment.htm>