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

   1 INTERNET-DRAFT                 Robert Zuccherato (Entrust Technologies)
   2 Expires in six months                     Magnus Nystrom (RSA Security)
   3 Intended Category: Experimental                          September 2000
   4
   5               ISO/IEC 9798-3 Authentication SASL Mechanism
   6
   7                  <draft-zuccherato-9798-3-sasl-02.txt>
   8
   9 Status of this Memo
  10
  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.
  16
  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."
  21
  22    The list of current Internet-Drafts can be accessed at
  23    http://www.ietf.org/ietf/1id-abstracts.txt
  24
  25    The list of Internet-Draft Shadow Directories can be accessed at
  26    http://www.ietf.org/shadow.html.
  27
  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).
  33
  34 Abstract
  35
  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.
  41
  42 1. Introduction
  43
  44  1.1. Overview
  45
  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,
  49
  50
  51
  52 Zuccherato & Nystrom       Expires: March 2001                  [Page 1]
  53 \f
  54 INTERNET DRAFT            9798-3 SASL Mechanism           September 2000
  55
  56
  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.
  64
  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.
  70
  71  1.2. Relationship to TLS
  72
  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.:
  76
  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.
  80
  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.
  84
  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.
  88
  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.
  95
  96 2.  Description of Mechanism
  97
  98  2.1. Scope
  99
 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.
 103
 104
 105
 106
 107
 108 Zuccherato & Nystrom       Expires: March 2001                  [Page 2]
 109 \f
 110 INTERNET DRAFT            9798-3 SASL Mechanism           September 2000
 111
 112
 113  2.2. Authentication modes
 114
 115    This SASL mechanism contains two authentication modes:
 116
 117     - Unilateral client authentication: The client digitally signs a
 118       challenge from the server, thus authenticating itself to the
 119       server.
 120
 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.
 125
 126  2.3. SASL key
 127
 128    This mechanism has two SASL keys corresponding to the two different
 129    modes:
 130
 131     - "9798-U-<algorithm>" for unilateral client authentication.
 132
 133     - "9798-M-<algorithm>" for mutual authentication.
 134
 135    Each SASL key may be used with a list of algorithms. A list of
 136    supported algorithms is given in Section 4.
 137
 138  2.4. Unilateral Client Authentication
 139
 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.
 143
 144    a) The server generates a random challenge value R_B and sends it to
 145       the client.
 146
 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.
 151
 152    c) The client sends the token to the server.
 153
 154    d) The server verifies the token by:
 155
 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
 161
 162
 163
 164 Zuccherato & Nystrom       Expires: March 2001                  [Page 3]
 165 \f
 166 INTERNET DRAFT            9798-3 SASL Mechanism           September 2000
 167
 168
 169       - verifying that the identifier for the server, if present,
 170         matches the server's distinguishing identifier.
 171
 172  2.5. Mutual Authentication
 173
 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.
 177
 178    a) The server generates a random challenge value R_B and sends it to
 179       the client.
 180
 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.
 185
 186    c) The client sends the token to the server.
 187
 188    d) The server verifies the token by:
 189
 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.
 197
 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.
 202
 203    f) The server sends the token to the client.
 204
 205    g) The client verifies the token by:
 206
 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.
 217
 218
 219
 220 Zuccherato & Nystrom       Expires: March 2001                  [Page 4]
 221 \f
 222 INTERNET DRAFT            9798-3 SASL Mechanism           September 2000
 223
 224
 225 3.  Token and Message Definition
 226
 227    Note - Protocol data units (PDUs) SHALL be DER-encoded [X690] before
 228           transmitted.
 229
 230  3.1. The "TokenBA1" PDU
 231
 232    TokenBA1 is used in both the unilateral client authentication and
 233    mutual authentication modes and is sent by the server to the client.
 234
 235    TokenBA1 contains a random value, and, optionally, the servers name
 236    and certificate information.
 237
 238    TokenBA1 ::= SEQUENCE {
 239         randomB   RandomNumber,
 240         entityB   [0] GeneralNames OPTIONAL,
 241         certPref  [1] SEQUENCE SIZE (1..MAX) OF TrustedAuth OPTIONAL
 242    }
 243
 244  3.2. The "TokenAB" PDU
 245
 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.
 253
 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.
 258
 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.--})
 269
 270    TBSDataAB ::= SEQUENCE {
 271         randomA RandomNumber,
 272         randomB RandomNumber,
 273
 274
 275
 276 Zuccherato & Nystrom       Expires: March 2001                  [Page 5]
 277 \f
 278 INTERNET DRAFT            9798-3 SASL Mechanism           September 2000
 279
 280
 281         entityB [0] GeneralNames OPTIONAL,
 282         authID  [1] GeneralNames OPTIONAL
 283    }
 284
 285  3.3. The "TokenBA2" PDU
 286
 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.
 293
 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.--})
 303
 304    TBSDataBA ::= SEQUENCE {
 305         randomB RandomNumber,
 306         randomA RandomNumber,
 307         randomC RandomNumber,
 308         entityA GeneralNames OPTIONAL
 309    }
 310
 311  3.4. The "TrustedAuth" type
 312
 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    }
 325
 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.
 329
 330
 331
 332 Zuccherato & Nystrom       Expires: March 2001                  [Page 6]
 333 \f
 334 INTERNET DRAFT            9798-3 SASL Mechanism           September 2000
 335
 336
 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.
 352
 353  3.5. The "CertData" type
 354
 355    The certification data is a choice between a set of certificates and
 356    a certificate URL.
 357
 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.
 364
 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.
 370
 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.
 377
 378    CertData ::= CHOICE {
 379         certificateSet     SET SIZE (1..MAX) OF Certificate,
 380         certURL            IA5String,
 381         ... -- For future extensions
 382    }
 383
 384
 385
 386
 387
 388 Zuccherato & Nystrom       Expires: March 2001                  [Page 7]
 389 \f
 390 INTERNET DRAFT            9798-3 SASL Mechanism           September 2000
 391
 392
 393  3.6. The "RandomNumber" type
 394
 395    A random number is simply defined as an octet string, at least 8
 396    bytes long.
 397
 398    RandomNumber ::= OCTET STRING (SIZE(8..MAX))
 399
 400  3.7. The "SIGNATURE" type
 401
 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.
 405
 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 })
 412
 413  3.8. Other types
 414
 415    The "GeneralNames" type is defined in [RFC2459].
 416
 417 4.  Supported Algorithms
 418
 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.
 425
 426    The following table gives a list of algorithm keys, noting the object
 427    identifier and the body that assigned the identifier.
 428
 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
 433
 434    Support of the RSA-SHA1-ENC algorithm is recommended for use with
 435    this mechanism.
 436
 437
 438
 439
 440
 441
 442
 443
 444 Zuccherato & Nystrom       Expires: March 2001                  [Page 8]
 445 \f
 446 INTERNET DRAFT            9798-3 SASL Mechanism           September 2000
 447
 448
 449 5.  Examples
 450
 451  5.1. IMAP4 example
 452
 453    The following example shows the use of the ISO/IEC 9798-3
 454    Authentication SASL mechanism with IMAP4 [RFC2060].
 455
 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).
 461
 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
 472
 473 6. IANA Considerations
 474
 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:
 479
 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
 490
 491 7.  Security Considerations
 492
 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.
 497
 498
 499
 500 Zuccherato & Nystrom       Expires: March 2001                  [Page 9]
 501 \f
 502 INTERNET DRAFT            9798-3 SASL Mechanism           September 2000
 503
 504
 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.
 509
 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.
 521
 522 8.  Bibliography
 523
 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.
 528
 529    [ISO1] ISO/IEC 9798-1:  1997, Information technology - Security
 530    techniques - Entity authentication - Part 1: General.
 531
 532    [ISO3] ISO/IEC 9798-3:  1997, Information technology - Security
 533    techniques - Entity authentication - Part 3: Mechanisms using digital
 534    signature techniques.
 535
 536    [RFC1738] Berners-Lee, T., Masinter L., and M. McCahill "Uniform
 537    Resource Locators (URL)," RFC 1738, December 1994.
 538
 539    [RFC2195] Klensin, J., Catoe, R., and P. Krumviede "IMAP/POP
 540    AUTHorize Extension for Simple Challenge/Response," RFC 2195,
 541    September 1997.
 542
 543    [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
 544    3," RFC 2026, October 1996.
 545
 546    [PKCS15] RSA Laboratories, "The Public-Key Cryptography Standards -
 547    PKCS #15 v1.1:  Cryptographic token information syntax standard",
 548    June 6, 2000.
 549
 550    [RFC 2060] Crispin, M., "Internet Message Access Protocol - Version
 551    4rev1," RFC 2060, December 1996.
 552
 553
 554
 555
 556 Zuccherato & Nystrom       Expires: March 2001                 [Page 10]
 557 \f
 558 INTERNET DRAFT            9798-3 SASL Mechanism           September 2000
 559
 560
 561    [RFC2222] J. Meyers, "Simple Authentication and Security Layer," RFC
 562    2222, October 1997.
 563
 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.
 567
 568    [RFC2630] R. Housley, "Cryptographic Message Syntax," RFC 2630, June
 569    1999.
 570
 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.
 575
 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).
 580
 581 9. Authors' Addresses
 582
 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
 590
 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
 598
 599
 600
 601
 602
 603
 604
 605
 606
 607
 608
 609
 610
 611
 612 Zuccherato & Nystrom       Expires: March 2001                 [Page 11]
 613 \f
 614 INTERNET DRAFT            9798-3 SASL Mechanism           September 2000
 615
 616
 617 APPENDICES
 618
 619 A. ASN.1 modules
 620
 621  A.1. 1988 ASN.1 module
 622
 623    SASL-9798-3-1988
 624
 625    DEFINITIONS IMPLICIT TAGS ::=
 626
 627    BEGIN
 628
 629    -- EXPORTS ALL --
 630
 631    IMPORTS
 632
 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)}
 637
 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)};
 642
 643    TokenBA1 ::= SEQUENCE {
 644         randomB   RandomNumber,
 645         entityB   [0] GeneralNames OPTIONAL,
 646         certPref  [1] SEQUENCE SIZE (1..MAX) OF TrustedAuth OPTIONAL
 647    }
 648
 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.
 664
 665
 666
 667
 668 Zuccherato & Nystrom       Expires: March 2001                 [Page 12]
 669 \f
 670 INTERNET DRAFT            9798-3 SASL Mechanism           September 2000
 671
 672
 673    TBSDataAB ::= SEQUENCE {
 674         randomA RandomNumber,
 675         randomB RandomNumber,
 676         entityB [0] GeneralNames OPTIONAL,
 677         authID  [1] GeneralNames OPTIONAL
 678    }
 679
 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.
 693
 694    TBSDataBA ::= SEQUENCE {
 695         randomB RandomNumber,
 696         randomA RandomNumber,
 697         randomC RandomNumber,
 698         entityA GeneralNames OPTIONAL
 699    }
 700
 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    }
 713
 714    CertData ::= CHOICE {
 715         certificateSet     SET SIZE (1..MAX) OF Certificate,
 716         certURL            IA5String
 717    }
 718
 719    RandomNumber ::= OCTET STRING (SIZE(8..MAX))
 720
 721
 722
 723
 724 Zuccherato & Nystrom       Expires: March 2001                 [Page 13]
 725 \f
 726 INTERNET DRAFT            9798-3 SASL Mechanism           September 2000
 727
 728
 729    END
 730
 731  A.2. 1997 ASN.1 module
 732
 733    SASL-9798-3-1997
 734
 735    DEFINITIONS IMPLICIT TAGS ::=
 736
 737    BEGIN
 738
 739    -- EXPORTS ALL --
 740
 741    IMPORTS
 742
 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)}
 747
 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)};
 752
 753    TokenBA1 ::= SEQUENCE {
 754         randomB   RandomNumber,
 755         entityB   [0] GeneralNames OPTIONAL,
 756         certPref  [1] SEQUENCE SIZE (1..MAX) OF TrustedAuth OPTIONAL
 757    }
 758
 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.--})
 769
 770    TBSDataAB ::= SEQUENCE {
 771         randomA RandomNumber,
 772         randomB RandomNumber,
 773         entityB [0] GeneralNames OPTIONAL,
 774         authID  [1] GeneralNames OPTIONAL
 775    }
 776
 777
 778
 779
 780 Zuccherato & Nystrom       Expires: March 2001                 [Page 14]
 781 \f
 782 INTERNET DRAFT            9798-3 SASL Mechanism           September 2000
 783
 784
 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.--})
 794
 795    TBSDataBA ::= SEQUENCE {
 796         randomB RandomNumber,
 797         randomA RandomNumber,
 798         randomC RandomNumber,
 799         entityA GeneralNames OPTIONAL
 800    }
 801
 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    }
 814
 815    CertData ::= CHOICE {
 816         certificateSet     SET SIZE (1..MAX) OF Certificate,
 817         certURL            IA5String,
 818         ... -- For future extensions
 819    }
 820
 821    RandomNumber ::= OCTET STRING (SIZE(8..MAX))
 822
 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 })
 829
 830    END
 831
 832
 833
 834
 835
 836 Zuccherato & Nystrom       Expires: March 2001                 [Page 15]