Browse Prior Art Database

ISO/IEC 9798-3 Authentication SASL Mechanism (RFC3163)

IP.com Disclosure Number: IPCOM000005341D
Original Publication Date: 2001-Aug-01
Included in the Prior Art Database: 2001-Aug-23
Document File: 18 page(s) / 33K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

R. Zuccherato: AUTHOR [+2]

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.

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 11% of the total text.

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