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

[Benjamin Kaduk <[e-mail]>]

On Fri, Apr 24, 2020 at 06:40:14AM +0000, Christer Holmberg 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?

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

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

-Ben