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.


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

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.

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

Regards,

Christer