Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-01.txt

From: Paul Kyzivat <[email-masked]>
Date: Mon, 8 Jul 2019 11:58:11 -0400

Inline

On 6/29/19 9:47 AM, Christer Holmberg wrote:
> 
> Hi,
>   
> ...
> 
>>> And a more fleshed out
>>> example that shows who puts up the UI to gather the needed info, what is
>>> included in the prompt, what comes back, and what is done with it then.
>>> Enough to relate it to real world experience.
>>>
>>> (AFAIK most real world experience is with web interfaces. For instance
>>> when hitting restricted web sites that require a login from Google,
>>> Facebook, Discus, etc. IIUC this could be much like that, including the
>>> choice of which of those to use. So a use case like that would be great.
>>
>> I think UI related issues and authentication using 3rd party IdPs are really out of scope of this document.
> 
> I agree.

I agree that there shouldn't be anything normative about UI.
But I think some text or examples showing how the signaling might 
interact with the UI would be helpful, so people can relate the 
mechanism to the real world.

> ...
> 
>>> Again, while it is probably true that SIP authentication is mostly used
>>> with registrars, it is also possible for other servers to require
>>> authentication, for SUBSCRIBE, NOTIFY, or even INVITE. Any server can
>>> send a challenge. So the UA needs to be prepared for this and do the
>>> right thing.
>>>
>>> Doing that right includes caching credentials and providing them
>>> appropriately to avoid unnecessarily prompting the user too often. And
>>> then preemptively sending credentials becomes an optimization to avoid
>>> extra round trips. This of course is very important for REGISTER since
>>> it at times is used very frequently as a keep-alive. But at the same
>>> time one needs to have some security guidance on when it is appropriate
>>> to send preemptively and when not.
>>
>> I will add text around this to indicate that non-REGISTER requests should always include the Access Token in the request.
> 
> I don't think we shall do that.
> 
> I think the token shall only be included in non-REGISTER requests only if such requests are being challenged (or, perhaps also based on local configuration), because otherwise the token may be sent to a non-trusted remote peer.

+1

	Thanks,
	Paul