doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc3163.txt b/doc/rfc/rfc3163.txt
new file mode 100644
index 0000000..88f7ba9
--- /dev/null
+++ b/doc/rfc/rfc3163.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+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.--})
+
+   TBSDataAB ::= SEQUENCE {
+        randomA RandomNumber,
+        randomB RandomNumber,
+        entityB [0] GeneralNames OPTIONAL,
+        authID  [1] GeneralNames OPTIONAL
+   }
+
+3.3. The "TokenBA2" PDU
+
+   TokenBA2 is used in the mutual authentication mode and is sent by the
+   server to the client.  TokenBA2 contains a random number, entity A's
+   name (optionally), certification information, and a signature of a
+   DER-encoded value of type TBSDataBA.  The certB field is to be used
+   to send the server's X.509 certificate and a related certificate
+   chain to the client.
+
+
+
+Zuccherato & Nystrom          Experimental                      [Page 6]
+
+RFC 3163      ISO/IEC 9798-3 Authentication SASL Mechanism   August 2001
+
+
+   TokenBA2 ::= SEQUENCE {
+        randomC   RandomNumber,
+        entityA   [0] GeneralNames OPTIONAL,
+        certB     [1] CertData,
+        signature SIGNATURE { TBSDataBA }
+   }(CONSTRAINED BY {-- The entityA field shall be included in TokenBA2
+     -- if and only if it is also included in TBSDataBA.  The entityA
+     -- field SHOULD be present and MUST contain the client's name
+     -- from their X.509 certificate.--})
+
+   TBSDataBA ::= SEQUENCE {
+        randomB RandomNumber,
+        randomA RandomNumber,
+        randomC RandomNumber,
+        entityA GeneralNames OPTIONAL
+   }
+
+3.4. The "TrustedAuth" type
+
+   TrustedAuth ::= CHOICE {
+        authorityName         [0] Name,
+             -- SubjectName from CA certificate
+        issuerNameHash        [1] OCTET STRING,
+             -- SHA-1 hash of Authority's DN
+        issuerKeyHash         [2] OCTET STRING,
+             -- SHA-1 hash of Authority's public key
+        authorityCertificate  [3] Certificate,
+             -- CA certificate
+        pkcs15KeyHash         [4] OCTET STRING
+             -- PKCS #15 key hash
+   }
+
+   The TrustedAuth type can be used by a server in its initial message
+   ("TokenBA1") to indicate to a client preferred certificates/public
+   key pairs to use in the authentication.
+
+   A trusted authority is identified by its name, hash of its name, hash
+   of its public key, its certificate, or PKCS #15 key hash.  If
+   identified by its name, then the authorityName field in TrustedAuth
+   contains the SubjectName of its CA certificate.  If it is identified
+   by the hash of its name then the issuerNameHash field contains the
+   SHA-1 hash of the DER encoding of SubjectName from its CA
+   certificate.  If it is identified by the hash of its public key then
+   the issuerKeyHash field contains the SHA-1 hash of the authority's
+   public key.  The hash shall be calculated over the value (excluding
+   tag and length) of the subject public key field in the issuer's
+   certificate.  If it is identified by its certificate then the
+   authorityCertificate field contains its CA certificate.  If it is
+
+
+
+Zuccherato & Nystrom          Experimental                      [Page 7]
+
+RFC 3163      ISO/IEC 9798-3 Authentication SASL Mechanism   August 2001
+
+
+   identified by the PKCS #15 key hash then the pkcs15KeyHash field
+   contains the hash of the CA's public key as defined in PKCS #15
+   [PKCS15] Section 6.1.4.
+
+3.5. The "CertData" type
+
+   The certification data is a choice between a set of certificates and
+   a certificate URL.
+
+   The certificate set alternative is as in [RFC2630], meaning it is
+   intended that the set be sufficient to contain chains from a
+   recognized "root" or "top-level certification authority" to all of
+   the sender certificates with which the set is associated.  However,
+   there may be more certificates than necessary, or there may be fewer
+   than necessary.
+
+   Note -   The precise meaning of a "chain" is outside the scope of
+            this document.  Some applications may impose upper limits on
+            the length of a chain; others may enforce certain
+            relationships between the subjects and issuers of
+            certificates within a chain.
+
+   When the certURL type is used to specify the location at which the
+   user's certificate can be found, it MUST be a non-relative URL, and
+   MUST follow the URL syntax and encoding rules specified in [RFC1738].
+   The URL must include both a scheme (e.g., "http" or "ldap") and a
+   scheme-specific part.  The scheme-specific part must include a fully
+   qualified domain name or IP address as the host.
+
+   CertData ::= CHOICE {
+        certificateSet     SET SIZE (1..MAX) OF Certificate,
+        certURL            IA5String,
+        ... -- For future extensions
+   }
+
+3.6. The "RandomNumber" type
+
+   A random number is simply defined as an octet string, at least 8
+   bytes long.
+
+   RandomNumber ::= OCTET STRING (SIZE(8..MAX))
+
+3.7. The "SIGNATURE" type
+
+   This is similar to the "SIGNED" parameterized type defined in
+   [RFC2459], the difference being that the "SIGNATURE" type does not
+   include the data to be signed.
+
+
+
+
+Zuccherato & Nystrom          Experimental                      [Page 8]
+
+RFC 3163      ISO/IEC 9798-3 Authentication SASL Mechanism   August 2001
+
+
+   SIGNATURE { ToBeSigned } ::= SEQUENCE {
+        algorithm AlgorithmIdentifier,
+        signature BIT STRING
+   }(CONSTRAINED BY {-- Must be the result of applying the signing
+     -- operation indicated in "algorithm" to the DER-encoded octets of
+     -- a value of type -- ToBeSigned })
+
+3.8. Other types
+
+   The "GeneralNames" type is defined in [RFC2459].
+
+4.  Supported Algorithms
+
+   The following signature algorithms are recognized for use with this
+   mechanism, and identified by a key.  Each key would be combined to
+   make two possible SASL mechanisms.  For example the DSA-SHA1
+   algorithm would give 9798-U-DSA-SHA1, and 9798-M-DSA-SHA1.  All
+   algorithm names are constrained to 13 characters, to keep within the
+   total SASL limit of 20 characters.
+
+   The following table gives a list of algorithm keys, noting the object
+   identifier and the body that assigned the identifier.
+
+      Key              Object Id           Body
+      RSA-SHA1-ENC   1.2.840.113549.1.1.5  RSA
+      DSA-SHA1       1.2.840.10040.4.3     ANSI
+      ECDSA-SHA1     1.2.840.10045.4.1     ANSI
+
+   Support of the RSA-SHA1-ENC algorithm is RECOMMENDED for use with
+   this mechanism.
+
+5.  Examples
+
+5.1. IMAP4 example
+
+   The following example shows the use of the ISO/IEC 9798-3
+   Authentication SASL mechanism with IMAP4 [RFC2060].
+
+   The base64 encoding of challenges and responses, as well as the "+ "
+   preceding the responses are part of the IMAP4 profile, not part of
+   this specification itself (note that the line breaks in the sample
+   authenticators are for editorial clarity and are not in real
+   authenticators).
+
+
+
+
+
+
+
+
+Zuccherato & Nystrom          Experimental                      [Page 9]
+
+RFC 3163      ISO/IEC 9798-3 Authentication SASL Mechanism   August 2001
+
+
+   S: * OK IMAP4 server ready
+   C: A001 AUTHENTICATE 9798-U-RSA-SHA1
+   S: + MAoECBI4l1h5h0eY
+   C: MIIBAgQIIxh5I0h5RYegD4INc2FzbC1yLXVzLmNvbaFPFk1odHRwOi8vY2VydHMt
+      ci11cy5jb20vY2VydD9paD1odmNOQVFFRkJRQURnWUVBZ2hBR2hZVFJna0ZqJnNu
+      PUVQOXVFbFkzS0RlZ2pscjCBkzANBgkqhkiG9w0BAQUFAAOBgQCkuC2GgtYcxGG1
+      NEzLA4bh5lqJGOZySACMmc+mDrV7A7KAgbpO2OuZpMCl7zvNt/L3OjQZatiX8d1X
+      buQ40l+g2TJzJt06o7ogomxdDwqlA/3zp2WMohlI0MotHmfDSWEDZmEYDEA3/eGg
+      kWyi1v1lEVdFuYmrTr8E4wE9hxdQrA==
+   S: A001 OK Welcome, 9798-U-RSA-SHA1 authenticated user: Magnus
+
+6. IANA Considerations
+
+   By registering the 9798-<U/M>-<algorithm> protocols as SASL
+   mechanisms, implementers will have a well-defined way of adding this
+   authentication mechanism to their product.  Here is the registration
+   template for the SASL mechanisms defined in this memo:
+
+        SASL mechanism names:     9798-U-RSA-SHA1-ENC
+                                  9798-M-RSA-SHA1-ENC
+                                  9798-U-DSA-SHA1
+                                  9798-M-DSA-SHA1
+                                  9798-U-ECDSA-SHA1
+                                  9798-M-ECDSA-SHA1
+                                  ; For a definition of the algorithms
+                                  see Section 4 of this memo.
+
+        Security Considerations:  See Section 7 of this memo
+        Published specification:  This memo
+        Person & email address to
+        contact for further
+        information:              See Section 9 of this memo.
+        Intended usage:           COMMON
+        Author/Change controller: See Section 9 of this memo.
+
+7.  Security Considerations
+
+   The mechanisms described in this memo only provides protection
+   against passive eavesdropping attacks.  They do not provide session
+   privacy or protection from active attacks.  In particular, man-in-
+   the-middle attacks aimed at session "hi-jacking" are possible.
+
+   The random numbers used in this protocol MUST be generated by a
+   cryptographically strong random number generator.  If the number is
+   chosen from a small set or is otherwise predictable by a third party,
+   then this mechanism can be attacked.
+
+
+
+
+
+Zuccherato & Nystrom          Experimental                     [Page 10]
+
+RFC 3163      ISO/IEC 9798-3 Authentication SASL Mechanism   August 2001
+
+
+   The inclusion of the random number R_A in the signed part of TokenAB
+   prevents the server from obtaining the signature of the client on
+   data chosen by the server prior to the start of the authentication
+   mechanism.  This measure may be required, for example, when the same
+   key is used by the client for purposes other than entity
+   authentication.  However, the inclusion of R_B in TokenBA2, whilst
+   necessary for security reasons which dictate that the client should
+   check that it is the same as the value sent in the first message, may
+   not offer the same protection to the server, since R_B is known to
+   the client before R_A is chosen.  For this reason a third random
+   number, R_C, is included in the TokenBA2 PDU.
+
+8.  Bibliography
+
+   [FIPS]      FIPS 196, "Entity authentication using public key
+               cryptography," Federal Information Processing Standards
+               Publication 196, U.S. Department of Commerce/N.I.S.T.,
+               National Technical Information Service, Springfield,
+               Virginia, 1997.
+
+   [ISO1]      ISO/IEC 9798-1:  1997, Information technology - Security
+               techniques - Entity authentication - Part 1: General.
+
+   [ISO3]      ISO/IEC 9798-3:  1997, Information technology - Security
+               techniques - Entity authentication - Part 3: Mechanisms
+               using digital signature techniques.
+
+   [PKCS15]    RSA Laboratories, "The Public-Key Cryptography Standards
+               - PKCS #15 v1.1:  Cryptographic token information syntax
+               standard", June 6, 2000.
+
+   [RFC1738]   Berners-Lee, T., Masinter L. and M. McCahill "Uniform
+               Resource Locators (URL)", RFC 1738, December 1994.
+
+   [RFC2026]   Bradner, S., "The Internet Standards Process -- Revision
+               3", BCP 9, RFC 2026, October 1996.
+
+   [RFC2060]   Crispin, M., "Internet Message Access Protocol - Version
+               4rev1", RFC 2060, December 1996.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2195]   Klensin, J., Catoe, R. and P. Krumviede "IMAP/POP
+               AUTHorize Extension for Simple Challenge/Response", RFC
+               2195, September 1997.
+
+
+
+
+
+Zuccherato & Nystrom          Experimental                     [Page 11]
+
+RFC 3163      ISO/IEC 9798-3 Authentication SASL Mechanism   August 2001
+
+
+   [RFC2222]   J. Meyers, "Simple Authentication and Security Layer",
+               RFC 2222, October 1997.
+
+   [RFC2459]   Housley, R., Ford, W., Polk, W. and D. Solo "Internet
+               X.509 Public Key Infrastructure: X.509 Certificate and
+               CRL Profile", RFC 2459, January 1999.
+
+   [RFC2630]   R. Housley, "Cryptographic Message Syntax", RFC 2630,
+               June 1999.
+
+   [X509]      ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8:1998,
+               Information Technology - Open Systems Interconnection -
+               The Directory: Authentication Framework.
+
+   [X690]      ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998,
+               Information Technology - ASN.1 Encoding Rules:
+               Specification of Basic Encoding Rules (BER), Canonical
+               Encoding Rules (CER) and Distinguished Encoding Rules
+               (DER).
+
+9. Authors' Addresses
+
+   Robert Zuccherato
+   Entrust Technologies
+   1000 Innovation Drive
+   Ottawa, Ontario
+   Canada K2K 3E7
+
+   Phone: +1 613 247 2598
+   EMail: robert.zuccherato@entrust.com
+
+
+   Magnus Nystrom
+   RSA Security
+   Box 10704
+   121 29 Stockholm
+   Sweden
+
+   Phone: +46 8 725 0900
+   EMail: magnus@rsasecurity.com
+
+
+
+
+
+
+
+
+
+
+
+Zuccherato & Nystrom          Experimental                     [Page 12]
+
+RFC 3163      ISO/IEC 9798-3 Authentication SASL Mechanism   August 2001
+
+
+APPENDICES
+
+A. ASN.1 modules
+
+A.1. 1988 ASN.1 module
+
+   SASL-9798-3-1988
+
+   DEFINITIONS IMPLICIT TAGS ::=
+
+   BEGIN
+
+   -- EXPORTS ALL --
+
+   IMPORTS
+
+   Name, AlgorithmIdentifier, Certificate
+        FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6)
+        internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
+        id-pkix1-explicit-88(1)}
+
+   GeneralNames
+        FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6)
+        internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
+        id-pkix1-implicit-88(2)};
+
+   TokenBA1 ::= SEQUENCE {
+        randomB   RandomNumber,
+        entityB   [0] GeneralNames OPTIONAL,
+        certPref  [1] SEQUENCE SIZE (1..MAX) OF TrustedAuth OPTIONAL
+   }
+
+   TokenAB ::= SEQUENCE {
+        randomA   RandomNumber,
+        entityB   [0] GeneralNames OPTIONAL,
+        certA     [1] CertData,
+        authID    [2] GeneralNames OPTIONAL,
+        signature SEQUENCE {
+             algorithm AlgorithmIdentifier,
+             signature BIT STRING
+       }
+   } -- 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.
+     -- The signature operation shall be done on a
+     -- DER-encoded value of type TBSDataAB.
+
+
+
+
+Zuccherato & Nystrom          Experimental                     [Page 13]
+
+RFC 3163      ISO/IEC 9798-3 Authentication SASL Mechanism   August 2001
+
+
+   TBSDataAB ::= SEQUENCE {
+        randomA RandomNumber,
+        randomB RandomNumber,
+        entityB [0] GeneralNames OPTIONAL,
+        authID  [1] GeneralNames OPTIONAL
+   }
+
+   TokenBA2 ::= SEQUENCE {
+        randomC   RandomNumber,
+        entityA   [0] GeneralNames OPTIONAL,
+        certB     [1] CertData,
+        signature SEQUENCE {
+             algorithm AlgorithmIdentifier,
+             signature BIT STRING
+        }
+   } -- The entityA field shall be included in TokenBA2
+     -- if and only if it is also included in TBSDataBA.  The entityA
+     -- field SHOULD be present and MUST contain the client's name
+     -- from their X.509 certificate.  The signature shall be done
+     -- on a DER-encoded value of type TBSDataBA.
+
+   TBSDataBA ::= SEQUENCE {
+        randomB RandomNumber,
+        randomA RandomNumber,
+        randomC RandomNumber,
+        entityA GeneralNames OPTIONAL
+   }
+
+   TrustedAuth ::= CHOICE {
+        authorityName         [0] Name,
+             -- SubjectName from CA certificate
+        issuerNameHash        [1] OCTET STRING,
+             -- SHA-1 hash of Authority's DN
+        issuerKeyHash         [2] OCTET STRING,
+             -- SHA-1 hash of Authority's public key
+        authorityCertificate  [3] Certificate,
+             -- CA certificate
+        pkcs15KeyHash         [4] OCTET STRING
+             -- PKCS #15 key hash
+   }
+
+   CertData ::= CHOICE {
+        certificateSet     SET SIZE (1..MAX) OF Certificate,
+        certURL            IA5String
+   }
+
+   RandomNumber ::= OCTET STRING (SIZE(8..MAX))
+
+
+
+
+Zuccherato & Nystrom          Experimental                     [Page 14]
+
+RFC 3163      ISO/IEC 9798-3 Authentication SASL Mechanism   August 2001
+
+
+   END
+
+A.2. 1997 ASN.1 module
+
+   SASL-9798-3-1997
+
+   DEFINITIONS IMPLICIT TAGS ::=
+
+   BEGIN
+
+   -- EXPORTS ALL --
+
+   IMPORTS
+
+   AlgorithmIdentifier, Name, Certificate
+        FROM PKIX1Explicit93 {iso(1) identified-organization(3) dod(6)
+        internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
+        id-pkix1-explicit-93(3)}
+
+   GeneralNames
+        FROM PKIX1Implicit93 {iso(1) identified-organization(3) dod(6)
+        internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
+        id-pkix1-implicit-93(4)};
+
+   TokenBA1 ::= SEQUENCE {
+        randomB   RandomNumber,
+        entityB   [0] GeneralNames OPTIONAL,
+        certPref  [1] SEQUENCE SIZE (1..MAX) OF TrustedAuth OPTIONAL
+   }
+
+   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.--})
+
+   TBSDataAB ::= SEQUENCE {
+        randomA RandomNumber,
+        randomB RandomNumber,
+        entityB [0] GeneralNames OPTIONAL,
+        authID  [1] GeneralNames OPTIONAL
+   }
+
+
+
+
+Zuccherato & Nystrom          Experimental                     [Page 15]
+
+RFC 3163      ISO/IEC 9798-3 Authentication SASL Mechanism   August 2001
+
+
+   TokenBA2 ::= SEQUENCE {
+        randomC   RandomNumber,
+        entityA   [0] GeneralNames OPTIONAL,
+        certB     [1] CertData,
+        signature SIGNATURE { TBSDataBA }
+   }(CONSTRAINED BY {-- The entityA field shall be included in TokenBA2
+     -- if and only if it is also included in TBSDataBA.  The entityA
+     -- field SHOULD be present and MUST contain the client's name
+     -- from their X.509 certificate.--})
+
+   TBSDataBA ::= SEQUENCE {
+        randomB RandomNumber,
+        randomA RandomNumber,
+        randomC RandomNumber,
+        entityA GeneralNames OPTIONAL
+   }
+
+   TrustedAuth ::= CHOICE {
+        authorityName         [0] Name,
+             -- SubjectName from CA certificate
+        issuerNameHash        [1] OCTET STRING,
+             -- SHA-1 hash of Authority's DN
+        issuerKeyHash         [2] OCTET STRING,
+             -- SHA-1 hash of Authority's public key
+        authorityCertificate  [3] Certificate,
+             -- CA certificate
+        pkcs15KeyHash         [4] OCTET STRING
+             -- PKCS #15 key hash
+   }
+
+   CertData ::= CHOICE {
+        certificateSet     SET SIZE (1..MAX) OF Certificate,
+        certURL            IA5String,
+        ... -- For future extensions
+   }
+
+   RandomNumber ::= OCTET STRING (SIZE(8..MAX))
+
+   SIGNATURE { ToBeSigned } ::= SEQUENCE {
+        algorithm AlgorithmIdentifier,
+        signature BIT STRING
+   }(CONSTRAINED BY {-- Must be the result of applying the signing
+     -- operation indicated in "algorithm" to the DER-encoded octets of
+     -- a value of type -- ToBeSigned })
+
+   END
+
+
+
+
+
+Zuccherato & Nystrom          Experimental                     [Page 16]
+
+RFC 3163      ISO/IEC 9798-3 Authentication SASL Mechanism   August 2001
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zuccherato & Nystrom          Experimental                     [Page 17]
+