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

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

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

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

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

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

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

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

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

BACKUP SLIDES 10

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

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

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

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

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