160 likes | 606 Views
SIP OAuth. Rifaat Shekh-Yusef IETF 90, SIPCore WG, Toronto, Canada July 21, 2014. 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.
E N D
SIP OAuth RifaatShekh-Yusef IETF 90, SIPCore WG, Toronto, Canada July 21, 2014
SIP Authorization Framework • Define an authorization framework for SIP that is based on the OAuth 2.0framework. • Benefits • Challenges • Single Sign-On • Level of Service • 3rd Party Authorization
OAuth2.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 | | |<--------------------------------------->| | | | |
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
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.
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?
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?
Token Refresh User Proxy Authorization Agent Server --------------------------------------------------------------------- | | | | | F13 POST /token | | | [ grant_type=refresh_token& | | | refresh_token=<ref_token> | | |------------------------------>| | | | | | F14 200 OK [ access token, | | | refresh_token ] | | |<------------------------------| | | |
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
Resource Owner Password Credentials Grant • Usage • Allows existing SIP systems to migrate towards a token-based systems, using the existing authentication mechanism (Digest).
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?
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 | |<-------------------------------------------------------------| | |
OAuth2.0 – Authorization Code Grant Browser Web Authorization Resource Server ServerServer (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 OAuthprocess 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] | |<----------------------------------------| | | | | |
OAuth2.0 – Authorization Code Grant Cont’ Browser Web Authorization Resource Server ServerServer (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| | |<--------------------------------------->| | | | |