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

[Christer Holmberg <[e-mail]>]

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.

I am saying that the procedures should be in one place, and that's RFC 3261. 

And, as 3261 already talks about multiple challenges/credentials, I don't think Bearer is pushing this.

Having said that, we can for sure reference the 3261 procedures in the draft, but I don't think the draft is the place where to describe SIP usage of multiple challenges/credentials.

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

Fair enough, if you know the server is the same.

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

As I said in another reply, if you by default place a REGISTER token in a non-REGISTER request the token may reach the remote peer, which could be a security concern. 

Regards,

Christer