OAuth SASL (OAuth for non-web apps, ep.IMAP)

From IIW

Session Topic: OAuth SASL (OAuth for Non-Web Apps, ep.IMAP)

Wednesday 4F

Convener: Hannes Tschofenig

Notes-taker(s): Roshni Chan

Tags for the session - technology discussed/ideas considered: OAuth, SASL

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

OAuth SASL

Presentation here: http://www.tschofenig.priv.at/oauth/IETF-SASL-Kitten.pptx


Presented work done by the IETF KITTEN WG.

SASL (Simple Authentication and Security Layer - RFC 4422)

  • middleware
  • generic security services (GSS API)
  • SASL and GSSAPI sort of merged, but the mechanisms in the RFC only specify SASL mechanisms.


Typical challenge - authentication mechanisms chosen by some may not be appropriate for some other people, therefore SASL provides a container within which to run an authentication framework. SASL messages need to be dumped in an application layer protocol to be useful - these protocols are called SASL profiles. Email based examples provided in the slides from spec.


High Level SASL Exchange

Client requests authentication exchange. The server initiates a challenge and then initiates the actual exchange with the authentication protocol specified and eventually responds with an outcome. The outcome depends on the SASL mechanism used.


In the IMAP example from the presentation, the keywords used were AUTHENTICATE=OAUTHBEARER where the client uses the AUTHENTICATE keyword to specify what mechanism it wishes to use, and the server can list what mechanisms it supports using the AUTH keyword. The client and server exchange blobs till success or failure.


TLS: The server/client can request TLS. The problem with using TLS is that the security mechanisms are now in the underlying layer and not known to SASL.


Standard OAuth SASL architecture: 

	OAuth Authorization Server (access token obtained here)
		|
		|
		|
	SASL OAuth Client (email client) ----------------- SASL server (Resource Server)
							    IMAP Server


Different from popular OAuth in that the client is not pre-provisioned with any information. Some bootstrapping is required for the server to learn about the client ID and metadata, and the client doesn’t know which Authz server to use.


Actual Client-Resource Server interaction

Two OAuth SASL Mechanisms

  • - bearer tokens RFC 6750
  • - OAuth1.0a RFC 5849


Q. OAuth1.0 has a list of vulnerabilities listed in the appendix as unaddressed flaws, so why are we still using it?

OAuth1.0a is being used to show how we would use this for a signed profile. OAuth2 doesn’t mention signed messages, but supports PoP.


Q. Why not use TLS and then recommend relying on something else later.

A. GSS API requires mutual authentication and TLS is outside the GSS layer.


Discovery

  • - missing in the spec.
  • manual config needed, which isn’t the best user experience.

Possible Options

  • in-band discovery (the IMAP server provides some data to bootstrap with)
  • Webfinger, and then retrieve a JSON based doc to get config parameters
  • Dynamic Client Registration


Implementations of SASL in email clients

  • Google has SASL with OAuth2 (server-side)
  • Amazon Kindle clients, Blackberry clients and the Microsoft Nokia phones use Gmail IMAP


Next steps

  • spec discussion in the KITTEN WG
  • issues like Discovery
  • error messages for revoked/expired tokens
    • use simple error messages and require a second call to check whether token was

revoked/expired (deterministic behavior by client).


Some discussion about the GSS Header.

Tunneling an HTTP-like mechanism to use it within SASL seems like we’re forcing an HTTP convention instead of using a JSON Convention - should be discussed further.

SASL-SAML does discovery by getting the client to talk to the IMAP server to get the IDP from the username. (email address -> IMAP server address. IMAP server -> authz server address)

  • in-band discovery in SASL (by separating out discovery of IMAP server and authz server)
  • authz server ID (URL) + attach a trusted component -- hit discovery endpoint and download config param document.
    • Type OAUTHBEARER + 1 URL -- if for authz server
    • add a trusted pth, fetch the doc with endpoint info
    • OR send the username and the actual discovery doc is a f(username).

Reference: draft-ietf-kitten-sasl-oauth-14

Retrieved from "https://iiw.idcommons.net/index.php?title=OAuth_SASL_(OAuth_for_non-web_apps,_ep.IMAP)&oldid=19640"