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

[Paul Kyzivat <[e-mail]>]

On 7/8/19 3:30 PM, Christer Holmberg wrote:
> Hi,
> 
>> * Regarding WWW-Authenticate:
>>
>> I believe it will how be possible for a server to support both Digest and Bearer. I think this means that the client
>> can use either depending on what sort of credentials it or its user happen to know.
>>
>> I think it would be good to mention this. I guess in principle the client could return credentials for both. In that case, I don't
>> know whether both must be valid or if it is sufficient for one to be valid.
>> Perhaps we need to discuss that. (Presumably only credentials for a/the realm that the server supports are to
>> be considered, with those for other realms being ignored.)
> 
> I think that is outside the scope of the draft. There could be multiple variants of multiple challenges.
> 
> And, RFC 3261 already talks generally about multiple challenges. I do think some of the 3261 text could be improved and clarified, but that should be done as a separate task.

While I agree in principle that this is in some sense independent of the 
individual schemes, Bearer is what pushes this from one to two, which is 
when the issue appears. So IMO it makes sense to say something about it 
here. Saying that it *ought* to be in 3261 is fine, but in practice that 
is simply saying that it isn't going to be considered at all.

>> * Regarding non-registration requests (and maybe registration requests too):
>>
>>     The UA MUST NOT insert a token in a non-REGISTER request, unless the
>>     non-REGISTER request has been challenged, or the peer is considered a
>>     trusted entity.
>>
>> What is a trusted entity?
> 
> I asked that to be added, but it can be removed.
> 
>> In any case I think this is too strong. Once a request has been challenged the client knows this target wants the credentials.
>> We certainly don't want to force every subsequent request to the same target to take two round trips, one without credentials
>> and then one with. So the client needs to associate these credentials with this target, for awhile. But that begs the question of
>> how long to retain this association. In the case of Digest, a nonce eventually expires and the old credentials fail and get forgotten
>> and replaced by new ones. I guess the life cycle will be somewhat different for Bearer.
>> This needs some thought and discussion.
> 
>  From a generic perspective I think 3261 should describe how credentials are provided in subsequent requests.

See my comment above on what ought to go in 3261.

> As far as tokens are concerned, I am not sure it's within the scope of this draft to define the lifetime of token credentials, as they are not SIP specific.

I'm not too much concerned with the *lifetime* of the token, since that 
will pretty much take care of itself. (When it exceeds its lifetime it 
will stop working.)

But I suspect there might be security concerns here, and that they may 
be different from those that apply to Digest.

It *may* be that it would be fine to include the token in every request, 
regardless of target - that doing so won't cause any security concerns. 
Conversely, that might not be so.

IIUC, similar tokens are used for single-signon, so perhaps there are 
guidelines that can be repurposed for use here. But I think *something* 
needs to be said or else implementors won't know what to do and the 
result will be interop problems.

> Having said that, I DO agree with you that the current came out too strong - and wrong: my intention was to say that credentials from a REGISTER request are not placed in a non-REGISTER request.
> 
> BUT, if a non-REGISTER requests gets challenged, we should allow the client to include the credentials in subsequent non-REGISTER requests - at least within the same session (in case of session related requests).

ISTM that is also too strong. If I used a token for REGISTER, and then I 
do something else (e.g., SUBSCRIBE) with the same server, then it should 
be fine to use it in other requests directed to the same server. And 
possibly to other servers as well. You seem to be assuming that 
credentials for registration are somehow different from credentials for 
other things. It is up to the servers in question to decide that, not 
this protocol document.

	Thanks,
	Paul