Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT)

["Olle E. Johansson" <[e-mail]>]

> On 24 Apr 2020, at 23:51, Christer Holmberg <[e-mail]> wrote:
> 
> Hi,
> 
>>>>>> RFC 3261 seems to be written in a world that assumed that Basic and Digest
>>>>>> are the only defined HTTP authentication schemes, and since it prohibits
>>>>>> Basic, that there would only be one authentication challenge (type)
>>>>>> possible.  This text righly acknowledges that we are opening the field up
>>>>>> and could have cases where multiple authentication schemes are possible;
>>>>>> however, it goes even further and admits the possibility of using them
>>>>>> simultaneously.  It seems like this places an onus on us to give some
>>>>>> indication of the semantics when multiple schemes are used at the same time.
>>>>>> Do the authenticated identities need to match?  Or are we asserting that
>>>>>> both/all identities are consenting to the request in question?  (If we don't
>>>>>> have a concrete use case in mind, perhaps the "or more" is just opening a
>>>>>> box that we don't need to open right now.)
>>>>> 
>>>>> I pushed quite a bit on this area during the development of this draft. As you note we are definitely expanding into an area that wasn't anticipated in RFC3261.
>>>>> The whole topic of how authentication works in the presence of multiple schemes and realms could use some elaboration. The authors of this draft were
>>>>> reluctant to get into those weeds. It isn't clear what the right mechanism is to do that.
>>>>> 
>>>>> I had a (non-sip) use case in mind: a site I visit allows you register directly with the site, resulting in an ability to use Digest credentials. The login page on the
>>>>> site offers that as an option, along with the alternatives of Facebook, Google, and maybe some others. I can see something just like that for SIP. Presumably it
>>>>> would be achieved by challenging with Digest and also with Bearer for Facebook, Google, etc. The UAC then "chooses" by delegating the choice to the user through the UI.
>>>>> 
>>>>> This is also the case where the "whitelist" really resides within the end user's head rather than in the UAC.
>>>>> 
>>>>> It gets harder for devices that might be connecting when there is no end user present. This can happen with a "phone" that attempts to be permanently registered
>>>>> to its sip server so that in can receive incoming calls. If it reboots in the middle of the night there is no user handy to interact in the authentication process. It all
>>>>> has to take place using credentials preconfigured (or cached) in the UAC.
>>>> 
>>>> I think it’s critical - and I’ve also raised the issue before like Paul - that we develop a BCP for the various combinations we have - both two types of digest algorithms and now the OAuth2/OpenID Connect.
>>>> There are huge risks of mis-configured platforms allowing for downgrade attacks, so even if you’ve added stronger authentication, someone will misuse your system because MD5 was still open with simple passwords for some very old SIP phones.
>>> 
>>> I agree that such BCP (or whatever form it would take) would be useful. As I said before, I think it should be done as a separate task.
>> 
>> How much do you think would be SIP-specific in such a document, vs. being
>> applicable to both SIP and HTTP?
> 
>    I don't know - perhaps there would be nothing SIP-specific. 
Food for thought. As mentioned earlier SIP has more proxys, ingress proxys between the authenticating part
and the client. Let’s start and see where it goes.
> 
>>>    Therefore, in the authnz draft the suggestion is to say that the processing is based on "local policy".
>> 
>> I'm happy to leave the choice of which one to use as up to local policy,
>> but would object to giving local policy the ability to use multiple
>> mechanisms in combination without defining the semantics of such
>> combinations.

Based on personal experience, referring to local policy results in “do whatever you want” which in
all likelyhood means opening for problems. We need guidelines here.

>> 
>>> If people want, we can add a note saying that a future specification may provide more detailed procedures and guidance regarding processing multiple schemes.
>> 
>> That seems reasonable, if consistent with the above.
> 
>    I suggest the following:
> 
> OLD:
> 
>   If the UAC receives a 401/407 response with multiple WWW-
>   Authenticate/Proxy-Authenticate header fields, providing challenges
>   using different authentication schemes for the same realm, the UAC
>   provides credentials for one or more of the schemes that it supports,
>   based on local polic
> NEW:
> 
>   If the UAC receives a 401/407 response with multiple WWW-
>   Authenticate/Proxy-Authenticate header fields, providing challenges
>   using different authentication schemes for the same realm, the UAC
>   provides credentials for one of the schemes that it supports,
>   based on local policy.
> 
>   NOTE: At the time of writing this specification, detailed procedures for the cases where a UAC receives multiple 
>   different authentication schemes had not been defined. A future specification might define such procedures.
> 
Until we have a point where we know we can securely handle multiple authentication schemes from the same UAS,
I think we should recommend one policy per realm and/or domain.

That will mean that until we have the BCP we determine method per device - new devices gets the challenge
that they support and we limit the possibilities of downgrade attacks.

/O