rfc3163.txt

RFC 的详细文档！

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

2.1. Scope

   The mechanism described in this memo provides either mutual or
   unilateral entity authentication as defined in ISO/IEC 9798-1 [ISO1]
   using an asymmetric (public-key) digital signature mechanism.

2.2. Authentication modes

   This SASL mechanism contains two authentication modes:

      -  Unilateral client authentication: The client digitally signs a
         challenge from the server, thus authenticating itself to the
         server.

      -  Mutual authentication: The client digitally signs a challenge
         from the server and the server digitally signs a challenge from
         the client.  Thus both the client and server authenticate each
         other.

2.3. SASL key

   This mechanism has two SASL keys corresponding to the two different
   modes:

      -  "9798-U-<algorithm>" for unilateral client authentication.

      -  "9798-M-<algorithm>" for mutual authentication.

   Each SASL key may be used with a list of algorithms.  A list of
   supported algorithms is given in Section 4.







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


2.4. Unilateral Client Authentication

   This section gives a brief description of the steps that are
   performed for unilateral client authentication.  The actual data
   structures are described fully in Section 3.

      a) The server generates a random challenge value R_B and sends it
         to the client.

      b) The client generates a random value R_A and creates a token
         TokenAB.  The token contains R_A, the client's certificate and
         also a digital signature created by the client over both R_A
         and R_B.  Optionally, it also contains an identifier for the
         server.

      c) The client sends the token to the server.

      d) The server verifies the token by:

         -  verifying the client's signature in TokenAB (this includes
            full certificate path processing as described in [RFC2459]),

         -  verifying that the random number R_B, sent to the client in
            Step 1, agrees with the random number contained in the
            signed data of TokenAB, and

         -  verifying that the identifier for the server, if present,
            matches the server's distinguishing identifier.

2.5. Mutual Authentication

   This section gives a brief description of the steps that are
   performed for mutual authentication.  The actual data structures are
   described fully in Section 3.

      a) The server generates a random challenge value R_B and sends it
         to the client.

      b) The client generates a random value R_A and creates a token
         TokenAB.  The token contains R_A, the client's certificate and
         also a digital signature created by the client over both R_A
         and R_B.  Optionally, it also contains an identifier for the
         server.

      c) The client sends the token to the server.

      d) The server verifies the token by:




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


         -  verifying the client's signature in TokenAB (this includes
            full certificate path processing as described in [RFC2459]),

         -  verifying that the random number R_B, sent to the client in
            Step 1, agrees with the random number contained in the
            signed data of TokenAB, and

         -  verifying that the identifier for the server, if present,
            matches the server's distinguishing identifier.

      e) The server creates a token TokenBA.  The token contains a third
         random value R_C, the server's certificate and a digital
         signature created by the server over R_A, R_B and R_C.
         Optionally, it also contains an identifier for the client.

      f) The server sends the token to the client.

      g) The client verifies the token by:

         -  verifying the server's signature in TokenBA (this includes
            full certificate path processing as described in [RFC2459]),

         -  verifying that the random number R_B, received by the client
            in Step 1, agrees with the random number contained in the
            signed data of TokenBA,

         -  verifying that the random number R_A, sent to the server in
            Step 2, agrees with the random number contained in the
            signed data of Token BA and

         -  verifying that the identifier for the client, if present,
            matches the client's distinguishing identifier.

3.  Token and Message Definition

   Note -   Protocol data units (PDUs) SHALL be DER-encoded [X690]
            before transmitted.

3.1. The "TokenBA1" PDU

   TokenBA1 is used in both the unilateral client authentication and
   mutual authentication modes and is sent by the server to the client.

   TokenBA1 contains a random value, and, optionally, the servers name
   and certificate information.






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


   TokenBA1 ::= SEQUENCE {
        randomB   RandomNumber,
        entityB   [0] GeneralNames OPTIONAL,
        certPref  [1] SEQUENCE SIZE (1..MAX) OF TrustedAuth OPTIONAL
   }

3.2. The "TokenAB" PDU

   TokenAB is used in the unilateral client authentication and mutual
   authentication modes and is sent by the client to the server.
   TokenAB contains a random number, entity B's name (optionally),
   entity certification information, an (optional) authorization
   identity, and a signature of a DER-encoded value of type TBSDataAB.
   The certA field is used to send the client's X.509 certificate (or a
   URL to it) and a related certificate chain to the server.

   The authID field is to be used when the identity to be used for
   access control is different than the identity contained in the
   certificate of the signer.  If this field is not present, then the
   identity from the client's X.509 certificate shall be used.

   TokenAB ::= SEQUENCE {
        randomA   RandomNumber,
        entityB   [0] GeneralNames OPTIONAL,
        certA     [1] CertData,
        authID    [2] GeneralNames OPTIONAL,
        signature SIGNATURE { TBSDataAB }

   }(CONSTRAINED BY {-- The entityB and authID fields shall be included
     -- in TokenAB if and only if they are also included in TBSDataAB.
     -- The entityB field SHOULD be present in TokenAB whenever the
     -- client believes it knows the identity of the server.--})