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

[Paul Kyzivat <[e-mail]>]

On 7/10/19 6:52 PM, Rifaat Shekh-Yusef wrote:
> Typically, access token is short lived, and in this case it should be 
> used only to allow the UA to register the user.
> When the time comes to refresh the registration, the UA should use the 
> refresh token, which is long lived as it stays with the UA, to obtain a 
> new access token to update the registration.
> If you tie it to the registration expiry, then the access token might be 
> valid for a long time, which degrades the security of the token.

This puts a different spin on how a key ring of credentials is managed. 
Either the key ring always have the refresh token, or else perhaps it 
should contain both, but they should have different expiry times.

This goes well beyond anything described in 3261, so I think an 
explanation is needed.

	Thanks,
	Paul

> There are better mechanisms for a proper indication of account 
> revocation, like the mechanisms defined by the Security Events WG:
> https://datatracker.ietf.org/wg/secevent/documents/
> 
> Regards,
>   Rifaat
> 
> 
> 
> On Wed, Jul 10, 2019 at 9:17 AM Olle E. Johansson <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
> 
> 
>>     On 10 Jul 2019, at 15:08, Olle E. Johansson <[e-mail]
>>     <mailto:[e-mail]>> wrote:
>>
>>
>>
>>>     On 10 Jul 2019, at 14:30, Rifaat Shekh-Yusef
>>>     <[e-mail] <mailto:[e-mail]>> wrote:
>>>
>>>     This does not explain the reason for such a requirement.
>>>     Why do you think we need to couple these together for SIP?
>>     I don’t want to continue delivering services to clients that are
>>     deleted or blocked in the customer database.
>>     With Oauth, the way to block an account is to remove it or change
>>     authorization in the authentication server (IDP) data base.
>>
>>     The idea with auth tokens and refresh tokens is to be able to
>>     revocate authorization quickly.
>>     Delivering a service beyond revocation is not a good thing in my book.
>>
>>     From the definition of Access Token in section 1.4 in RFC 6749:
>>
>>     "Access tokens are credentials used to access protected resources. An
>>         access token is a string representing an authorization issued to the
>>         client.  The string is usually opaque to the client.  Tokens
>>         represent specific scopes and durations of access, granted by the
>>         resource owner, and enforced by the resource server and authorization
>>         server.
>>     “
>>
>>     "Duration of access" is in my world coupled to SIP
>>     registration/subscription expiry.
>>
> 
>     You have actually implicitly written that expiry time accords to
>     token expiry :
> 
>     "2..3
>     <https://tools.ietf.org/html/draft-ietf-sipcore-sip-token-authnz-02#section-2.3>.
>     Subsequent Registrations
> 
>         All subsequent REGISTER requests from the UA MUST include a valid
>         access token.  The UA MUST obtain a new access token before the
>         access token expiry period to continue to get service from the
>         system.
> 
>     “
> 
>     You just need to add that the server MUST not allow an expiry that
>     is greater than
>     the access token expiry time.
> 
>     /O
> 
> 
>>     Cheers
>>     /O
>>
>>>
>>>     Regards,
>>>      Rifaat
>>>
>>>
>>>
>>>
>>>     On Wed, Jul 10, 2019 at 8:25 AM Olle E. Johansson <[e-mail]
>>>     <mailto:[e-mail]>> wrote:
>>>
>>>
>>>
>>>>         On 10 Jul 2019, at 14:18, Rifaat Shekh-Yusef
>>>>         <[e-mail] <mailto:[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] <mailto:[e-mail]>> wrote:
>>>>
>>>>
>>>>
>>>>>             On 10 Jul 2019, at 13:50, Rifaat Shekh-Yusef
>>>>>             <[e-mail] <mailto:[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] <mailto:[e-mail]>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>>                 On 10 Jul 2019, at 02:53, Roman Shpount
>>>>>>                 <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>>
>>>>>>                 On Tue, Jul 9, 2019 at 8:30 PM Rifaat Shekh-Yusef
>>>>>>                 <[e-mail]
>>>>>>                 <mailto:[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] <mailto:[e-mail]>
>>>>>>                 https://www.ietf.org/mailman/listinfo/sipcore
>>>>>
>>>>>             _______________________________________________
>>>>>             sipcore mailing list
>>>>>             [e-mail] <mailto:[e-mail]>
>>>>>             https://www.ietf.org/mailman/listinfo/sipcore
>>>>
>>>
>>>     _______________________________________________
>>>     sipcore mailing list
>>>     [e-mail] <mailto:[e-mail]>
>>>     https://www.ietf.org/mailman/listinfo/sipcore
>>
> 
> 
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
>