ISO/IEC 9798-3 Authentication SASL Mechanism
RFC 3163

 
Document Type RFC - Experimental (August 2001; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html
Stream Legacy state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 3163 (Experimental)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                      R. Zuccherato
Request for Comments: 3163                          Entrust Technologies
Category: Experimental                                        M. Nystrom
                                                            RSA Security
                                                             August 2001

              ISO/IEC 9798-3 Authentication SASL Mechanism

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

IESG Note

   It is the opinion of the Security Area Directors that this document
   defines a mechanism to use a complex system (namely PKI certificates)
   for authentication, but then intentionally discards the key benefits
   (namely integrity on each transmission).  Put another way, it has all
   of the pain of implementing a PKI and none of the benefits.  We
   should not support it in use in Internet protocols.

   The same effect, with the benefits of PKI, can be had by using
   TLS/SSL, an existing already standards track protocol.

Abstract

   This document defines a SASL (Simple Authentication and Security
   Layer) authentication mechanism based on ISO/IEC 9798-3 and FIPS PUB
   196 entity authentication.

Zuccherato & Nystrom          Experimental                      [Page 1]
RFC 3163      ISO/IEC 9798-3 Authentication SASL Mechanism   August 2001

1. Introduction

1.1. Overview

   This document defines a SASL [RFC2222] authentication mechanism based
   on ISO/IEC 9798-3 [ISO3] and FIPS PUB 196 [FIPS] entity
   authentication.

   This mechanism only provides authentication using X.509 certificates
   [X509].  It has no effect on the protocol encodings and does not
   provide integrity or confidentiality services.

   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].

   The key benefit of asymmetric (public key) security, is that the
   secret (private key) only needs to be placed with the entity that is
   being authenticated.  Thus, a private key can be issued to a client,
   which can then be authenticated by ANY server based on a token
   generated by the client and the generally available public key.
   Symmetric authentication mechanisms (password mechanisms such as
   CRAM-MD5 [RFC2195]) require a shared secret, and the need to maintain
   it at both endpoints.  This means that a secret key for the client
   needs to be maintained at every server that may need to authenticate
   the client.

   The service described in this memo provides authentication only.
   There are a number of places where an authentication only service is
   useful, e.g., where confidentiality and integrity are provided by
   lower layers, or where confidentiality or integrity services are
   provided by the application.

1.2. Relationship to TLS

   The functionality defined here can be provided by TLS, and it is
   important to consider why it is useful to have it in both places.
   There are several reasons for this, e.g.:

      -  Simplicity.  This mechanism is simpler than TLS.  If there is
         only a requirement for this functionality (as distinct from all
         of TLS), this simplicity will facilitate deployment.

      -  Layering.  The SASL mechanism to establish authentication works
         cleanly with most protocols.  This mechanism can fit more
         cleanly than TLS for some protocols.

Zuccherato & Nystrom          Experimental                      [Page 2]
RFC 3163      ISO/IEC 9798-3 Authentication SASL Mechanism   August 2001

      -  Proxies.  In some architectures the endpoint of the TLS session
         may not be the application endpoint.  In these situations, this
         mechanism can be used to obtain end-to-end authentication.

      -  Upgrade of authentication.  In some applications it may not be
         clear at the time of TLS session negotiation what type of
         authentication may be required (e.g., anonymous, server,
         client-server).  This mechanism allows the negotiation of an
         anonymous or server authenticated TLS session which can, at a
         later time, be upgraded to provide the desired level of
         authentication.

2.  Description of Mechanism
Show full document text