Add.
[gsasl.git] / doc / specification / draft-zuccherato-9798-3-sasl-02.txt
blob49db03d3d7e88379a0b3b6dcdd8a6d6f8b734fa2
1 INTERNET-DRAFT                 Robert Zuccherato (Entrust Technologies)
2 Expires in six months                     Magnus Nystrom (RSA Security)
3 Intended Category: Experimental                          September 2000
5               ISO/IEC 9798-3 Authentication SASL Mechanism
7                  <draft-zuccherato-9798-3-sasl-02.txt>
9 Status of this Memo
11    This document is an Internet-Draft and is in full conformance with
12    all provisions of Section 10 of [RFC2026].  Internet-Drafts are
13    working documents of the Internet Engineering Task Force (IETF), its
14    areas, and its working groups.  Note that other groups may also
15    distribute working documents as Internet-Drafts.
17    Internet-Drafts are draft documents valid for a maximum of six months
18    and may be updated, replaced, or obsoleted by other documents at any
19    time.  It is inappropriate to use Internet-Drafts as reference
20    material or to cite them other than as "work in progress."
22    The list of current Internet-Drafts can be accessed at
23    http://www.ietf.org/ietf/1id-abstracts.txt
25    The list of Internet-Draft Shadow Directories can be accessed at
26    http://www.ietf.org/shadow.html.
28    To learn the current status of any Internet-Draft, please check the
29    "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
30    Directories on ds.internic.net (US East Coast), nic.nordu.net
31    (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
32    Rim).
34 Abstract
36    This document defines a SASL [RFC2222] authentication mechanism based
37    on ISO/IEC 9798-3 [ISO3] and FIPS PUB 196 [FIPS] entity
38    authentication.  This mechanism only provides authentication using
39    X.509 certificates [X509].  It has no effect on the protocol
40    encodings and does not provide integrity or confidentiality services.
42 1. Introduction
44  1.1. Overview
46    The key benefit of asymmetric (public key) security, is that the
47    secret (private key) only needs to be placed with the entity that is
48    being authenticated. Thus, a private key can be issued to a client,
52 Zuccherato & Nystrom       Expires: March 2001                  [Page 1]
54 INTERNET DRAFT            9798-3 SASL Mechanism           September 2000
57    which can then be authenticated by ANY server based on a token
58    generated by the client and the generally available public key.
59    Symmetric authentication mechanisms (password mechanisms such as
60    CRAM-MD5 [RFC2195]) require a shared secret, and the need to maintain
61    it at both endpoints.  This means that a secret key for the client
62    needs to be maintained at every server that may need to authenticate
63    the client.
65    The service described in this memo provides authentication only.
66    There are a number of places where an authentication only service is
67    useful, e.g., where confidentiality and integrity are provided by
68    lower layers, or where confidentiality or integrity services are
69    provided by the application.
71  1.2. Relationship to TLS
73    The functionality defined here can be provided by TLS, and it is
74    important to consider why it is useful to have it in both places.
75    There are several reasons for this, e.g.:
77     - Simplicity.  This mechanism is simpler than TLS.  If there is
78       only a requirement for this functionality (as distinct from all
79       of TLS), this simplicity will facilitate deployment.
81     - Layering.  The SASL mechanism to establish authentication works
82       cleanly with most protocols.  This mechanism can fit more cleanly
83       than TLS for some protocols.
85     - Proxies.  In some architectures the endpoint of the TLS session
86       may not be the application endpoint.  In these situations, this
87       mechanism can be used to obtain end-to-end authentication.
89     - Upgrade of authentication.  In some applications it may not be
90       clear at the time of TLS session negotiation what type of
91       authentication may be required (e.g. anonymous, server, client-
92       server).  This mechanism allows the negotiation of an anonymous
93       or server authenticated TLS session which can, at a later time,
94       be upgraded to provide the desired level of authentication.
96 2.  Description of Mechanism
98  2.1. Scope
100    The mechanism described in this memo provides either mutual or
101    unilateral entity authentication as defined in ISO/IEC 9798-1 [ISO1]
102    using an asymmetric (public-key) digital signature mechanism.
108 Zuccherato & Nystrom       Expires: March 2001                  [Page 2]
110 INTERNET DRAFT            9798-3 SASL Mechanism           September 2000
113  2.2. Authentication modes
115    This SASL mechanism contains two authentication modes:
117     - Unilateral client authentication: The client digitally signs a
118       challenge from the server, thus authenticating itself to the
119       server.
121     - Mutual authentication: The client digitally signs a challenge
122       from the server and the server digitally signs a challenge from
123       the client.  Thus both the client and server authenticate each
124       other.
126  2.3. SASL key
128    This mechanism has two SASL keys corresponding to the two different
129    modes:
131     - "9798-U-<algorithm>" for unilateral client authentication.
133     - "9798-M-<algorithm>" for mutual authentication.
135    Each SASL key may be used with a list of algorithms. A list of
136    supported algorithms is given in Section 4.
138  2.4. Unilateral Client Authentication
140    This section gives a brief description of the steps that are
141    performed for unilateral client authentication.  The actual data
142    structures are described fully in Section 3.
144    a) The server generates a random challenge value R_B and sends it to
145       the client.
147    b) The client generates a random value R_A and creates a token
148       TokenAB.  The token contains R_A, the client's certificate and
149       also a digital signature created by the client over both R_A and
150       R_B.  Optionally, it also contains an identifier for the server.
152    c) The client sends the token to the server.
154    d) The server verifies the token by:
156       - verifying the client's signature in TokenAB (this includes
157         full certificate path processing as described in [RFC2459]),
158       - verifying that the random number R_B, sent to the client in
159         Step 1, agrees with the random number contained in the signed
160         data of TokenAB, and
164 Zuccherato & Nystrom       Expires: March 2001                  [Page 3]
166 INTERNET DRAFT            9798-3 SASL Mechanism           September 2000
169       - verifying that the identifier for the server, if present,
170         matches the server's distinguishing identifier.
172  2.5. Mutual Authentication
174    This section gives a brief description of the steps that are
175    performed for mutual authentication. The actual data structures are
176    described fully in Section 3.
178    a) The server generates a random challenge value R_B and sends it to
179       the client.
181    b) The client generates a random value R_A and creates a token
182       TokenAB. The token contains R_A, the client's certificate and
183       also a digital signature created by the client over both R_A and
184       R_B. Optionally, it also contains an identifier for the server.
186    c) The client sends the token to the server.
188    d) The server verifies the token by:
190       - verifying the client's signature in TokenAB (this includes full
191         certificate path processing as described in [RFC2459]),
192       - verifying that the random number R_B, sent to the client in
193         Step 1, agrees with the random number contained in the signed
194         data of TokenAB, and
195       - verifying that the identifier for the server, if present,
196         matches the server's distinguishing identifier.
198    e) The server creates a token TokenBA.  The token contains a third
199       random value R_C, the server's certificate and a digital signature
200       created by the server over R_A, R_B and R_C.  Optionally, it also
201       contains an identifier for the client.
203    f) The server sends the token to the client.
205    g) The client verifies the token by:
207       - verifying the server's signature in TokenBA (this includes
208         full certificate path processing as described in [RFC2459]),
209       - verifying that the random number R_B, received by the client in
210         Step 1, agrees with the random number contained in the signed
211         data of TokenBA,
212       - verifying that the random number R_A, sent to the server in
213         Step 2, agrees with the random number contained in the signed
214         data of Token BA and
215       - verifying that the identifier for the client, if present,
216         matches the client's distinguishing identifier.
220 Zuccherato & Nystrom       Expires: March 2001                  [Page 4]
222 INTERNET DRAFT            9798-3 SASL Mechanism           September 2000
225 3.  Token and Message Definition
227    Note - Protocol data units (PDUs) SHALL be DER-encoded [X690] before
228           transmitted.
230  3.1. The "TokenBA1" PDU
232    TokenBA1 is used in both the unilateral client authentication and
233    mutual authentication modes and is sent by the server to the client.
235    TokenBA1 contains a random value, and, optionally, the servers name
236    and certificate information.
238    TokenBA1 ::= SEQUENCE {
239         randomB   RandomNumber,
240         entityB   [0] GeneralNames OPTIONAL,
241         certPref  [1] SEQUENCE SIZE (1..MAX) OF TrustedAuth OPTIONAL
242    }
244  3.2. The "TokenAB" PDU
246    TokenAB is used in the unilateral client authentication and mutual
247    authentication modes and is sent by the client to the server.
248    TokenAB contains a random number, entity B's name (optionally),
249    entity certification information, an (optional) authorization
250    identity, and a signature of a DER-encoded value of type TBSDataAB.
251    The certA field is used to send the client's X.509 certificate (or a
252    URL to it) and a related certificate chain to the server.
254    The authID field is to be used when the identity to be used for
255    access control is different than the identity contained in the
256    certificate of the signer. If this field is not present, then the
257    identity from the client's X.509 certificate shall be used.
259    TokenAB ::= SEQUENCE {
260         randomA   RandomNumber,
261         entityB   [0] GeneralNames OPTIONAL,
262         certA     [1] CertData,
263         authID    [2] GeneralNames OPTIONAL,
264         signature SIGNATURE { TBSDataAB }
265    }(CONSTRAINED BY {-- The entityB and authID fields shall be included
266      -- in TokenAB if and only if they are also included in TBSDataAB.
267      -- The entityB field SHOULD be present in TokenAB whenever the
268      -- client believes it knows the identity of the server.--})
270    TBSDataAB ::= SEQUENCE {
271         randomA RandomNumber,
272         randomB RandomNumber,
276 Zuccherato & Nystrom       Expires: March 2001                  [Page 5]
278 INTERNET DRAFT            9798-3 SASL Mechanism           September 2000
281         entityB [0] GeneralNames OPTIONAL,
282         authID  [1] GeneralNames OPTIONAL
283    }
285  3.3. The "TokenBA2" PDU
287    TokenBA2 is used in the mutual authentication mode and is sent by the
288    server to the client. TokenBA2 contains a random number, entity A's
289    name (optionally), certification information, and a signature of a
290    DER-encoded value of type TBSDataBA. The certB field is to be used to
291    send the server's X.509 certificate and a related certificate chain
292    to the client.
294    TokenBA2 ::= SEQUENCE {
295         randomC   RandomNumber,
296         entityA   [0] GeneralNames OPTIONAL,
297         certB     [1] CertData,
298         signature SIGNATURE { TBSDataBA }
299    }(CONSTRAINED BY {-- The entityA field shall be included in TokenBA2
300      -- if and only if it is also included in TBSDataBA. The entityA
301      -- field SHOULD be present and MUST contain the client's name
302      -- from their X.509 certificate.--})
304    TBSDataBA ::= SEQUENCE {
305         randomB RandomNumber,
306         randomA RandomNumber,
307         randomC RandomNumber,
308         entityA GeneralNames OPTIONAL
309    }
311  3.4. The "TrustedAuth" type
313    TrustedAuth ::= CHOICE {
314         authorityName         [0] Name,
315              -- SubjectName from CA certificate
316         issuerNameHash        [1] OCTET STRING,
317              -- SHA-1 hash of Authority's DN
318         issuerKeyHash         [2] OCTET STRING,
319              -- SHA-1 hash of Authority's public key
320         authorityCertificate  [3] Certificate,
321              -- CA certificate
322         pkcs15KeyHash         [4] OCTET STRING
323              -- PKCS #15 key hash
324    }
326    The TrustedAuth type can be used by a server in its inital message
327    ("TokenBA1") to indicate to a client preferred certificates/public
328    key pairs to use in the authentication.
332 Zuccherato & Nystrom       Expires: March 2001                  [Page 6]
334 INTERNET DRAFT            9798-3 SASL Mechanism           September 2000
337    A trusted authority is identified by its name, hash of its name, hash
338    of its public key, its certificate, or PKCS #15 key hash.  If
339    identified by its name, then the authorityName field in TrustedAuth
340    contains the SubjectName of its CA certificate.  If it is identified
341    by the hash of its name then the issuerNameHash field contains the
342    SHA-1 hash of the DER encoding of SubjectName from its CA
343    certificate.  If it is identified by the hash of its public key then
344    the issuerKeyHash field contains the SHA-1 hash of the authority's
345    public key. The hash shall be calculated over the value (excluding
346    tag and length) of the subject public key field in the issuer's
347    certificate.  If it is identified by its certificate then the
348    authorityCertificate field contains its CA certificate.  If it is
349    identified by the PKCS #15 key hash then the pkcs15KeyHash field
350    contains the hash of the CA's public key as defined in PKCS #15
351    [PKCS15] Section 6.1.4.
353  3.5. The "CertData" type
355    The certification data is a choice between a set of certificates and
356    a certificate URL.
358    The certificate set alternative is as in [RFC2630], meaning it is
359    intended that the set be sufficient to contain chains from a
360    recognized "root" or "top-level certification authority" to all of
361    the sender certificates with which the set is associated.  However,
362    there may be more certificates than necessary, or there may be fewer
363    than necessary.
365    Note - The precise meaning of a "chain" is outside the scope of this
366           document.  Some applications may impose upper limits on the
367           length of a chain; others may enforce certain relationships
368           between the subjects and issuers of certificates within a
369           chain.
371    When the certURL type is used to specify the location at which the
372    user's certificate can be found, it MUST be a non-relative URL, and
373    MUST follow the URL syntax and encoding rules specified in [RFC1738].
374    The URL must include both a scheme (e.g., "http" or "ldap") and a
375    scheme-specific part.  The scheme-specific part must include a fully
376    qualified domain name or IP address as the host.
378    CertData ::= CHOICE {
379         certificateSet     SET SIZE (1..MAX) OF Certificate,
380         certURL            IA5String,
381         ... -- For future extensions
382    }
388 Zuccherato & Nystrom       Expires: March 2001                  [Page 7]
390 INTERNET DRAFT            9798-3 SASL Mechanism           September 2000
393  3.6. The "RandomNumber" type
395    A random number is simply defined as an octet string, at least 8
396    bytes long.
398    RandomNumber ::= OCTET STRING (SIZE(8..MAX))
400  3.7. The "SIGNATURE" type
402    This is similar to the "SIGNED" parameterized type defined in
403    [RFC2459], the difference being that the "SIGNATURE" type does not
404    include the data to be signed.
406    SIGNATURE { ToBeSigned } ::= SEQUENCE {
407         algorithm AlgorithmIdentifier,
408         signature BIT STRING
409    }(CONSTRAINED BY {-- Must be the result of applying the signing
410      -- operation indicated in "algorithm" to the DER-encoded octets of
411      -- a value of type -- ToBeSigned })
413  3.8. Other types
415    The "GeneralNames" type is defined in [RFC2459].
417 4.  Supported Algorithms
419    The following signature algorithms are recognized for use with this
420    mechanism, and identified by a key.  Each key would be combined to
421    make two possible SASL mechanisms.  For example the DSA-SHA1
422    algorithm would give 9798-U-DSA-SHA1, and 9798-M-DSA-SHA1.  All
423    algorithm names are constrained to 13 characters, to keep within the
424    total SASL limit of 20 characters.
426    The following table gives a list of algorithm keys, noting the object
427    identifier and the body that assigned the identifier.
429                  Key              Object Id           Body
430                  RSA-SHA1-ENC   1.2.840.113549.1.1.5  RSA
431                  DSA-SHA1       1.2.840.10040.4.3     ANSI
432                  ECDSA-SHA1     1.2.840.10045.4.1     ANSI
434    Support of the RSA-SHA1-ENC algorithm is recommended for use with
435    this mechanism.
444 Zuccherato & Nystrom       Expires: March 2001                  [Page 8]
446 INTERNET DRAFT            9798-3 SASL Mechanism           September 2000
449 5.  Examples
451  5.1. IMAP4 example
453    The following example shows the use of the ISO/IEC 9798-3
454    Authentication SASL mechanism with IMAP4 [RFC2060].
456    The base64 encoding of challenges and responses, as well as the "+ "
457    preceding the responses are part of the IMAP4 profile, not part of
458    this specification itself (note that the line breaks in the sample
459    authenticators are for editorial clarity and are not in real
460    authenticators).
462    S: * OK IMAP4 server ready
463    C: A001 AUTHENTICATE 9798-U-RSA-SHA1
464    S: + MAoECBI4l1h5h0eY
465    C: MIIBAgQIIxh5I0h5RYegD4INc2FzbC1yLXVzLmNvbaFPFk1odHRwOi8vY2VydHMt
466       ci11cy5jb20vY2VydD9paD1odmNOQVFFRkJRQURnWUVBZ2hBR2hZVFJna0ZqJnNu
467       PUVQOXVFbFkzS0RlZ2pscjCBkzANBgkqhkiG9w0BAQUFAAOBgQCkuC2GgtYcxGG1
468       NEzLA4bh5lqJGOZySACMmc+mDrV7A7KAgbpO2OuZpMCl7zvNt/L3OjQZatiX8d1X
469       buQ40l+g2TJzJt06o7ogomxdDwqlA/3zp2WMohlI0MotHmfDSWEDZmEYDEA3/eGg
470       kWyi1v1lEVdFuYmrTr8E4wE9hxdQrA==
471    S: A001 OK Welcome, 9798-U-RSA-SHA1 authenticated user: Magnus
473 6. IANA Considerations
475    By registering the 9798-U-<algorithm> protocols as SASL mechanisms,
476    implementers will have a well-defined way of adding this
477    authentication mechanism to their product. Here is the registration
478    template for the 9798-U-<algorithm> SASL mechanisms:
480         SASL mechanism name:      9798-U-<algorithm> and
481                                   9798-M-<algorithm> ; for a definition
482                                   of <algorithm> see this memo.
483         Security Considerations:  See corresponding section of this memo
484         Published specification:  This memo
485         Person & email address to
486         contact for further
487         information:              See author's address section below
488         Intended usage:           COMMON
489         Author/Change controller: See author's address section below
491 7.  Security Considerations
493    The mechanisms described in this memo only provides protection
494    against passive eavesdropping attacks. They do not provide session
495    privacy or protection from active attacks. In particular, man-in-the-
496    middle attacks aimed at session "hi-jacking" are possible.
500 Zuccherato & Nystrom       Expires: March 2001                  [Page 9]
502 INTERNET DRAFT            9798-3 SASL Mechanism           September 2000
505    The random numbers used in this protocol MUST be generated by a
506    cryptographically strong random number generator. If the number is
507    chosen from a small set or is otherwise predictable by a third party,
508    then this mechanism can be attacked.
510    The inclusion of the random number R_A in the signed part of TokenAB
511    prevents the server from obtaining the signature of the client on
512    data chosen by the server prior to the start of the authentication
513    mechanism.  This measure may be required, for example, when the same
514    key is used by the client for purposes other than entity
515    authentication.  However, the inclusion of R_B in TokenBA2, whilst
516    necessary for security reasons which dictate that the client should
517    check that it is the same as the value sent in the first message, may
518    not offer the same protection to the server, since R_B is known to
519    the client before R_A is chosen. For this reason a third random
520    number, R_C, is included in the TokenBA2 PDU.
522 8.  Bibliography
524    [FIPS] FIPS 196, "Entity authentication using public key
525    cryptography," Federal Information Processing Standards Publication
526    196, U.S. Department of Commerce/N.I.S.T., National Technical
527    Information Service, Springfield, Virginia, 1997.
529    [ISO1] ISO/IEC 9798-1:  1997, Information technology - Security
530    techniques - Entity authentication - Part 1: General.
532    [ISO3] ISO/IEC 9798-3:  1997, Information technology - Security
533    techniques - Entity authentication - Part 3: Mechanisms using digital
534    signature techniques.
536    [RFC1738] Berners-Lee, T., Masinter L., and M. McCahill "Uniform
537    Resource Locators (URL)," RFC 1738, December 1994.
539    [RFC2195] Klensin, J., Catoe, R., and P. Krumviede "IMAP/POP
540    AUTHorize Extension for Simple Challenge/Response," RFC 2195,
541    September 1997.
543    [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
544    3," RFC 2026, October 1996.
546    [PKCS15] RSA Laboratories, "The Public-Key Cryptography Standards -
547    PKCS #15 v1.1:  Cryptographic token information syntax standard",
548    June 6, 2000.
550    [RFC 2060] Crispin, M., "Internet Message Access Protocol - Version
551    4rev1," RFC 2060, December 1996.
556 Zuccherato & Nystrom       Expires: March 2001                 [Page 10]
558 INTERNET DRAFT            9798-3 SASL Mechanism           September 2000
561    [RFC2222] J. Meyers, "Simple Authentication and Security Layer," RFC
562    2222, October 1997.
564    [RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo "Internet X.509
565    Public Key Infrastructure: X.509 Certificate and CRL Profile," RFC
566    2459, January 1999.
568    [RFC2630] R. Housley, "Cryptographic Message Syntax," RFC 2630, June
569    1999.
571    [X509] ITU-T Recommendation X.509 (2000) | ISO/IEC 9594-8:2000,
572    Information Technology - Open Systems Interconnection - The
573    Directory:  Public-Key And Attribute Certificate Frameworks, 3rd
574    draft, May 2000.
576    [X690] ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998,
577    Information Technology - ASN.1 Encoding Rules: Specification of Basic
578    Encoding Rules (BER), Canonical Encoding Rules (CER) and
579    Distinguished Encoding Rules (DER).
581 9. Authors' Addresses
583    Robert Zuccherato
584    Entrust Technologies
585    750 Heron Road
586    Ottawa, Ontario
587    Canada K1V 1A7
588    Phone: +1 613 247 2598
589    Email: robert.zuccherato@entrust.com
591    Magnus Nystrom
592    RSA Security
593    Box 10704
594    121 29 Stockholm
595    Sweden
596    Phone: +46 8 725 0900
597    Email: magnus@rsasecurity.com
612 Zuccherato & Nystrom       Expires: March 2001                 [Page 11]
614 INTERNET DRAFT            9798-3 SASL Mechanism           September 2000
617 APPENDICES
619 A. ASN.1 modules
621  A.1. 1988 ASN.1 module
623    SASL-9798-3-1988
625    DEFINITIONS IMPLICIT TAGS ::=
627    BEGIN
629    -- EXPORTS ALL --
631    IMPORTS
633    Name, AlgorithmIdentifier, Certificate
634         FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6)
635         internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
636         id-pkix1-explicit-88(1)}
638    GeneralNames
639         FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6)
640         internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
641         id-pkix1-implicit-88(2)};
643    TokenBA1 ::= SEQUENCE {
644         randomB   RandomNumber,
645         entityB   [0] GeneralNames OPTIONAL,
646         certPref  [1] SEQUENCE SIZE (1..MAX) OF TrustedAuth OPTIONAL
647    }
649    TokenAB ::= SEQUENCE {
650         randomA   RandomNumber,
651         entityB   [0] GeneralNames OPTIONAL,
652         certA     [1] CertData,
653         authID    [2] GeneralNames OPTIONAL,
654         signature SEQUENCE {
655              algorithm AlgorithmIdentifier,
656              signature BIT STRING
657        }
658    } -- The entityB and authID fields shall be included in TokenAB
659      -- if and only if they are also included in TBSDataAB. The entityB
660      -- field SHOULD be present in TokenAB whenever the client
661      -- believes it knows the identity of the server.
662      -- The signature operation shall be done on a
663      -- DER-encoded value of type TBSDataAB.
668 Zuccherato & Nystrom       Expires: March 2001                 [Page 12]
670 INTERNET DRAFT            9798-3 SASL Mechanism           September 2000
673    TBSDataAB ::= SEQUENCE {
674         randomA RandomNumber,
675         randomB RandomNumber,
676         entityB [0] GeneralNames OPTIONAL,
677         authID  [1] GeneralNames OPTIONAL
678    }
680    TokenBA2 ::= SEQUENCE {
681         randomC   RandomNumber,
682         entityA   [0] GeneralNames OPTIONAL,
683         certB     [1] CertData,
684         signature SEQUENCE {
685              algorithm AlgorithmIdentifier,
686              signature BIT STRING
687         }
688    } -- The entityA field shall be included in TokenBA2
689      -- if and only if it is also included in TBSDataBA. The entityA
690      -- field SHOULD be present and MUST contain the client's name
691      -- from their X.509 certificate.  The signature shall be done
692      -- on a DER-encoded value of type TBSDataBA.
694    TBSDataBA ::= SEQUENCE {
695         randomB RandomNumber,
696         randomA RandomNumber,
697         randomC RandomNumber,
698         entityA GeneralNames OPTIONAL
699    }
701    TrustedAuth ::= CHOICE {
702         authorityName         [0] Name,
703              -- SubjectName from CA certificate
704         issuerNameHash        [1] OCTET STRING,
705              -- SHA-1 hash of Authority's DN
706         issuerKeyHash         [2] OCTET STRING,
707              -- SHA-1 hash of Authority's public key
708         authorityCertificate  [3] Certificate,
709              -- CA certificate
710         pkcs15KeyHash         [4] OCTET STRING
711              -- PKCS #15 key hash
712    }
714    CertData ::= CHOICE {
715         certificateSet     SET SIZE (1..MAX) OF Certificate,
716         certURL            IA5String
717    }
719    RandomNumber ::= OCTET STRING (SIZE(8..MAX))
724 Zuccherato & Nystrom       Expires: March 2001                 [Page 13]
726 INTERNET DRAFT            9798-3 SASL Mechanism           September 2000
729    END
731  A.2. 1997 ASN.1 module
733    SASL-9798-3-1997
735    DEFINITIONS IMPLICIT TAGS ::=
737    BEGIN
739    -- EXPORTS ALL --
741    IMPORTS
743    AlgorithmIdentifier, Name, Certificate
744         FROM PKIX1Explicit93 {iso(1) identified-organization(3) dod(6)
745         internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
746         id-pkix1-explicit-93(3)}
748    GeneralNames
749         FROM PKIX1Implicit93 {iso(1) identified-organization(3) dod(6)
750         internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
751         id-pkix1-implicit-93(4)};
753    TokenBA1 ::= SEQUENCE {
754         randomB   RandomNumber,
755         entityB   [0] GeneralNames OPTIONAL,
756         certPref  [1] SEQUENCE SIZE (1..MAX) OF TrustedAuth OPTIONAL
757    }
759    TokenAB ::= SEQUENCE {
760         randomA   RandomNumber,
761         entityB   [0] GeneralNames OPTIONAL,
762         certA     [1] CertData,
763         authID    [2] GeneralNames OPTIONAL,
764         signature SIGNATURE { TBSDataAB }
765    }(CONSTRAINED BY {-- The entityB and authID fields shall be included
766      -- in TokenAB if and only if they are also included in TBSDataAB.
767      -- The entityB field SHOULD be present in TokenAB whenever the
768      -- client believes it knows the identity of the server.--})
770    TBSDataAB ::= SEQUENCE {
771         randomA RandomNumber,
772         randomB RandomNumber,
773         entityB [0] GeneralNames OPTIONAL,
774         authID  [1] GeneralNames OPTIONAL
775    }
780 Zuccherato & Nystrom       Expires: March 2001                 [Page 14]
782 INTERNET DRAFT            9798-3 SASL Mechanism           September 2000
785    TokenBA2 ::= SEQUENCE {
786         randomC   RandomNumber,
787         entityA   [0] GeneralNames OPTIONAL,
788         certB     [1] CertData,
789         signature SIGNATURE { TBSDataBA }
790    }(CONSTRAINED BY {-- The entityA field shall be included in TokenBA2
791      -- if and only if it is also included in TBSDataBA. The entityA
792      -- field SHOULD be present and MUST contain the client's name
793      -- from their X.509 certificate.--})
795    TBSDataBA ::= SEQUENCE {
796         randomB RandomNumber,
797         randomA RandomNumber,
798         randomC RandomNumber,
799         entityA GeneralNames OPTIONAL
800    }
802    TrustedAuth ::= CHOICE {
803         authorityName         [0] Name,
804              -- SubjectName from CA certificate
805         issuerNameHash        [1] OCTET STRING,
806              -- SHA-1 hash of Authority's DN
807         issuerKeyHash         [2] OCTET STRING,
808              -- SHA-1 hash of Authority's public key
809         authorityCertificate  [3] Certificate,
810              -- CA certificate
811         pkcs15KeyHash         [4] OCTET STRING
812              -- PKCS #15 key hash
813    }
815    CertData ::= CHOICE {
816         certificateSet     SET SIZE (1..MAX) OF Certificate,
817         certURL            IA5String,
818         ... -- For future extensions
819    }
821    RandomNumber ::= OCTET STRING (SIZE(8..MAX))
823    SIGNATURE { ToBeSigned } ::= SEQUENCE {
824         algorithm AlgorithmIdentifier,
825         signature BIT STRING
826    }(CONSTRAINED BY {-- Must be the result of applying the signing
827      -- operation indicated in "algorithm" to the DER-encoded octets of
828      -- a value of type -- ToBeSigned })
830    END
836 Zuccherato & Nystrom       Expires: March 2001                 [Page 15]