Network Working Group S. Josefsson
Internet-Draft SJD
Intended status: Standards Track August 5, 2008
Expires: February 6, 2009
SASL Mechanism for External Authentication using Channel Bindings:
EXTERNAL-CHANNEL
draft-josefsson-sasl-external-channel-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 6, 2009.
Abstract
This document describes a way to perform end-user authentication in
the Simple Authentication and Security Layer (SASL) framework which
re-use an external security layer (such as the Transport Layer
Security (TLS) protocol) that may have already completed end-user
authentication. In comparison with the existing EXTERNAL mechanism,
this mechanism offers a way to cryptographically bind the
authentication to the security layer via a channel binding. The
EXTERNAL-CHANNEL mechanism alleviates the a priori assumptions made
by the design of the EXTERNAL mechanism.
See <http://josefsson.org/external-channel/> for more information.
Josefsson Expires February 6, 2009 [Page 1]
Internet-Draft EXTERNAL-CHANNEL August 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Technical Specification . . . . . . . . . . . . . . . . . . . 3
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Making Authorization Decisions . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 10
Josefsson Expires February 6, 2009 [Page 2]
Internet-Draft EXTERNAL-CHANNEL August 2008
1. Introduction
The EXTERNAL mechanism, described in Appendix A of [RFC4422] allows a
client to request the server to use credentials established by means
external to the mechanism to authenticate the client. The external
means may be, for instance, TLS [RFC4346] or IP Security [RFC4301]
services.
The EXTERNAL mechanism requires some a prior agreement between the
client and the server regarding which external channel, and
consequently which external credentials, should be used for
authentication. In practice this has often meant that the EXTERNAL
mechanism is only used when there is tight out of band interaction
between the server administration and client user. This has an
impact of the interoperability of the EXTERNAL mechanism.
The EXTERNAL-CHANNEL mechanism, specified in this document, is
similar to the EXTERNAL mechanism in that it relies on an external
channel to perform the user authentication. However, EXTERNAL-
CHANNEL provides a way for the client to provide an identifier of the
external channel that provides the user credentials. The intention
is that the server need not rely on a priori arrangement to identify
the secure channel that was used, but can automatically find the
intended channel and re-use its credentials for the SASL
authentication.
In the EXTERNAL-CHANNEL mechanism the external channel is identified
using the "Channel binding unique prefix" string as defined in
[RFC5056]. A channel bindings is transferred, so that the server can
verify that the client is a peer of the same secure channel as the
server.
Binding authentication to a specific encrypted session can protect
from certain attacks [MITM]. It can also help to improve performance
by having peers agree to re-use a secure channel rather than to set
up a new.
2. Technical Specification
The name of this mechanism is "EXTERNAL-CHANNEL".
The mechanism does not provide a security layer. It provides similar
functionality by relying on an external channel.
The mechanism is capable of transferring a channel binding and an
authorization identity string. If the authorization identity string
is empty, the client is requesting to act as the identity the server
Josefsson Expires February 6, 2009 [Page 3]
Internet-Draft EXTERNAL-CHANNEL August 2008
has associated with the client's credentials. If the authorization
identity string is non-empty, the client is requesting to act as the
identity represented by the string. The channel binding name cannot
be empty.
The client is expected to send data first in the authentication
exchange. Where the client does not provide an initial response data
in its request to initiate the authentication exchange, the server is
to respond to the request with an empty initial challenge and then
the client is to provide its initial response.
The client sends the initial response containing the channel binding
name, a base64 [RFC4648] encoded channel bindings, and a UTF-8
[RFC3629] encoding of the requested authorization identity string.
The authorization identity is non-empty when the client is requesting
to act as the identity represented by the (non-empty) string. The
authorization identity is empty when the client is requesting to act
as the identity the server associates with the external
authentication credentials.
The syntax of the initial response is specified as a value of the
<extern-initial-resp> production detailed below using the Augmented
Backus-Naur Form (ABNF) [RFC4234] notation.
external-initial-resp = cb-name " " b64-cb-data " " authz-id-string
cb-name = 1*( US-ASCII / "." / "-")
;; Based on RFC 5056: "There is no naming convention for channel
;; bindings: any string composed of US-ASCII alphanumeric
;; characters, period ('.'), and dash ('-') will suffice."
b64-cb-data = *( ALPHA / DIGIT / "+" / "/" / "=" )
;; Base64 encoding of the channel bindings, the format
;; of the decoded data depends on the cb-name.
authz-id-string = *( UTF8-char-no-nul )
UTF8-char-no-nul = UTF8-1-no-nul / UTF8-2 / UTF8-3 / UTF8-4
;; where the UTF8-2, UTF8-3, and UTF8-4 productions are
;; as defined in RFC 3629.
UTF8-1-no-nul = %x01-7F
There are no additional challenges and responses.
Hence, the server is to return the outcome of the authentication
exchange.
Josefsson Expires February 6, 2009 [Page 4]
Internet-Draft EXTERNAL-CHANNEL August 2008
The exchange fails if
- the cb-name denote an (to the server implementation) unknown or
end-point channel binding type,
- the client has not established its credentials via the indicated
external channel,
- the channel bindings data does not match,
- the client's credentials are inadequate,
- the client provided an empty authorization identity string and the
server is unwilling or unable to associate an authorization identity
with the client's credentials,
- the client provided a non-empty authorization identity string that
is invalid per the syntax requirements of the applicable application
protocol specification,
- the client provided a non-empty authorization identity string
representing an identity that the client is not allowed to act as, or
- the server is unwilling or unable to provide service to the client
for any other reason.
Otherwise the exchange is successful. When indicating a successful
outcome, additional data is not provided.
3. Examples
This section provides examples of EXTERNAL-CHANNEL authentication
exchanges. The examples are intended to help the readers understand
the above text. The examples are not definitive. The Application
Configuration Access Protocol (ACAP) [RFC2244] is used in the
examples because ACAP sends the SASL tokens without additional
encoding.
The first example shows use of EXTERNAL-CHANNEL with an empty
authorization identity bound to an external "tls-unique" channel. In
this example, the initial response is not sent in the client's
request to initiate the authentication exchange.
Josefsson Expires February 6, 2009 [Page 5]
Internet-Draft EXTERNAL-CHANNEL August 2008
S: * ACAP (SASL "DIGEST-MD5")
C: a001 STARTTLS
S: a001 OK "Begin TLS negotiation now"
<TLS negotiation, further commands are under TLS layer>
S: * ACAP (SASL "DIGEST-MD5" "EXTERNAL-CHANNEL")
C: a002 AUTHENTICATE "EXTERNAL-CHANNEL"
S: + "tls-unique rvOng1J3oo2oMQBc "
C: + ""
S: a002 OK "Authenticated"
Note how the string ends with a " ", it needs to be present even if
the authorization identity is empty.
The second example shows use of EXTERNAL-CHANNEL with an
authorization identity of "simon" bound to an external "tls-unique"
channel. In this example, the initial response is sent with the
client's request to initiate the authentication exchange. This saves
a round-trip.
S: * ACAP (SASL "DIGEST-MD5")
C: a001 STARTTLS
S: a001 OK "Begin TLS negotiation now"
<TLS negotiation, further commands are under TLS layer>
S: * ACAP (SASL "DIGEST-MD5" "EXTERNAL-CHANNEL")
C: a002 AUTHENTICATE "EXTERNAL-CHANNEL" {31+}
C: tls-unique CI4WoQGSd7FdWPrw simon
S: a002 NO "Cannot assume requested authorization identity"
Note how the server rejects the authentication attempt with an
authorization-related error message. Presumably the client
credentials presented in the TLS session does not give the client
authority to assume the identity of "simon".
4. Making Authorization Decisions
The server may use any mechanism to make authorization decisions.
For illustration, we want to give some ideas on how this may work in
practice. This section is not normative.
Typically the external channel will not use authentication identities
that can be used by the application protocol that uses the SASL
EXTERNAL-CHANNEL mechanism. Thus, a mapping is normally required.
There may be mappings from the external credential to a set of
permitted identifiers, and a "default" identifier can be provided in
the mapping table if the client do not specify a particular
authorization identity.
Josefsson Expires February 6, 2009 [Page 6]
Internet-Draft EXTERNAL-CHANNEL August 2008
For example, when mapping from X.509 credentials used in TLS
connections to simple usernames, a table stored on the server can
contain hex-encoded hashes of client X.509 certificates and a set of
usernames.
aef3a7835277a28da831005c2ae3b919e2076a62 simon jas admin
d2fc512490a15036460b5489401439d6da5407fa joe
The server could extract a successfully authenticated X.509 client
certificate from the TLS stack, hash it and look it up in the mapping
table. Each of the usernames given would be permitted authorization
identities. The first username given may be the default username if
the client does not provide an authorization identity.
When mapping from OpenPGP credentials used in TLS [RFC5081], the
mapping table could consist of verified OpenPGP fingerprints and a
set of permitted usernames, such as the following table.
0424D4EE81A0E3D119C6F835EDA21E94B565716F simon jas admin
A4D94E92B0986AB5EE9DCD755DE249965B0358A2 werner
90A79E2FC6F4AAB5B604974FE15DD857B15C37D1 nikos
When SRP authentication with TLS [RFC5054] is used, the username
provided may be the same as the application username, and no mapping
would be necessary.
5. IANA Considerations
The IANA is request to add to the SASL mechanisms registry the
following entry.
Subject: Registration of SASL mechanism EXTERNAL-CHANNEL
SASL mechanism name (or prefix for the family): EXTERNAL-CHANNEL
Security considerations: See security considerations in RFC XXXX.
Published specification (recommended): RFC XXXX.
Person & email address to contact for further information:
Simon Josefsson <simon@josefsson.org>
Intended usage: COMMON
Owner/Change controller: Simon Josefsson <simon@josefsson.org>
6. Security Considerations
The EXTERNAL-CHANNEL mechanism does not authenticate users itself, it
relies on implementation to perform the authentication as part of the
external channel. Care must be taken to ensure that the client
credential has been authenticated, rather than just blindly accepted
Josefsson Expires February 6, 2009 [Page 7]
Internet-Draft EXTERNAL-CHANNEL August 2008
as part of a leap-of-faith setup.
The security of external channel is critical to the security of this
mechanism. The connection between the authentication and the
external channel is made via a channel binding, thus the security
considerations related to channel bindings are also critical, see
[RFC5056].
We claim that by appropriately using a channel binding an application
can protect itself from the attacks in [MITM]. To guarantee this
property, the derived data is only to be used for the intended
purpose.
7. Acknowledgements
The EXTERNAL-CHANNEL mechanism, and significant amount of text in
this document, is based on the EXTERNAL mechanism in Appendix A of
SASL [RFC4422].
8. References
8.1. Normative References
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and
Security Layer (SASL)", RFC 4422, June 2006.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
Channels", RFC 5056, November 2007.
8.2. Informative References
[RFC2244] Newman, C. and J. Myers, "ACAP -- Application
Configuration Access Protocol", RFC 2244, November 1997.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
Josefsson Expires February 6, 2009 [Page 8]
Internet-Draft EXTERNAL-CHANNEL August 2008
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin,
"Using the Secure Remote Password (SRP) Protocol for TLS
Authentication", RFC 5054, November 2007.
[RFC5081] Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport
Layer Security (TLS) Authentication", RFC 5081,
November 2007.
[MITM] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle
in Tunneled Authentication",
WWW http://www.saunalahti.fi/~asokan/research/mitm.html.
Author's Address
Simon Josefsson
SJD
Email: simon@josefsson.org
Josefsson Expires February 6, 2009 [Page 9]
Internet-Draft EXTERNAL-CHANNEL August 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Josefsson Expires February 6, 2009 [Page 10]