Network Working Group M. Sova Internet-Draft CESNET Intended status: Experimental March 7, 2011 Expires: September 8, 2011 SASL External URI Mechanism draft-sova-sasl-exturi-00 Abstract Simple Authentication and Security Layer (SASL) is a framework for providing authentication to connection-oriented protocols. This memo specifies a SASL mechanism leveraging an existing external authentication infrastructure built for access control for URL- identified resources. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 8, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Sova Expires September 8, 2011 [Page 1] Internet-Draft SASL External URI Mechanism March 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 2. EXTERNAL-URI SASL Mechanism . . . . . . . . . . . . . . . 4 2.1. Access Token Delivery Method . . . . . . . . . . . . . . . 5 2.1.1. Display Delivery Method . . . . . . . . . . . . . . . . . 6 2.1.2. HTTP GET Delivery Method . . . . . . . . . . . . . . . . . 6 2.1.3. Save . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Initial Client Message . . . . . . . . . . . . . . . . . . 6 2.2.1. Display Initial Message . . . . . . . . . . . . . . . . . 6 2.2.2. GET Initial Message . . . . . . . . . . . . . . . . . . . 7 2.2.3. Save Initial Message . . . . . . . . . . . . . . . . . . . 7 2.3. Protected URL Message . . . . . . . . . . . . . . . . . . 8 2.4. Access Token Message . . . . . . . . . . . . . . . . . . . 8 3. Security Considerations . . . . . . . . . . . . . . . . . 9 4. IANA Considerations . . . . . . . . . . . . . . . . . . . 10 5. Normative References . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . 12 Sova Expires September 8, 2011 [Page 2] Internet-Draft SASL External URI Mechanism March 2011 1. Introduction Simple Authentication and Security Layer (SASL) [RFC4422] is a modular framework for providing authentication to connection-oriented protocols. Many communities have deployed web single-sign-on infrastructures to control access to web resources. This memo specifies SASL External URI mechanism that leverages the existing web authentication system for SASL-enabled protocols. The name associated with this mechanism is "EXTERNAL-URI". The EXTERNAL-URI SASL mechanism does not provide a security layer. It is expected to be used with data security protection provided by application layer protocol such as Transport Layer Security. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Sova Expires September 8, 2011 [Page 3] Internet-Draft SASL External URI Mechanism March 2011 2. EXTERNAL-URI SASL Mechanism In short, when using the EXTERNAL-URI SASL mechanism, the SASL client authenticates to the SASL server by proving that the user has access to a specified HTTP URL where the SASL server has stored a random access token. The SASL server challenges the SASL client with a one- time URL access to which is protected by an authentication mechanism external to the SASL-protected protocol. The client is expected to access the URL (usually via an external application such as a web browser) and reply to the SASL server with the access token provided at the URL. The message flow is described in Figure 1 ________ b __________ | | <------------------- | | | HTTP | | SASL | | Server | f | Server | |________| -------------------> |__________| ^ | ^ | ^ | | | | | | | | | | | | | e| g| A| C| I| J| | | | | | | | | | | | | | v | v | v ________ d __________ | | <------------------- | | | HTTP | | SASL | | Client | h | Client | |________| -------------------> |__________| Figure 1: EXTERNAL-URI Authentication Flow A The SASL client sends the initial message to the SASL server. The message informs the HTTP server how the access token should be presented to the HTTP client (the access token delivery method) so that the HTTP client can relay the access token to the SASL client. b The SASL server generates a one-time URL located at the HTTP server and a one-time access token and relays them to the HTTP server together with the access token delivery method. Sova Expires September 8, 2011 [Page 4] Internet-Draft SASL External URI Mechanism March 2011 C The SASL server sends the generated URL to the SASL client. d The SASL client starts the HTTP client to access the URL. e The HTTP client requests the URL from the HTTP server. The HTTP server authenticates the HTTP client using some locally configured authentication method. f In case of successful authentication, the HTTP server relays to the SASL server the identity of the authenticated user. g In case of successful authentication, the HTTP server presents to the HTTP client the access token. The actual form of the access token presentation depends on the token delivery method sent by the SASL client in step A (see Section 2.1). Otherwise, [TBD erro handling]... h The HTTP client relays the access token to the SASL client using the delivery method prescribed by the HTTP server. I The SASL client sends the access token to the SASL server. J The SASL server compares the access token delivered by the SASL client with its stored original value. When they are found identical, the authentication is considered successful. The SASL server sends to the SASL client the authentication result. The actual authentication is delegated to the system controlling access to the URL. Although any authentication mechanism may be chosen, some kind of a web single-sign-on system brings most benefits when combined with SASL EXTERNAL-URI. 2.1. Access Token Delivery Method SASL ETERNAL-URI mechanism requires communication between the HTTP client and the SASL client. The HTTP client has to deliver the access token to the SASL client. This memo defines three mechanism for the delivery: o Display o HTTP GET o Save Sova Expires September 8, 2011 [Page 5] Internet-Draft SASL External URI Mechanism March 2011 2.1.1. Display Delivery Method The display delivery method presents the access token to the user in the browser UI. The user is expected to re-type or copy the access token to the SASL client. 2.1.2. HTTP GET Delivery Method With the HTTP GET delivery method, the SASL client starts a HTTP server at a random port of a local network interface and sends the respective URL as the hint to the SASL server. After successful authentication the HTTP server redirects the HTTP client to the URL constructed by appending the appending the access token value to the URL obtained from the hint. 2.1.3. Save When using the Save delivery method, the hint specifies a specific mime-type registered with a helper application at the user's system. The HTTP server presents the access token as content of an object of the specified mime-type. The browser starts the helper application with the object (a file) containing the access token. The helper application delivers the access token to the SASL client using some IPC method. The actual IPC method is out of scope of this specification. 2.2. Initial Client Message The initial message sent by the SASL client to the SASL server specifies the access token delivery method to be used by the HTTP client to deliver the access token to the SASL client. The message consists of the delivery method identifier and method-specific parameter separated by one space character (ASCII 0x20). 2.2.1. Display Initial Message The identifier for the Display delivery method is DISPLAY. The method-specific parameter is optional. When present, it contains a string intended to be presented to the user together with the access token. The client can for instance use the string to instruct the user to re-type or copy the access token to the SASL client password prompt. Example: DISPLAY Copy the folowing password to the mutt prompt: Sova Expires September 8, 2011 [Page 6] Internet-Draft SASL External URI Mechanism March 2011 2.2.2. GET Initial Message The identifier for the GET delivery method is GET. The mandatory parameter is the HTTP URL to which the HTTP server should redirect the HTTP client after a successful authentication. The host part of the URL MUST be localhost. The URL MUST contain an explicit port at which the SASL client expects the access token. The SASL client MAY include an non-empty path component. After successful authentication, the HTTP server MUST concatenate the URL received as the GET delivery method parameter and the access token and reply to the HTTP client with the HTTP 302 Found response setting the Location header to the result of the concatenation. Example: GET http://localhost:4223/eujMrVZzJn/ Given the access token value is RI5atMwMtNafIa8CXrY8, the HTTP server MUST reply to the successful authentication of the HTTP client with: HTTP/1.1 302 Found Location: http://localhost:4223/eujMrVZzJn/RI5atMwMtNafIa8CXrY8 Connection: close ... 2.2.3. Save Initial Message The identifier for the Save delivery method is SAVE. The mandatory parameter is a string identifier of a mime-type that the SASL client and its helper application recognizes as the access token delivery hint. Example> SAVE application/x-sasl-exturi-token Given the access token value is RI5atMwMtNafIa8CXrY8, the HTTP server MUST reply to the successful authentication of the HTTP client with: HTTP/1.1 200 OK Content-Type: application/x-sasl-exturi-token ... RI5atMwMtNafIa8CXrY8 Sova Expires September 8, 2011 [Page 7] Internet-Draft SASL External URI Mechanism March 2011 2.3. Protected URL Message On receiving the Client Initial Message the SASL server creates a random access token for the session and makes it available via the HTTP server under a random URL. The SASL server MUST inform the HTTP server about the requested access token delivery method to ensure the access token is delivered as requested. The protected URL Message consists of the URL at which the access token is available. The host component of the URL SHOULD be https. Example> https://auth.example.org/secured/MTaHwomHjRo8MnTeC7ZW The MTaHwomHjRo8MnTeC7ZW part of the path component is random and ensures uniqueness of the URL thus binding it to the SASL session. The access to the URL MUST be protected by the HTTP server using the authentication system providing all user information required for authorization decision for the SASL-protected service. As minimum, the HTTP authentication system MUST provide a user identifier suitable for the SASL server. 2.4. Access Token Message On receiving the Protected URL Message, the SASL client starts an external application (the HTTP client) to access the access token at the URL. After a successful authentication to the HTTP server, the HTTP client delivers the access token to the SASL server using the delivery method from Initial Client Message. Then the SASL client sends the Access Token Message to the SASL server. The message consists of the access token. Example: RI5atMwMtNafIa8CXrY8 where the RI5atMwMtNafIa8CXrY8 is the access token obtained from the HTTP client. Sova Expires September 8, 2011 [Page 8] Internet-Draft SASL External URI Mechanism March 2011 3. Security Considerations [TBD] Sova Expires September 8, 2011 [Page 9] Internet-Draft SASL External URI Mechanism March 2011 4. IANA Considerations [TBD] Sova Expires September 8, 2011 [Page 10] Internet-Draft SASL External URI Mechanism March 2011 5. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006. Sova Expires September 8, 2011 [Page 11] Internet-Draft SASL External URI Mechanism March 2011 Author's Address Milan Sova CESNET Zikova 4 Prague 160 00 Czech Republic Email: sova+ietf@cesnet.cz Sova Expires September 8, 2011 [Page 12]