doc/specification/rfc3163.txt

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