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

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

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.

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