summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3163.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3163.txt')
-rw-r--r--doc/rfc/rfc3163.txt955
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]
+