1 / 14

SASL OAuth IETF KITTEN Working Group

SASL OAuth IETF KITTEN Working Group. Hannes Tschofenig. What is SASL?. Simple Authentication and Security Layer (SASL) described in RFC 4422. SASL is an authentication framework. It is a middleware supported in applications.

vangie
Download Presentation

SASL OAuth IETF KITTEN Working Group

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SASL OAuthIETF KITTEN Working Group Hannes Tschofenig

  2. What is SASL? • Simple Authentication and Security Layer (SASL) described in RFC 4422. • SASL is an authentication framework. It is a middleware supported in applications. • The actual authentication mechanisms are described in “mechanisms”. Here is a list of standardized mechanisms: • http://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml • Each of these mechanisms have different capabilities and requires.

  3. SASL, cont. • How SASL messages get transported in application protocols is called "SASL profile". • The SASL profile includes how a protocol can indicate which SASL mechanisms it supports, how to start authentication, and how authentication messages are transmitted across that protocol. • Examples: • SMTP: http://www.ietf.org/rfc/rfc2554.txt • IMAP: http://tools.ietf.org/html/rfc3501

  4. High-Level SASL Exchange C: Request authentication exchange S: Initial challenge C: Initial response <additional challenge/response messages> S: Outcome of authentication exchange

  5. IMAP Example S: * OK IMAP4rev1 Server Ready C: t0 CAPABILITY S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR S: t0 OK Completed C: t1 AUTHENTICATE OAUTHBEARER biwBdXNlcj…..PQEB S: t1 OK SASL authentication succeeded

  6. SASL Exchange • "AUTH" key word indicates a list of mechanisms the server supports. • Client picks one (which is usually based on what it supports and the ones that the server prefers), issues an "AUTHENTICATE mechanism-name“. • Then, the client and server exchange base64-encoded blobs until either the authentication completes, or one side has decided that the authentication has failed.

  7. RegularOAuthExchange Architecture Assumption: Client not pre-configured for use with a specific authorization server. Authorization Server SASL Server SASL / OAuth Client SASL IMAP Server Email Client

  8. Architecture, cont. ----+ +--------+ +---------------+ | | |--(A)-- Authorization Request --->| Resource | | | | | Owner | |Plain | |<-(B)------ Access Grant ---------| | |OAuth | | +---------------+ |2.0 | | | | | Client Credentials & +---------------+ | | |--(C)------ Access Grant -------->| Authorization | | | Client | | Server | | | |<-(D)------ Access Token ---------| | | | | (w/ Optional Refresh Token) +---------------+ | | | ----+ | | | | ----+ | | (Optional discovery) +---------------+ | | |--(1)------- User Name --------->| | | | Client | | | | | |<-(2)------ Authentication -------| | | | | endpoint information | Resource | |OAuth | | | Server | |over | |--(E)------ Access Token -------->| | |SASL/ | | | | |GSS- | |<-(F)---- Protected Resource -----| | |API +--------+ +---------------+ | ----+

  9. Two OAuth SASL Mechanisms • OAUTHBEARER: OAuth 2.0 bearer tokens, as described in [RFC6750]. RFC 6750 uses Transport Layer Security (TLS) to secure the protocol interaction between the client and the resource server. • OAUTH10A: OAuth 1.0a MAC tokens (using the HMAC-SHA1 keyed message digest), as described in Section 3.4.2 of [RFC5849]. • OAUTH10A used because no standardized proof-of-possession mechanism available in OAuth 2.0.

  10. IMAP Example S: * OK IMAP4rev1 Server Ready C: t0 CAPABILITY S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR S: t0 OK Completed C: t1 AUTHENTICATE OAUTHBEARER biwBdXNlcj…..PQEB S: t1 OK SASL authentication succeeded

  11. OAUTH10A • Keyed Message Digest needed and a mechanisms for computing it is described in the document. • The signature base string would be constructed per the OAuth 1.0 specification [RFC5849] with the following things noted: • The method value is defaulted to POST. • The scheme defaults to be "http", and any port number other than 80 is included. • The path defaults to "/". o The query string defaults to "".

  12. Implementation? • Available here: https://github.com/sweetums/SASL-OAuth

  13. Discovery • Current specification does not mandate a specific discovery mechanism. • “naked” email clients would require manual configuration. • Possible options: • In-band discovery (via SASL) • WebFinger • Dynamic Client registration • Will be discussed in next session!

  14. Next Steps • Specification is discussed in the IETF KITTEN working group and close to completion. • Feedback highly appreciated!

More Related