1. SIP OAuth Rifaat Shekh-Yusef IETF 90, SIPCore WG, Toronto, Canada July 21, 2014 1

2. SIP Authorization Framework Define an authorization framework for SIP that is based on the OAuth 2.0 framework. Benefits – Challenges – Single Sign-On – Level of Service – 3rd Party Authorization 2

3. OAuth 2.0 – Authorization Code Grant Browser Web Server Auth Server Resource Server (printing service) (Facebook) (photo sharing) -------------------------------------------------------------------- | | | | | F1 GET/200 OK | | | | | | | | F2 302 Auth Server | | | |<-------------------| | | | F3 GET /authorize?response_type=code&… / 200 OK | | | | | F4 POST [credentials] | | |---------------------------------------->| | | | F5 302 redirect-uri [auth code] | |<----------------------------------------| | | F6 GET [auth code]/200 OK | | | | | | | | F7 POST /token [auth code] | | |------------------->| | | | F8 200 OK [access & refresh tokens] | | |<-------------------| | | | F9 GET /photos [access token]/200 OK | | | | | | | | 3

4. Digest Scheme The SIP OAuth proposal relies on Digest Scheme to authenticate the user. I have proposals (CFRG WG) to define new scheme to replace Digest: – PAKE-based Scheme – Key-Derivation Scheme 4

5. Authorization Code Grant Usage – Reuse of existing authorization server that provides access and refresh tokens to existing services. – Use with systems that deploy the registrar and the proxy on separate servers. 5

6. Authenticate & Obtain an Auth Code User Proxy/Registrar Authorization Agent Server --------------------------------------------------------------------- | | | | F1 REGISTER | | |------------------------------>| | | F2 401 | | |<------------------------------| | | | | | F3 GET /authorize?response_type=code&... | |-------------------------------------------------------------->| | | F4 401 Digest | |<--------------------------------------------------------------| | | | o master-key = HMAC-SHA256(HA1, realm + nonce) | | | | | F5 GET /authorize?response_type=code&... with credentials | |-------------------------------------------------------------->| | | | | o master-key = HMAC-SHA256(HA1, realm + nonce) | | | | | F6 OK [auth code] | |<--------------------------------------------------------------| | | | [OPEN ISSUE] How should the UA be redirected to the Authorization Server? Using a new SIP Parameter? Extend Bearer scheme? New scheme? 6

7. Exchange a Code with Access Token User Proxy/Registrar Authorization Agent Server --------------------------------------------------------------------- | | | | F7 REGISTER [auth code] | | |------------------------------>| | | | F8 POST /token [auth code] | | |------------------------------>| | | | | | F9 200 OK [ access token, | | | refresh token, | | | master-key] | | |<------------------------------| | F10 200 OK | | |<------------------------------| | | | | [OPEN ISSUE] Should the proxy forward the tokens to the UA and expect the UA to provide the access token with subsequent requests and take care of refreshing the token? 7

8. Token Refresh User Proxy Authorization Agent Server --------------------------------------------------------------------- | | | | | F13 POST /token | | | [ grant_type=refresh_token& | | | refresh_token= | | |------------------------------>| | | | | | F14 200 OK [ access token, | | | refresh_token ] | | |<------------------------------| | | | 8

9. Authenticated Requests & Application Servers User Agent Proxy Auth Server App Server -------------------------------------------------------------------- | | | | o pop = HMAC-SHA256(master-key, digest-string*) | | | | | | F13 INVITE VM, pop | | | |------------------->| | | | | | | | o The proxy verifies the pop. | | | | | | | | F14 INVITE access token | | |---------------------------------------->| | | | F15 180 Ringing | | |<----------------------------------------| | F14 180 Ringing | | | |<-------------------| | | | | | | [OPEN ISSUE] Should the proof-of-possession be required for the responses? * digest-string: a hash of Contact, Date, Call-ID, CSeq, To, and From headers of SIP requests, as defined in section 9 of RFC4474 9

10. BACKUP SLIDES 10

11. Resource Owner Password Credentials Grant Usage – Allows existing SIP systems to migrate towards a token-based systems, using the existing authentication mechanism (Digest). 11

12. Authenticate & Obtain Access Token UA Proxy/Registrar -------------------------------------------------------------------- | | | F1 REGISTER | |------------------------------------------------------------->| | | | F2 401 WWW-Authenticate: Digest | |<-------------------------------------------------------------| | | o master-key = HMAC-SHA256(HA1, realm + nonce) | | | | F3 REGISTER with Authorization | |------------------------------------------------------------->| | | | o master-key=HMAC-SHA256(HA1, realm + nonce) | | | F4 200 OK [access token, expires,...] | |<-------------------------------------------------------------| | | [OPEN ISSUE] How should the access and refresh tokens be carried? Should we keep it aligned with RFC6749 and carry it in the body of the 200 OK? Should we use a SIP header instead? 12

13. Authenticated Requests UA Proxy ------------------------------------------------------------------- | | o pop = HMAC-SHA256(master-key, access token + digest-string) | | | | F5 INVITE access token, pop | |------------------------------------------------------------->| | | | o The server verifies the pop| | | | F6 180 Ringing | |<-------------------------------------------------------------| | | 13

14. OAuth 2.0 – Authorization Code Grant Browser Web Authorization Resource Server Server Server (printing service) (photo sharing) -------------------------------------------------------------------- | | | | User visits a printing service site: | GET/OK | | | | | | | User provides the printing service site access to his photos hosted on the photo sharing site, which launches the OAuth process and redirects the browser to the Authorization Server: | 302 Auth Server | | | |<-------------------| | | | | | | Browser loads the authorization page from Authorization Server: | GET [redirect-uri]/OK | | | | | | | | | User provides his credentials to allow the browser to obtain a auth code. The browser get redirected back to the web server. | GET /authorize?response_type=code&… | | |---------------------------------------->| | | |302 redirect-uri [auth code] | |<----------------------------------------| | | | | | 14

15. OAuth 2.0 – Authorization Code Grant Cont’ Browser Web Authorization Resource Server Server Server (printing service) (photo sharing) -------------------------------------------------------------------- | | | | Browser provides auth code to the web server when it fetches the web page. | GET [auth code]/OK | | | | | | | Web server exchanges the auth code for an access and refresh tokens | | POST /token [auth code] | | |------------------->| | | | 200 OK [access & refresh tokens] | | |<-------------------| | | | | | Web server uses the access token to get the user's photos | | GET /photos [access token]/200 OK | | | | | | | | 15