SASL OAuth
IETF KITTEN Working Group
Hannes Tschofenig
1
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-

2
mechanisms.xhtml
Each of these mechanisms have different capabilities and
requires.
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
3
High-Level SASL Exchange
C: Request authentication exchange
S: Initial challenge
C: Initial response
<additional challenge/response messages>
S: Outcome of authentication exchange
4
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
5
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 base64encoded blobs until either the authentication
completes, or one side has decided that the
authentication has failed.
6
Architecture
Authorization
Server
Assumption: Client not pre-configured
for use with a specific authorization
server.
Regular
OAuth
Exchange
SASL /
OAuth
Client
Email Client
7
SASL
SASL
Server
IMAP Server
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
+--------+
+---------------+ |
----+
8
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 HMACSHA1 keyed message digest), as described in Section 3.4.2
of [RFC5849].
 OAUTH10A used because no standardized proof-ofpossession mechanism available in OAuth 2.0.
9
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
10
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

11
is included.
The path defaults to "/". o The query string defaults to "".
Implementation?
 Available here: https://github.com/sweetums/SASL-OAuth
12
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!
13
Next Steps
 Specification is discussed in the IETF KITTEN working group
and close to completion.
 Feedback highly appreciated!
14