home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_a_c / draft-ietf-asid-ldapv3-strong-00.txt < prev    next >
Text File  |  1997-03-27  |  12KB  |  289 lines
  1. Network Working Group                                            M. Wahl
  2. INTERNET-DRAFT                                       Critical Angle Inc.
  3. Expires in six months from                                 24 March 1997
  4.  
  5.       X.500 Strong Authentication Mechanisms for LDAPv3
  6.         <draft-ietf-asid-ldapv3-strong-00.txt>
  7.  
  8. 1. Status of this Memo
  9.  
  10.    This document is an Internet-Draft.  Internet-Drafts are working 
  11.    documents of the Internet Engineering Task Force (IETF), its areas, and
  12.    its working groups.  Note that other groups may also distribute working
  13.    documents as Internet-Drafts.
  14.  
  15.    Internet-Drafts are draft documents valid for a maximum of six months
  16.    and may be updated, replaced, or obsoleted by other documents at any
  17.    time.  It is inappropriate to use Internet-Drafts as reference material
  18.    or to cite them other than as "work in progress."
  19.  
  20.    To learn the current status of any Internet-Draft, please check the
  21.    "1id-abstracts.txt" listing  contained in the Internet-Drafts Shadow
  22.    Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
  23.    ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
  24.  
  25. 2. Abstract
  26.  
  27.    This document defines two SASL [1] authentication mechanisms which may
  28.    be used with LDAPv3 [2].  These mechanisms are only for authentication, 
  29.    they have no effect on the protocol encodings and are not designed to 
  30.    provide integrity or confidentiality services.
  31.  
  32. 3. Model
  33.  
  34.    Two mechanisms are defined, which are equivalent to the "protected"
  35.    password and "strong" mechanisms of X.500.  Unprotected password 
  36.    authentication is done using the existing LDAP "simple" bind, not with
  37.    SASL.  These mechanisms may also be used in other SASL-based protocols.
  38.  
  39.    The client may include one of these mechanisms and its credential in the 
  40.    BindRequest.
  41.  
  42.    The server will return a BindResponse with one of the following result
  43.    codes:
  44.  
  45.     - success, and the serverCreds field absent, implying that the server
  46.       successfully authenticated the client but is not returning any 
  47.       authentication information about the server;
  48.  
  49.     - success, and the serverCreds field present, with the same mechanism
  50.       as that requested by the client, and the credentials of the server 
  51.       itself;
  52.  
  53.     - protocolError, if the server does not implement LDAP version 3,
  54.  
  55.     - authMethodNotSupported, if the server does not implement this 
  56.       mechanism;
  57.  
  58.  
  59.  
  60. INTERNET-DRAFT                                                March 1997
  61.  
  62.     - strongAuthRequired, referral, inappropriateAuthentication, 
  63.       invalidCredentials, busy or unavailable, if the server did not 
  64.       successfully authenticate the client.
  65.  
  66.    If the server supports either of these mechanisms, the mechanism name(s)
  67.    must be included as values in the root DSE attribute 
  68.    supportedSASLMechanisms.
  69.  
  70. 4. Encoding Requirements
  71.  
  72.    This document describes data elements using ASN.1 structures, which are
  73.    encoding using a subset of the Basic Encoding Rules, as done in LDAPv3 [2]. 
  74.    Implementations must follow the encoding restrictions of LDAP, and 
  75.    additional encoding restrictions apply to the elements defined in this 
  76.    specification:
  77.  
  78.    - BIT STRING values are to be encoded in primitive form only. Unused bits 
  79.      in the final octet of the encoding of a BIT STRING value, if there are 
  80.      any, should always be set to zero.
  81.  
  82.    - UTC Times must be encoded with the "Z" suffix, not as a local time. 
  83.  
  84. 5. X.511-Protected
  85.  
  86.    The "X.511-Protected" authentication mechanism allows a hash of the 
  87.    password, combined optionally with the current time and random 
  88.    numbers, to be sent to or returned from the server.  The protected field 
  89.    contains the hash value.  This prevents a password from being carried in 
  90.    the clear.
  91.  
  92.    The mechanism field is set to the string "X.511-Protected", and the 
  93.    credentials field contain the DER encoding of a value of the following 
  94.    ASN.1 type:
  95.  
  96.         ProtectedPassword ::= SEQUENCE {
  97.                 time1                   [0] UTCTime OPTIONAL,
  98.                 time2                   [1] UTCTime OPTIONAL,
  99.                 random1                 [2] BIT STRING OPTIONAL,
  100.                 random2                 [3] BIT STRING OPTIONAL,
  101.                 algorithmIdentifier     [4] LDAPOID,
  102.                 encipheredPassword      [5] BIT STRING }
  103.  
  104.    The use of the time1, time2, random1, random2 and encipheredPassword fields 
  105.    are as defined in ITU-T Rec. X.509 [3] and the functional profile for X.500
  106.    for the environment in which this authentication mechanism is to be used.
  107.  
  108.    The algorithmIdentifier must be an entirely numeric string representation
  109.    of an OBJECT IDENTIFIER.
  110.  
  111.    The name field of the BindRequest must be a nonempty string when this
  112.    mechanism is being used to authenticate the client.  Note that this 
  113.    security mechanism is not intended to protect against attackers 
  114.    modifying the bind name field or other protocol elements.
  115.  
  116.  
  117.  
  118. INTERNET-DRAFT                                                March 1997
  119.  
  120. 6. X.511-Strong
  121.  
  122.    Strong authentication to the directory can be accomplished using the 
  123.    "X.511-Strong".
  124.  
  125.    The mechanism field is set to the string "X.511-Strong", and the 
  126.    credentials field set to a DER-encoding of a value of the following 
  127.    ASN.1 type:
  128.  
  129.         StrongCredentials ::= SEQUENCE {
  130.                 certification-path      [0] AF.CertificationPath OPTIONAL,
  131.                 bind-token              [1] DAS.Token }
  132.  
  133.    The ASN.1 type "CertificationPath" is defined in X.509 [3], and the ASN.1 
  134.    type "Token" is defined in X.511 [4].  The procedures for generation and 
  135.    validation of the bind token are defined in X.509 and X.511.
  136.  
  137.    When the credentials are being used to authenticate the client, it is 
  138.    recommended that the certification-path field be present, which will
  139.    contain minimally the client's certificate. If the certification-path 
  140.    field is supplied, then the name field of the BindRequest must be an 
  141.    empty string, and the server will obtain the name of the client from 
  142.    the subject field of the certification-path userCertificate.
  143.  
  144.    It is recommended for interoperability that if the server's or client's 
  145.    certificates contain RSA public keys, the PKCS md5WithRSAEncryption 
  146.    (1.2.840.113549.1.1.4) algorithm should be used.
  147.  
  148. 7. Attributes in the Root DSE
  149.  
  150.    This document defines three attributes which may be present in the 
  151.    server's root DSE.
  152.  
  153. 7.1. Checking the Current Time
  154.  
  155.    With these mechanisms, authentication between the client and the server 
  156.    may fail due to a lack of clock synchronization.  This may be detected by 
  157.    the client, by reading the currentTime attribute.
  158.  
  159.    This attribute has a single value, a string containing a GeneralizedTime 
  160.    character string.  This attribute need only be present if the server 
  161.    supports LDAP strong or protected simple authentication. Otherwise if 
  162.    the server does not know the current time, or does not choose to present 
  163.    it to clients, this attribute need not be present. The client may wish to 
  164.    use this value to detect whether a strong or protected bind is failing 
  165.    because the client and server clocks are not sufficiently synchronized,
  166.    but clients must not use this time field for setting their own system 
  167.    clock.
  168.  
  169.    The definition of the attribute is:
  170.  
  171.     ( 1.3.6.1.4.1.1466.101.120.2 NAME 'currentTime'
  172.       SYNTAX 'GeneralizedTime' SINGLE-VALUE USAGE dSAOperation )
  173.  
  174.  
  175.  
  176. INTERNET-DRAFT                                                March 1997
  177.  
  178. 7.2. Validating the Name of the Server
  179.  
  180.    A server which accepts binds with the X.511-Strong mechanism must have
  181.    a Distinguished Name, which preferably should uniquely identify it.
  182.  
  183.    A client may check that the Distinguished Name which it has for a server
  184.    matches that which the server is expecting by reading the 
  185.    serverName;binary attribute from the servers' root DSE.
  186.  
  187.    This attribute's value is the server's Distinguished Name.  The 
  188.    attribute will likely be absent if the server does not accept strong 
  189.    authentication using X.511-Strong.  However, the presence of this 
  190.    attribute does not guarantee that the server will be able to perform 
  191.    strong authentication.  
  192.  
  193.    If the server acts as a gateway to gateway to more than one X.500 DSA
  194.    capable of strong authentication, there may be multiple values of 
  195.    this attribute, one per DSA.
  196.    
  197.    (Note: this attribute is distinct from myAccessPoint, for it is not 
  198.    required that a server have a presentation address in order to perform 
  199.    strong authentication.)  
  200.  
  201.    It is likely that clients will retrieve this attribute in binary. 
  202.    If all attributes of the root DSE are requested, servers must return
  203.    the attribute values in binary.  The binary value is the octets of a 
  204.    DER-encoded value of an X.501 DistinguishedName type, e.g. the first 
  205.    byte is a SEQUENCE tag, and so on.
  206.  
  207.    Client implementors should be aware that values returned by the 
  208.    server may be modified in transit.
  209.  
  210.    The definition of this attribute is:
  211.  
  212.     ( 1.3.6.1.4.1.1466.101.120.3 NAME 'serverName'  
  213.      SYNTAX 'DN' USAGE dSAOperation )
  214.  
  215. 7.3. Obtaining the Certification Path of the Server
  216.  
  217.    A server which accepts binds with the X.511-Strong mechanism may have 
  218.    certification paths, and this information may be of use to the client 
  219.    in determining a common point of trust.
  220.  
  221.    A client may retrieve a server's certification paths by reading the 
  222.    certificationPath;binary attribute from the server's root DSE.
  223.  
  224.    An attribute value contains a binary DER encoding data type, which is the 
  225.    certificate path for a server.  If the server does not have a certificate
  226.    path this attribute must be absent.  
  227.  
  228.    Clients must only retrieve this attribute in binary. If all attributes of 
  229.    the root DSE are requested, servers must return the attribute values in 
  230.    binary.  The binary value is the octets of a DER-encoded value of an X.509
  231.    CertificationPath type, e.g. the first byte is a SEQUENCE tag, and so on.
  232.  
  233.    The definition of this attribute is:
  234.  
  235.     ( 1.3.6.1.4.1.1466.101.120.4 NAME 'certificationPath'
  236.      SYNTAX 'CertificatePath' USAGE dSAOperation )
  237.  
  238. 7.4. Determining Supported Algorithms
  239.  
  240.    The server may list the names of algorithms it supports for use in 
  241.    these mechanisms in the supportedAlgorithms attribute of the root DSE.
  242.  
  243.     ( 2.5.4.52 NAME 'supportedAlgorithms' SYNTAX 'SupportedAlgorithm' )
  244.  
  245. 8. Security Considerations
  246.    
  247.    These algorithms are designed to be used for authentication where
  248.    the underlying transport service cannot guarantee confidentiality.
  249.  
  250.    It should be noted that the name field of the BindRequest is not protected 
  251.    against modification in the "X.511-Protected" mechanism.
  252.  
  253.    These mechanisms do not provide for confidentiality of any data 
  254.    transferred between the client and the server, except for the password
  255.    in the "X.511-Protected" mechanism.  These mechanisms do not prevent 
  256.    an authenticated association from being hijacked.
  257.  
  258. 8. Acknowledgements
  259.  
  260.    Design ideas included in this document are based on those from ITU
  261.    and ISO, and the IETF ASID Working Groups.  The contributions of
  262.    individuals in these working groups is gratefully acknowledged.
  263.  
  264. 9.  Bibliography
  265.  
  266.    [1] J. Meyers, "Simple Authentication and Security Layer",
  267.         INTERNET-DRAFT <draft-myers-auth-sasl-04.txt>, July 1996.
  268.  
  269.    [2] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol 
  270.        (v3)", INTERNET-DRAFT <draft-ietf-asid-ldapv3-protocol-04.txt>, 
  271.        February 1997.
  272.  
  273.    [3] ITU-T Rec. X.509, "The Directory: Authentication Framework",
  274.         1993.
  275.  
  276.    [4] ITU-T Rec. X.511, "The Directory: Abstract Service Definition", 1993.
  277.  
  278. 10.  Authors' Address
  279.  
  280.        Mark Wahl
  281.        Critical Angle Inc.
  282.        4815 W Braker Lane #502-385
  283.        Austin, TX 78759
  284.        USA
  285.  
  286.        EMail:  M.Wahl@critical-angle.com
  287.  
  288.  
  289.