doc/specification/draft-zuccherato-9798-3-sasl-01.txt

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