1

SIP OAuth

Rifaat Shekh-YusefIETF 90, SIPCore WG, Toronto, Canada

July 21, 2014

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

3

OAuth 2.0 – Authorization Code GrantBrowser 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 | | |<--------------------------------------->| | | | |

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

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.

6

Authenticate & Obtain an Auth CodeUser Proxy/Registrar AuthorizationAgent 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?

7

Exchange a Code with Access Token

User Proxy/Registrar AuthorizationAgent 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?

8

Token RefreshUser Proxy

AuthorizationAgent

Server-------------------------------------------------------------------

-- | | | | | F13 POST /token | | | [ grant_type=refresh_token& | | | refresh_token=<ref_token> | | |------------------------------>| | | | | | F14 200 OK [ access token, | | | refresh_token ] | | |<------------------------------| | | |

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

10

BACKUP SLIDES

11

Resource Owner Password Credentials Grant

• Usage– Allows existing SIP systems to migrate towards a

token-based systems, using the existing authentication mechanism (Digest).

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?

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

14

OAuth 2.0 – Authorization Code GrantBrowser 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] | |<----------------------------------------| | | | | |

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