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

[Rifaat Shekh-Yusef <[e-mail]>]

The UA is expected to obtain a valid access token to get service, and
should be able to use that to refresh its registration when the
registration expires.
Is this coupling of expiry times needed?

Regards,
 Rifaat


On Wed, Jul 10, 2019 at 7:56 AM Olle E. Johansson <[e-mail]> wrote:

>
>
> On 10 Jul 2019, at 13:50, Rifaat Shekh-Yusef <[e-mail]>
> wrote:
>
> When the UA authenticates to the AS, it obtains a number of tokens: access
> token and refresh token, and depends on the AS, maybe ID token.
> It is the UAs responsibility to use the refresh token to obtain a new
> access token before the expiry of the existing access token.
>
> Absolutely - my thought was what the server is supposed to do. Reading the
> STUN/Oauth docs, I see a requirement for expiry
> being less than token validity time. In SIP REGISTER/SUBSCRIBE terms, the
> expiry time in SIP should be less
> than the time the token is valid.
>
>  If the token expires, the server needs to reauth or deny services. It is
> important that no services are delivered to an expired authentication.
>
> /O
>
>
> Regards,
>  Rifaat
>
>
> On Wed, Jul 10, 2019 at 2:44 AM Olle E. Johansson <[e-mail]> wrote:
>
>>
>>
>> On 10 Jul 2019, at 02:53, Roman Shpount <[e-mail]> wrote:
>>
>> On Tue, Jul 9, 2019 at 8:30 PM Rifaat Shekh-Yusef <[e-mail]>
>> wrote:
>>
>>> The document clearly allows the use of access token to authenticate
>>> non-REGISTER requests when challenged in the context of the same realm.
>>>
>>> Whether that is needed or not is a different discussion.
>>> Assuming the UA was able to authenticate the user and obtain an access
>>> token, then establish an authenticated TLS channel with the server, and
>>> register the user; is there a need for further challenges from server?
>>>
>>> When the token expires, you certainly need a new token from the user.
>> With SIP Outbound, we’re more connection oriented than before, so we should
>> propably consider what the
>> server does with the connection when a token expires (if it’s not already
>> in the draft).
>> /O
>>
>>
>> Typically, for SIP, user authentication is not tied to the TLS
>> connection. One of the reasons for this is that multiple users can use the
>> same TLS connection in federated systems. This is especially true for
>> Confidential UA, which have trust relationship with a proxy and can
>> maintain a secure connection to the registrar/proxy on behalf of multiple
>> clients.
>>
>> Once again, it would be much easier to discuss if you can provide a use
>> specific case for OAuth with confidential UA. I can easily think of a OAuth
>> use case for Public User Agent, but only have a vague idea what OAuth with
>> Confidential UA would be.
>>
>> The example I can think of, would be some sort of hot desk application,
>> where user allows a Local PBX to register with User Home PBX to accept
>> calls on behalf of user in a remote location. In this case, Local PBX and
>> User Home PBX will be federated systems which will use a single TLS
>> connection for multiple calls or end user devices. Local PBX and User Home
>> PBX will have a trust relationship, possibly with mutual TLS certificate
>> authentications. A company wide directory server will be used to store
>> actual user credentials and will be used to authenticate the user and
>> generate the token.
>>
>> Best Regards,
>> _____________
>> Roman Shpount
>>
>> _______________________________________________
>> sipcore mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sipcore
>>
>>
>> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
>
>
>