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

[Paul Kyzivat <[e-mail]>]

On 4/23/20 3:25 PM, Benjamin Kaduk via Datatracker wrote:

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

	Thanks,
	Paul