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

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

This does not explain the reason for such a requirement.
Why do you think we need to couple these together for SIP?

Regards,
 Rifaat




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

>
>
> On 10 Jul 2019, at 14:18, Rifaat Shekh-Yusef <[e-mail]>
> wrote:
>
> 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?
>
> Absolutely. If we grant a REGISTER expiry time that is much longer than
> the expiry of the token, we’re in deep waters.
>
> Example from RFC 7635 Stun/Oauth - which I think we can borrow a lot from:
>
> “ o The lifetime provided by the TURN server in the Allocate and
>
>       Refresh responses MUST be less than or equal to the lifetime of
>       the token.  It is RECOMMENDED that the TURN server calculate the
>       maximum allowed lifetime value using the formula:
>
>         lifetime + Delta - abs(RDnew - TS)
>
>       The RECOMMENDED value for the allowed Delta is 5 seconds.
>
> “
>
> Note that they have a “MUST” on this. I think we MUST do the same :-)
> /O
>
>
> 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
>>
>>
>>
>