ISO/IEC 9798-3 Authentication SASL Mechanism (RFC3163)
Original Publication Date: 2001-Aug-01
Included in the Prior Art Database: 2019-Feb-13
Internet Society Requests For Comment (RFCs)
R. Zuccherato: AUTHOR [+1]
This document defines a SASL (Simple Authentication and Security Layer) authentication mechanism based on ISO/IEC 9798-3 and FIPS PUB 196 entity authentication. This memo defines an Experimental Protocol for the Internet community.
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 (C) The Internet Society (2001). All Rights Reserved.
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.
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
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 mechanis...