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

[Paul Kyzivat <[e-mail]>]

On 7/10/19 11:53 AM, Christer Holmberg wrote:
> Hi,
> 
>>> OAuth allows you to re-use the token as many times as you want (until it expires) for the same service. So, for SIP, re-using the token in binding refresh REGISTER requests is fine.
>>>
>>> But, you should not re-use a token you got for one "service" (e.g., your registration authentication) with another "service" (e.g., user-to-user authentication for a SIP call). It most likely wouldn't even work.
>>     
>>     Is the token somehow bound to the "registration service"? (Whatever that is.)
>>   
>>     ISTM that the token is bound to the parameters from www-authenticate
>>     were used in the process of obtaining the token. And so presumably the
>>     token should be applicable to any other use that provokes a
>>     www-authenticate with the same values of those parameters.
> 
> Yes.
> 
>>     So, if I use a token in REGISTER, and then I do a SUBSCRIBE and get
>>     challenged the same way I would expect to use the same token for that.
>>     And I might decide to preemptively use the same token in the SUBSCRIBE
>>     if it is being sent to the same target.
> 
> Yes.
> 
>>     Based on analogies to Digest, I would expect that after receiving a
>>     Bearer challenge and fetching a matching token I would then add that
>>     token to a key ring, indexed by some (which?) of the parameters from the
>>     www-authenticate. And then in the future for new requests I would look
>>     on the key ring for keys (credentials/tokens) suitable for use on this
>>     request. (When doing this I might find either Digest or Bearer
>>     credentials, or maybe both.)
>>     
>>     Am I missing something?
>    
> No __
> 
> In the case you describe, you should be able to use the same token.
> 
> All I am saying is that one should not send a token to someone that it has NOT been issued for.

Then you are saying that a token should *never* be included in a request 
to a target for which you have not received a challenge some time in the 
past.

That is a bit extreme, but I guess you can specify that if you think it 
is the right thing to do.

But note that this logic won't always work for Proxy-Authenticate. You 
*might* know that a particular proxy will be visited (if it is mentioned 
on a Route header), but it is pretty common for the request to visit 
proxies unknown (at least in advance) to the UAC.

	Thanks,
	Paul