From 72e2d531438a7b185d9395afb40a1e6e1acda71f Mon Sep 17 00:00:00 2001 From: Kurt Zeilenga Date: Mon, 22 Nov 1999 01:20:49 +0000 Subject: [PATCH] rev 5 --- doc/drafts/draft-good-ldap-ldif-xx.txt | 609 +++++++++++++++------- doc/drafts/draft-leach-digest-sasl-xx.txt | 494 ++++++++++-------- 2 files changed, 693 insertions(+), 410 deletions(-) diff --git a/doc/drafts/draft-good-ldap-ldif-xx.txt b/doc/drafts/draft-good-ldap-ldif-xx.txt index 56654338ee..86d5589c90 100644 --- a/doc/drafts/draft-good-ldap-ldif-xx.txt +++ b/doc/drafts/draft-good-ldap-ldif-xx.txt @@ -1,12 +1,9 @@ - - - LDAP Data Interchange Format (LDIF) Gordon Good INTERNET-DRAFT Netscape Communications - 22 February 1999 +Status: Standards-Track 19 October 1999 The LDAP Data Interchange Format (LDIF) - Technical Specification - Filename: draft-good-ldap-ldif-03.txt + Filename: draft-good-ldap-ldif-05.txt Status of this Memo @@ -27,7 +24,7 @@ Status of this Memo To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. - This Internet Draft expires August 22nd, 1999. + This Internet Draft expires 19 April, 2000. Abstract @@ -52,14 +49,14 @@ Background and Intended Usage -Good February 22, 1999 [Page 1] +Good October 18, 1999 [Page 1] -INTERNET-DRAFT LDAP Data Interchange Format 22 February 1999 +INTERNET-DRAFT LDAP Data Interchange Format 19 October 1999 of data import tools from legacy systems is facilitated. A fairly simple set of tools written in awk or perl can, for example, convert - a database of personnel information into an LDIF file. Thie file can + a database of personnel information into an LDIF file. This file can then be imported into a directory server, regardless of the internal database representation the target directory server uses. @@ -73,8 +70,8 @@ INTERNET-DRAFT LDAP Data Interchange Format 22 February 1999 The application/directory MIME content-type [1] is a general framework and format for conveying directory information, and is independent of any particular directory service. The LDIF format is - a simpler format which is perhaps easier to create, and also may also - be used, as noted, to describe a set of changes to be applied to a + a simpler format which is perhaps easier to create, and may also be + used, as noted, to describe a set of changes to be applied to a directory. The key words "MUST", "MAY", and "SHOULD" used in this document are @@ -92,9 +89,9 @@ Definition of the LDAP Data Interchange Format entry. An LDIF file specifies a set of directory entries, or a set of changes to be applied to directory entries, but not both. - There is a one-to-one correlation between LDAP operations which - modify the directory (add, delete, modify, and modrdn), and the types - of changerecords described below ("add", "delete", "modify", and + There is a one-to-one correlation between LDAP operations that modify + the directory (add, delete, modify, and modrdn), and the types of + changerecords described below ("add", "delete", "modify", and "modrdn" or "moddn"). This correspondence is intentional, and permits a straightforward translation from LDIF changerecords to protocol operations. @@ -102,84 +99,186 @@ Definition of the LDAP Data Interchange Format Formal Syntax Definition of LDIF The following definition uses the augmented Backus-Naur Form - specified in RFC 822 [2]. + specified in RFC 2234 [2]. + + ldif-file = ldif-content / ldif-changes + + + +Good October 18, 1999 [Page 2] + +INTERNET-DRAFT LDAP Data Interchange Format 19 October 1999 + + + ldif-content = version-spec 1*(1*SEP ldif-attrval-record) + + ldif-changes = version-spec 1*(1*SEP ldif-change-record) + + ldif-attrval-record = dn-spec SEP 1*attrval-spec + + ldif-change-record = dn-spec SEP *control changerecord + + version-spec = "version:" FILL version-number + + version-number = 1*DIGIT + ; version-number MUST be "1" for the + ; LDIF format described in this document. + + dn-spec = "dn:" (FILL distinguishedName / + ":" FILL base64-distinguishedName) + + distinguishedName = SAFE-UTF8-STRING + ; a distinguished name, as defined in [3] + + base64-distinguishedName = BASE64-UTF8-STRING + ; a distinguishedName which has been base64 + ; encoded (see note 10, below) + + rdn = SAFE-UTF8-STRING + ; a relative distinguished name, defined as + ; in [3] + + base64-rdn = BASE64-UTF8-STRING + ; an rdn which has been base64 encoded (see + ; note 10, below) + + control = "control:" FILL ldap-oid ; controlType + 0*1(1*SPACE ("true" / "false")) ; criticality + 0*1(value-spec) ; controlValue + SEP + ; (See note 9, below) + + ldap-oid = 1*DIGIT 0*1("." 1*DIGIT) + ; An LDAPOID, as defined in [4] + + attrval-spec = AttributeDescription value-spec SEP + + value-spec = ":" ( FILL 0*1(SAFE-STRING) / + ":" FILL (BASE64-STRING) / + "<" FILL url) + ; See notes 7 and 8, below + + - ldif-file = ldif-content / ldif-changes +Good October 18, 1999 [Page 3] + +INTERNET-DRAFT LDAP Data Interchange Format 19 October 1999 + + + url = + ; (See Note 6, below) + + AttributeDescription = AttributeType [";" options] + ; Definition taken from [4] + + AttributeType = ldap-oid / (ALPHA *(attr-type-chars)) + + options = option / (option ";" options) + + option = 1*opt-char + + attr-type-chars = ALPHA / DIGIT / "-" + + opt-char = attr-type-chars + + changerecord = "changetype:" FILL + (change-add / change-delete / + change-modify / change-moddn) + + change-add = "add" SEP 1*attrval-spec + + change-delete = "delete" SEP + + change-moddn = ("modrdn" / "moddn") SEP + "newrdn:" ( FILL rdn / + ":" FILL base64-rdn) SEP + "deleteoldrdn:" FILL ("0" / "1") SEP + 0*1("newsuperior:" + ( FILL distinguishedName / + ":" FILL base64-distinguishedName) SEP) + change-modify = "modify" SEP *mod-spec -Good February 22, 1999 [Page 2] + mod-spec = ("add:" / "delete:" / "replace:") + FILL AttributeDescription SEP + *attrval-spec + "-" SEP + + SPACE = %x20 + ; ASCII SP, space + + FILL = *SPACE + + SEP = (CR LF / LF) + + CR = %x0D + ; ASCII CR, carriage return + + + +Good October 18, 1999 [Page 4] -INTERNET-DRAFT LDAP Data Interchange Format 22 February 1999 - - - ldif-content = version-spec 1*SEP - ldif-attrval-record *(1*SEP ldif-attrval-record) - ldif-changes = version-spec 1*SEP - ldif-change-record *(1*SEP ldif-change-record) - ldif-attrval-record = dn-spec SEP 1*(attrval-spec SEP) - ldif-change-record = dn-spec SEP 1*(changerecord SEP) - - version-spec = "version:" *SPACE version-number - version-number = 1*DIGIT ; version-number MUST be "1" for the - ; LDIF format described in this document. - - dn-spec = ("dn:" *SPACE dn) / ("dn::" *SPACE base64-dn) - dn = - base64-dn = - rdn = - base64-rdn = - - attrval-spec = attribute-description ((":") / (":" *SPACE value) / - ("::" *SPACE base64-value) / - (":<" *SPACE url)) - url = - ; (See Note 6, below) - attribute-description = - value = 1*safe-initval *safe - ; (See Note 9, below) - safe = - safe-initval = - base64-value = - - changerecord = change-add / change-delete / change-modify / - change-moddn - change-add = "changetype:" *SPACE "add" 1*(SEP attrval-spec) - change-delete = "changetype:" *SPACE "delete" - change-moddn = "changetype:" *SPACE ("modrdn" / "moddn") SEP - ("newrdn:" *SPACE rdn / - "newrdn::" *SPACE base-64-rdn) SEP - "deleteoldrdn:" *SPACE ("0" / "1") - 0,1*(SEP (("newsuperior:" *SPACE dn) / - ("newsuperior::" *SPACE base-64-dn))) - change-modify = "changetype:" *SPACE "modify" 1*(SEP mod-spec) - mod-spec = mod-add-spec / mod-delete-spec / mod-replace-spec - - - -Good February 22, 1999 [Page 3] +INTERNET-DRAFT LDAP Data Interchange Format 19 October 1999 + + + LF = %x0A + ; ASCII LF, line feed + + ALPHA = %x41-5A / %x61-7A + ; A-Z / a-z + + DIGIT = %x30-39 + ; 0-9 + + UTF8-1 = %x80-BF + + UTF8-2 = %xC0-DF UTF8-1 + + UTF8-3 = %xE0-EF 2UTF8-1 + + UTF8-4 = %xF0-F7 3UTF8-1 + + UTF8-5 = %xF8-FB 4UTF8-1 + + UTF8-6 = %xFC-FD 5UTF8-1 + + SAFE-CHAR = %x01-09 / %x0B-0C / %x0E-7F + ; any value <= 127 decimal except NUL, LF, and CR + + SAFE-INIT-CHAR = %x01-09 / %x0B-0C / %x0E-1F / + %x21-39 / %x3B / %x3D-7F + ; any value <= 127 except NUL, LF, CR, + ; SPACE, colon (":", ASCII 58 decimal) + ; and less-than ("<" , ASCII 60 decimal) + + SAFE-STRING = [SAFE-INIT-CHAR *SAFE-CHAR] + + SAFE-UTF8-CHAR = SAFE-CHAR / UTF8-2 / UTF8-3 / + UTF8-4 / UTF8-5 / UTF8-6 + + SAFE-INIT-UTF8-CHAR = SAFE-INIT-CHAR / UTF8-2 / UTF8-3 / + UTF8-4 / UTF8-5 / UTF8-6 + + SAFE-UTF8-STRING = [SAFE-INIT-UTF8-CHAR *SAFE-UTF8-CHAR] + + BASE64-UTF8-STRING = BASE64-STRING + ; MUST be the base64 encoding of a valid + ; string of UTF-8 characters + + BASE64-CHAR = %x2B / %x2F / %x30-39 / %x3D / %x41-5A / %x61-7A + ; +, /, 0-9, =, A-Z, and a-z + ; as specified in [5] + + + + +Good October 18, 1999 [Page 5] -INTERNET-DRAFT LDAP Data Interchange Format 22 February 1999 +INTERNET-DRAFT LDAP Data Interchange Format 19 October 1999 - mod-add-spec = "add:" *SPACE attribute-description - 1*(SEP attrval-spec) SEP "-" - mod-delete-spec = "delete:" *SPACE attribute-description - *(SEP attrval-spec) SEP "-" - mod-replace-spec = "replace:" *SPACE attribute-description - *(SEP attrval-spec) SEP "-" - SPACE = - SEP = (CR LF / LF) - CR = - LF = - DIGIT = + BASE64-STRING = [*(BASE64-CHAR)] Notes on LDIF Syntax @@ -189,23 +288,32 @@ INTERNET-DRAFT LDAP Data Interchange Format 22 February 1999 choose to interpret the contents as an older LDIF file format, supported by the University of Michigan ldap-3.3 implementation [8]. - 2) Any line, including comment lines, in an LDIF file MAY be wrapped - by inserting a line separator (SEP) and a SPACE. Any line which - begins with a single space MUST be treated as a continuation of the - previous line. When joining folded lines, exactly one space character - at the beginning of each continued line must be discarded. - - 3) Any line which begins with a pound-sign ("#", ASCII 35) is a + 2) Any non-empty line, including comment lines, in an LDIF file MAY + be folded by inserting a line separator (SEP) and a SPACE. Folding + MUST NOT occur before the first character of the line. In other + words, folding a line into two lines, the first of which is empty, is + not permitted. Any line that begins with a single space MUST be + treated as a continuation of the previous (non-empty) line. When + joining folded lines, exactly one space character at the beginning of + each continued line must be discarded. Implementations SHOULD NOT + fold lines in the middle of a multi-byte UTF-8 character. + + 3) Any line that begins with a pound-sign ("#", ASCII 35) is a comment line, and MUST be ignored when parsing an LDIF file. - 4) Any dn or value which contains characters other than those defined - as "safe", or begins with a character other than those defined as - "safe-initval", above, MUST be base-64 encoded. Other values MAY be - base-64 encoded. + 4) Any dn or rdn that contains characters other than those defined as + "SAFE-UTF8-CHAR", or begins with a character other than those defined + as "SAFE-INIT-UTF8-CHAR", above, MUST be base-64 encoded. Other + values MAY be base-64 encoded. Any value that contains characters + other than those defined as "SAFE-CHAR", or begins with a character + other than those defined as "SAFE-INIT-CHAR", above, MUST be base-64 + encoded. Other values MAY be base-64 encoded. - 5) To represent a zero-length attribute value, use an attrval-spec of - "attribute-description:". For example, "seeAlso:" represents a - zero-length "seeAlso" attribute value. + 5) When a zero-length attribute value is to be included directly in + an LDIF file, it MUST be represented as AttributeDescription ":" FILL + SEP. For example, "seeAlso:" followed by a newline represents a + zero-length "seeAlso" attribute value. It is also permissible for + the value referred to by a URL to be of zero length. 6) When a URL is specified in an attrval-spec, the following conventions apply: @@ -216,28 +324,41 @@ INTERNET-DRAFT LDAP Data Interchange Format 22 February 1999 associated with each supported URL will be documented in an associated Applicability Statement. - 7) While it is permissible for character values larger than 126 to be + 7) Distinguished names, relative distinguished names, and attribute + values of DirectoryString syntax MUST be valid UTF-8 strings. -Good February 22, 1999 [Page 4] +Good October 18, 1999 [Page 6] -INTERNET-DRAFT LDAP Data Interchange Format 22 February 1999 - - - contained in an attribute value, implementations SHOULD base-64 - encode any value which contains such characters when generating LDIF. - However, implementations MAY leave the values unencoded. This - relaxation is designed to allow editing of LDIF files containing - UTF-8 data. - - 8) Attribute values contained in LDIF files represent directory data, - and therefore MUST be valid UTF-8 strings. Implementations which read - LDIF MAY interpret files in which the values are stored in some other - character set encoding, but implementations MUST NOT generate LDIF - content which does not contain valid UTF-8 data. - - 9) Values that end with SPACE SHOULD be base-64 encoded. +INTERNET-DRAFT LDAP Data Interchange Format 19 October 1999 + + + Implementations that read LDIF MAY interpret files in which these + entities are stored in some other character set encoding, but + implementations MUST NOT generate LDIF content which does not contain + valid UTF-8 data. + + 8) Values or distinguished names that end with SPACE SHOULD be base- + 64 encoded. + + 9) When controls are included in an LDIF file, implementations MAY + choose to ignore some or all of them. This may be necessary if the + changes described in the LDIF file are being sent on an LDAPv2 + connection (LDAPv2 does not support controls), or the particular + controls are not supported by the remote server. If the criticality + of a control is "true", then the implementation MUST either include + the control, or MUST NOT send the operation to a remote server. + + 10) When an attrval-spec, distinguishedName, or rdn is base64- + encoded, the encoding rules specified in [5] are used with the + following exceptions: a) The requirement that base64 output streams + must be represented as lines of no more than 76 characters is + removed. Lines in LDIF files may only be folded according to the + folding rules described in note 2, above. b) Base64 strings in [5] + may contain characters other than those defined in BASE64-CHAR, and + are ignored. LDIF does not permit any extraneous characters, other + than those used for line folding. Examples of LDAP Data Interchange Format @@ -261,6 +382,14 @@ Examples of LDAP Data Interchange Format objectclass: top objectclass: person objectclass: organizationalPerson + + + +Good October 18, 1999 [Page 7] + +INTERNET-DRAFT LDAP Data Interchange Format 19 October 1999 + + cn: Bjorn Jensen sn: Jensen telephonenumber: +1 408 555 1212 @@ -273,21 +402,13 @@ Examples of LDAP Data Interchange Format objectclass:person objectclass:organizationalPerson cn:Barbara Jensen - - - -Good February 22, 1999 [Page 5] - -INTERNET-DRAFT LDAP Data Interchange Format 22 February 1999 - - cn:Barbara J Jensen cn:Babs Jensen sn:Jensen uid:bjensen telephonenumber:+1 408 555 1212 - description:Babs is a big sailing fan, and travels extensively in search of - perfect sailing conditions. + description:Babs is a big sailing fan, and travels extensively in sea + rch of perfect sailing conditions. title:Product Manager, Rod and Reel Division Example 3: A file containing a base-64-encoded value @@ -317,6 +438,14 @@ INTERNET-DRAFT LDAP Data Interchange Format 22 February 1999 objectclass: organizationalUnit ou:: 5Za25qWt6YOo # ou:: + + + +Good October 18, 1999 [Page 8] + +INTERNET-DRAFT LDAP Data Interchange Format 19 October 1999 + + ou;lang-ja:: 5Za25qWt6YOo # ou;lang-ja:: ou;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2 @@ -329,14 +458,6 @@ INTERNET-DRAFT LDAP Data Interchange Format 22 February 1999 userpassword: {SHA}O3HSv1MusyL4kTjP+HKI5uxuNoM= objectclass: top objectclass: person - - - -Good February 22, 1999 [Page 6] - -INTERNET-DRAFT LDAP Data Interchange Format 22 February 1999 - - objectclass: organizationalPerson objectclass: inetOrgPerson uid: rogasawara @@ -374,6 +495,13 @@ INTERNET-DRAFT LDAP Data Interchange Format 22 February 1999 Example 5: A file containing a reference to an external file + + +Good October 18, 1999 [Page 9] + +INTERNET-DRAFT LDAP Data Interchange Format 19 October 1999 + + version: 1 dn: cn=Horatio Jensen, ou=Product Testing, dc=airius, dc=com objectclass: top @@ -386,13 +514,6 @@ INTERNET-DRAFT LDAP Data Interchange Format 22 February 1999 telephonenumber: +1 408 555 1212 jpegphoto:< file:///usr/local/directory/photos/hjensen.jpg - - -Good February 22, 1999 [Page 7] - -INTERNET-DRAFT LDAP Data Interchange Format 22 February 1999 - - Example 6: A file containing a series of change records and comments version: 1 @@ -429,6 +550,14 @@ INTERNET-DRAFT LDAP Data Interchange Format 22 February 1999 # Modify an entry: add an additional value to the postaladdress attribute, # completely delete the description attribute, replace the telephonenumber # attribute with two values, and delete a specific value from the + + + +Good October 18, 1999 [Page 10] + +INTERNET-DRAFT LDAP Data Interchange Format 19 October 1999 + + # facsimiletelephonenumber attribute dn: cn=Paula Jensen, ou=Product Development, dc=airius, dc=com changetype: modify @@ -441,18 +570,32 @@ INTERNET-DRAFT LDAP Data Interchange Format 22 February 1999 telephonenumber: +1 408 555 1234 telephonenumber: +1 408 555 5678 - - - - -Good February 22, 1999 [Page 8] - -INTERNET-DRAFT LDAP Data Interchange Format 22 February 1999 - - delete: facsimiletelephonenumber facsimiletelephonenumber: +1 408 555 9876 - + # Modify an entry: replace the postaladdress attribute with an empty + # set of values (which will cause the attribute to be removed), and + # delete the entire description attribute. Note that the first will + # always succeed, while the second will only succeed if at least + # one value for the description attribute is present. + dn: cn=Ingrid Jensen, ou=Product Support, dc=airius, dc=com + changetype: modify + replace: postaladdress + - + delete: description + - + + Example 7: An LDIF file containing a change record with a control + version: 1 + # Delete an entry. The operation will attach the LDAPv3 + # Tree Delete Control defined in [9]. The criticality + # field is "true" and the controlValue field is + # absent, as required by [9]. + dn: ou=Product Development, dc=airius, dc=com + control: 1.2.840.113556.1.4.805 true + changetype: delete + Security Considerations @@ -463,6 +606,14 @@ Security Considerations Since ":<" directives can cause external content to be included when processing an LDIF file, one should be cautious of accepting LDIF + + + +Good October 18, 1999 [Page 11] + +INTERNET-DRAFT LDAP Data Interchange Format 19 October 1999 + + files from external sources. A "trojan" LDIF file could name a file with sensitive contents and cause it to be included in a directory entry, which a hostile entity could read via LDAP. @@ -497,14 +648,6 @@ Appendix A: Differences from previous versions of this document ldif-02.txt 1) The BNF has been modified such that a simple attribute name - - - -Good February 22, 1999 [Page 9] - -INTERNET-DRAFT LDAP Data Interchange Format 22 February 1999 - - ("attrname") has been replaced with an "attribute-description" as defined in the LDAPv3 protocol document [4]. This permits language codes and other attribute options to be carried in an LDIF file. @@ -520,9 +663,16 @@ INTERNET-DRAFT LDAP Data Interchange Format 22 February 1999 Differences between draft-ietf-asid-ldif-02.txt and draft-good-ldap- ldif-00.txt + + +Good October 18, 1999 [Page 12] + +INTERNET-DRAFT LDAP Data Interchange Format 19 October 1999 + + 1) The "charset-option" and "charset-name" productions were removed from the BNF, due to objections within the working group. UTF-8 is - the only character set which may be used in LDIF. + the only character set that may be used in LDIF. 2) Examples were reworked to reflect the above change, and to include an example of a non-western language represented in UTF-8. @@ -532,9 +682,9 @@ INTERNET-DRAFT LDAP Data Interchange Format 22 February 1999 1) Added version identifiers to the examples - they were missing. - 2) Clarified that LDIF file must use UTF-8. + 2) Clarified that LDIF files must use UTF-8. - Differences between draft-ietf-good-ldif-01.txt and draft-good-ldap- + Differences between draft-good-ldap-ldif-01.txt and draft-good-ldap- ldif-02.txt 1) Added a recommendation that values ending in SPACE should be @@ -544,7 +694,7 @@ INTERNET-DRAFT LDAP Data Interchange Format 22 February 1999 3) Updated header to reflect new IETF I-D guidelines. - Differences between draft-ietf-good-ldif-02.txt and draft-good-ldap- + Differences between draft-good-ldap-ldif-02.txt and draft-good-ldap- ldif-03.txt 1) Fixed reference from RFC 1779 to RFC 2253. @@ -554,13 +704,6 @@ INTERNET-DRAFT LDAP Data Interchange Format 22 February 1999 3) Comment lines may be folded (this is now explicitly mentioned in note 2). - - -Good February 22, 1999 [Page 10] - -INTERNET-DRAFT LDAP Data Interchange Format 22 February 1999 - - 4) Moved this section (differences between draft versions) to an appendix. @@ -569,6 +712,87 @@ INTERNET-DRAFT LDAP Data Interchange Format 22 February 1999 6) Cleaned up references section. + Differences between draft-good-ldap-ldif-03.txt and draft-good-ldap- + ldif-04.txt + + 1) The grammar now requires that an LDIF file end with one or more + SEP sequences (newlines). This was inadvertently prohibited in + earlier revisions of the grammar. + + + +Good October 18, 1999 [Page 13] + +INTERNET-DRAFT LDAP Data Interchange Format 19 October 1999 + + + 2) Several minor spelling and typographical errors were fixed. + + 3) Reworked the grammar to make it more readable. Hallvard Furuseth + (University of Oslo) provided the new BNF. + + 4) Excluded NUL from "safe" production. + + 5) Changed "0,1*xxx" "0*1xxx" in compliance with RFC822. + + 6) Fixed a glitch in the grammar that allowed multiple changetypes + within a single LDIF change record. The intent is that only one + changetype per change record is permitted. + + 7) Fixed a mistake in example 2 (folded attribute value). + + 8) The BNF now explicitly requires that zero-length attribute values + be encoded as attribute-description ":" FILL SEP. + + 9) Factored "changetype: FILL" out of the productions for change-add, + change-delete, change-moddn, and change-modify. + + 10) RFC 2251 permits an LDAP modify operation with no modifications, + and also permits an attribute with no values. Although it's unclear + what the purpose of these constructs might be, I altered the BNF to + allow these to be described in LDIF. + + 11) The BNF may now carry LDAP v3 controls in ldif-change-records. + The "value-spec" production was factored out to allow it to be used + in the definition of a control. + + 12) Clarified the rules for line-folding to prohibit a line from + being folded into two lines, the first of which is empty. This + guarantees that the sequence SEP SEP terminates an LDIF record, and + allows, for example, "perl -n00" to be used to read an entire LDIF + record into the $_ variable. + + Differences between draft-good-ldap-ldif-04.txt and draft-good-ldap- + ldif-05.txt + + 1) The grammar has been rewritten to use the RFC2234 ABNF, replacing + the RFC822 ABNF. + + 2) The grammar makes fewer uses of . + + 3) DNs, RDNs, and attribute values with DirectoryString are now + explicitly called out as UTF-8 strings. + + 4) An error in the BNF for "control" was fixed. + + + +Good October 18, 1999 [Page 14] + +INTERNET-DRAFT LDAP Data Interchange Format 19 October 1999 + + + 5) An additional ldif-change-record was added to example 6. + + 6) Since RFC 1521 defines base-64 encoding with different folding + rules, and permits illegal characters (which should be ignored), an + explanatory note has been added. This note explains that lines must + be folded according to LDIF rules, not RFC 1521 rules, and that + extraneous characters are not permitted. + + 7) DNs, values, and rdns containing octets > 127 must be base-64 + encoded. + Acknowledgments @@ -578,6 +802,10 @@ Acknowledgments supported by the National Science Foundation under Grant No. NCR- 9416667. + Members of the IETF LDAP Extensions Working group provided many + helpful suggestions. In particular, Hallvard B. Furuseth of the + University of Oslo made many significant contributions to this + document, including a thorough review and rewrite of the BNF. References @@ -586,9 +814,9 @@ References mation", RFC 2425, September 1998, - [2] Crocker, D.H., "Standard for the Format of ARPA Internet Text - Messages", RFC 822, August 1982, - + [2] Crocker, D., Overell, P., "Augmented BNF for Syntax Specifica- + tions: ABNF" , RFC 2234, November 1997, + [3] Wahl, M., Kille, S., Howes, T., "A String Representation of Dis- tinguished Names", RFC 2253, @@ -602,21 +830,21 @@ References Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", section 5.2, "Base64 Content-Transfer-Encoding", RFC 1521, December 1993, - - [6] T. Berners-Lee, L. Masinter, M. McCahill, "Uniform Resource - Locators (URL)", RFC 1738, December 1994, - - [7] S. Bradner, "Key Words for use in RFCs to Indicate Requirement +Good October 18, 1999 [Page 15] + +INTERNET-DRAFT LDAP Data Interchange Format 19 October 1999 -Good February 22, 1999 [Page 11] - -INTERNET-DRAFT LDAP Data Interchange Format 22 February 1999 + + [6] T. Berners-Lee, L. Masinter, M. McCahill, "Uniform Resource + Locators (URL)", RFC 1738, December 1994, + + [7] S. Bradner, "Key Words for use in RFCs to Indicate Requirement Levels", Harvard University, RFC 2119, March 1997, @@ -624,6 +852,11 @@ INTERNET-DRAFT LDAP Data Interchange Format 22 February 1999 gan, April 1996. + [9] M. P. Armijo, "Tree Delete Control", Microsoft Corporation, + INTERNET-DRAFT June 1999, + + Author's Address @@ -636,7 +869,7 @@ Author's Address Phone: +1 650 937-3825 EMail: ggood@netscape.com - This Internet Draft expires August 22nd, 1999. + This Internet Draft expires 19 April, 2000. @@ -656,17 +889,5 @@ Author's Address - - - - - - - - - - - - -Good February 22, 1999 [Page 12] - +Good October 18, 1999 [Page 16] + \ No newline at end of file diff --git a/doc/drafts/draft-leach-digest-sasl-xx.txt b/doc/drafts/draft-leach-digest-sasl-xx.txt index 0a8b50b007..863aee0f84 100644 --- a/doc/drafts/draft-leach-digest-sasl-xx.txt +++ b/doc/drafts/draft-leach-digest-sasl-xx.txt @@ -1,19 +1,19 @@ - Digest SASL Mechanism September, 1999 + Digest SASL Mechanism September, 1999 Network Working Group Paul J. Leach, Microsoft INTERNET-DRAFT Chris Newman, Innosoft -draft-leach-digest-sasl-04.txt +draft-leach-digest-sasl-05.txt Category: Standards Track -Expires March 27, 2000 September 27, 1999 +Expires April 21, 2000 October 21, 1999 Using Digest Authentication as a SASL Mechanism - Author's draft: 15 + Author's draft: 16 @@ -80,13 +80,13 @@ Table of Contents 2.1.3 Step Three...................................................12 - 2.2 SUBSEQUENT AUTHENTICATION........................................12 + 2.2 SUBSEQUENT AUTHENTICATION........................................13 2.2.1 Step one.....................................................13 2.2.2 Step Two.....................................................13 - 2.3 INTEGRITY PROTECTION.............................................13 + 2.3 INTEGRITY PROTECTION.............................................14 2.4 CONFIDENTIALITY PROTECTION.......................................14 @@ -101,7 +101,7 @@ Table of Contents 3.5 OFFLINE DICTIONARY ATTACKS.......................................16 - 3.6 MAN IN THE MIDDLE................................................16 + 3.6 MAN IN THE MIDDLE................................................17 3.7 CHOSEN PLAINTEXT ATTACKS.........................................17 @@ -126,18 +126,18 @@ Leach, Newman Standards Track [Page 2] 4 EXAMPLE............................................................18 -5 REFERENCES.........................................................19 +5 REFERENCES.........................................................20 -6 AUTHORS' ADDRESSES.................................................20 +6 AUTHORS' ADDRESSES.................................................21 7 ABNF...............................................................21 - 7.1 AUGMENTED BNF....................................................21 + 7.1 AUGMENTED BNF....................................................22 - 7.2 BASIC RULES......................................................22 + 7.2 BASIC RULES......................................................23 -8 SAMPLE CODE........................................................24 +8 SAMPLE CODE........................................................25 -9 FULL COPYRIGHT STATEMENT...........................................25 +9 FULL COPYRIGHT STATEMENT...........................................26 @@ -284,13 +284,13 @@ nonce digest-challenge is sent as part of initial authentication. It is recommended that this string be base64 or hexadecimal data. Note that since the string is passed as a quoted string, the double-quote - character is not allowed. The contents of the nonce are - implementation dependent. The security of the implementation depends - on a good choice. It is RECOMMENDED that it contain at least 64 bits - of entropy. The nonce is opaque to the client. This directive is - required and MUST appear exactly once; if not present, or if multiple - instances are present, the client should abort the authentication - exchange. + character is not allowed unless escaped (see section 7.2). The + contents of the nonce are implementation dependent. The security of + the implementation depends on a good choice. It is RECOMMENDED that + it contain at least 64 bits of entropy. The nonce is opaque to the + client. This directive is required and MUST appear exactly once; if + not present, or if multiple instances are present, the client should + abort the authentication exchange. @@ -314,7 +314,9 @@ qop-options stale The "stale" directive is not used in initial authentication. See the - next section for its use in subsequent authentications. + next section for its use in subsequent authentications. This + directive may appear at most once; if multiple instances are present, + the client should abort the authentication exchange. maxbuf A number indicating the size of the largest buffer the server is able @@ -346,9 +348,7 @@ cipher-opts implement. The client MUST ignore unrecognized options; if the client recognizes no option, it should abort the authentication exchange. - des - the Data Encryption Standard (DES) cipher [FIPS] in cipher block - chaining (CBC) mode with a 56 bit key. + @@ -361,6 +361,10 @@ Leach, Newman Standards Track [Page 6] + des + the Data Encryption Standard (DES) cipher [FIPS] in cipher block + chaining (CBC) mode with a 56 bit key. + 3des the "triple DES" cipher in CBC mode with EDE with the same key for each E stage (aka "two keys mode") for a total key length of 112 @@ -402,14 +406,10 @@ digest-response = 1#( username | realm | nonce | cnonce | nonce-count = "nc" "=" nc-value nc-value = 8LHEX qop = "qop" "=" qop-value - digest-uri = "digest-uri" "=" digest-uri-value + digest-uri = "digest-uri" "=" <"> digest-uri-value <"> digest-uri-value = serv-type "/" host [ "/" serv-name ] serv-type = 1*ALPHA host = 1*( ALPHA | DIGIT | "-" | "." ) - serv-name = host - response = "response" "=" <"> response-value <"> - response-value = 32LHEX - LHEX = "0" | "1" | "2" | "3" | @@ -421,19 +421,23 @@ Leach, Newman Standards Track [Page 7] + serv-name = host + response = "response" "=" response-value + response-value = 32LHEX + LHEX = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" | "a" | "b" | "c" | "d" | "e" | "f" cipher = "cipher" "=" cipher-value - authzid = "authzid" "=" authzid-value + authzid = "authzid" "=" <"> authzid-value <"> authzid-value = qdstr-val username - The user's name in the specified realm, encoded as UTF-8. This - directive is required and MUST be present exactly once; otherwise, - authentication fails. + The user's name in the specified realm, encoded according to the + value of the "charset" directive. This directive is required and MUST + be present exactly once; otherwise, authentication fails. realm The realm containing the user's account. This directive is required @@ -465,10 +469,6 @@ nonce-count The purpose of this directive is to allow the server to detect request replays by maintaining its own copy of this count - if the same nc-value is seen twice, then the request is a replay. See the - description below of the construction of the response value. - -qop - Indicates what "quality of protection" the client accepted. If @@ -480,6 +480,12 @@ Leach, Newman Standards Track [Page 8] + description below of the construction of the response value. This + directive may appear at most once; if multiple instances are present, + the client should abort the authentication exchange. + +qop + Indicates what "quality of protection" the client accepted. If present, it may appear exactly once and its value MUST be one of the alternatives in qop-options. If not present, it defaults to "auth". These values affect the computation of the response. Note that this @@ -522,12 +528,6 @@ digest-uri example above would have a "digest-uri" value of "smtp/mail3.example.com/example.com". - Servers SHOULD check that the supplied value is correct. This will - detect accidental connection to the incorrect server. It is also so - that clients will be trained to provide values that will work with - implementations that use a shared back-end authentication service - that can provide server authentication. - @@ -539,6 +539,12 @@ Leach, Newman Standards Track [Page 9] + Servers SHOULD check that the supplied value is correct. This will + detect accidental connection to the incorrect server. It is also so + that clients will be trained to provide values that will work with + implementations that use a shared back-end authentication service + that can provide server authentication. + The serv-type component should match the service being offered. The host component should match one of the host names of the host on which the service is running, or it's IP address. Servers SHOULD NOT @@ -547,6 +553,9 @@ Leach, Newman Standards Track [Page 9] is unavailable or unreliable. The serv-name component should match one of the service's configured service names. + This directive may appear at most once; if multiple instances are + present, the client should abort the authentication exchange. + Note: In the HTTP use of Digest authentication, the digest-uri is the URI (usually a URL) of the resource requested -- hence the name of the directive. @@ -579,15 +588,6 @@ cipher once if "auth-conf" is negotiated; if required and not present, authentication fails. -authzid - The "authorization ID" as per RFC 2222, encoded in UTF-8. This - directive is optional. If present, and the authenticating user has - sufficient privilege, and the server supports it, then after - authentication the server will use this identity for making all - accesses and access checks. If the client specifies it, and the - server does not support it, then the response-value will be - incorrect, and authentication will fail. - Leach, Newman Standards Track [Page 10] @@ -598,6 +598,15 @@ Leach, Newman Standards Track [Page 10] +authzid + The "authorization ID" as per RFC 2222, encoded in UTF-8. This + directive is optional. If present, and the authenticating user has + sufficient privilege, and the server supports it, then after + authentication the server will use this identity for making all + accesses and access checks. If the client specifies it, and the + server does not support it, then the response-value will be + incorrect, and authentication will fail. + The size of a digest-response MUST be less than 4096 bytes. @@ -608,9 +617,8 @@ how the value is computed. response-value = HEX( KD ( HEX(H(A1)), - { nonce-value, ":" nc-value, ":", - cnonce-value, ":", qop-value, ":", HEX(H(A2)) -})) + { nonce-value, ":" nc-value, ":", + cnonce-value, ":", qop-value, ":", HEX(H(A2)) })) If authzid is specified, then A1 is @@ -639,14 +647,6 @@ implementation of this conversion is in section 8. If the "qop" directive's value is "auth", then A2 is: - A2 = { "AUTHENTICATE:", digest-uri-value } - -If the "qop" value is "auth-int" or "auth-conf" then A2 is: - - A2 = { "AUTHENTICATE:", digest-uri-value, - ":00000000000000000000000000000000" } - - @@ -658,6 +658,13 @@ Leach, Newman Standards Track [Page 11] + A2 = { "AUTHENTICATE:", digest-uri-value } + +If the "qop" value is "auth-int" or "auth-conf" then A2 is: + + A2 = { "AUTHENTICATE:", digest-uri-value, + ":00000000000000000000000000000000" } + Note that "AUTHENTICATE:" must be in upper case, and the second string constant is a string with a colon followed by 32 zeros. @@ -687,26 +694,19 @@ the nonce-count. It sends a message formatted as follows: where response-value is calculated as above, using the values sent in step two, except that if qop is "auth", then A2 is - A2 = { ":", digest-uri-value } + A2 = { ":", digest-uri-value } And if qop is "auth-int" or "auth-conf" then A2 is - A2 = { ":", digest-uri-value, ":00000000000000000000000000000000" - } + A2 = { ":", digest-uri-value, ":00000000000000000000000000000000" } Compared to its use in HTTP, the following Digest directives in the "digest-response" are unused: - nextnonce - qop - cnonce - nonce-count - -2.2 Subsequent Authentication -If the client has previously authenticated to the server, and remembers -the values of username, realm, nonce, nonce-count, cnonce, and qop that -it used in that authentication, and the SASL profile for a protocol + + + @@ -719,6 +719,16 @@ Leach, Newman Standards Track [Page 12] + nextnonce + qop + cnonce + nonce-count + +2.2 Subsequent Authentication + +If the client has previously authenticated to the server, and remembers +the values of username, realm, nonce, nonce-count, cnonce, and qop that +it used in that authentication, and the SASL profile for a protocol permits an initial client response, then it MAY perform "subsequent authentication", as defined in this section. @@ -758,17 +768,7 @@ previous response; otherwise, the client must solicit the password anew from the user. This permits the server to make sure that the user has presented their password recently. (The directive name refers to the previous nonce being stale, not to the last use of the password.) Except -for the handling of "stale", after sending the "digest-challenge" -authentication proceeds as in the case of initial authentication. - -2.3 Integrity Protection -If the server offered "qop=auth-int" and the client responded "qop=auth- -int", then subsequent messages, up to but not including the next -subsequent authentication, between the client and the server MUST be -integrity protected. Using as a base session key the value of H(A1) as -defined above the client and server calculate a pair of message -integrity keys as follows. @@ -780,6 +780,18 @@ Leach, Newman Standards Track [Page 13] +for the handling of "stale", after sending the "digest-challenge" +authentication proceeds as in the case of initial authentication. + +2.3 Integrity Protection + +If the server offered "qop=auth-int" and the client responded "qop=auth- +int", then subsequent messages, up to but not including the next +subsequent authentication, between the client and the server MUST be +integrity protected. Using as a base session key the value of H(A1) as +defined above the client and server calculate a pair of message +integrity keys as follows. + The key for integrity protecting messages from client to server is: Kic = MD5({H(A1), @@ -818,18 +830,6 @@ The key for confidentiality protecting messages from client to server is: Kcc = MD5({H(A1)[0..n], -"Digest H(A1) to client-to-server sealing key magic constant"}) - -The key for confidentiality protecting messages from server to client -is: - -Kcs = MD5({H(A1)[0..n], -"Digest H(A1) to server-to-client sealing key magic constant"}) - -where MD5 is as specified in [RFC 1321]. For cipher "rc4-40" n is 5; for -"rc4-56" n is 7; for the rest n is 16. The key for the "rc-*" ciphers is -all 16 bytes of Kcc or Kcs; the key for "des" is the first 7 bytes; the - @@ -841,6 +841,17 @@ Leach, Newman Standards Track [Page 14] +"Digest H(A1) to client-to-server sealing key magic constant"}) + +The key for confidentiality protecting messages from server to client +is: + +Kcs = MD5({H(A1)[0..n], +"Digest H(A1) to server-to-client sealing key magic constant"}) + +where MD5 is as specified in [RFC 1321]. For cipher "rc4-40" n is 5; for +"rc4-56" n is 7; for the rest n is 16. The key for the "rc-*" ciphers is +all 16 bytes of Kcc or Kcs; the key for "des" is the first 7 bytes; the key for "3des" is the first 14 bytes. The IV for "des" and "3des" is the last 8 bytes of Kcc or Kcs. @@ -859,7 +870,7 @@ along with the message. SEAL(Ki, Kc, SeqNum, msg) = {CIPHER(Kc, {msg, pad, HMAC(Ki, {SeqNum, msg})[0..9])}), 0x0001, - SeqNum} + SeqNum} where CIPHER is the chosen cipher, Ki and Kc are Kic and Kcc for messages sent by the client and Kis and Kcs for those sent by the @@ -880,17 +891,6 @@ mechanism, when compared to public key based mechanisms, for example. However, since it prevents chosen plaintext attacks, it is stronger than (e.g.) CRAM-MD5, which has been proposed for use with LDAP [10], POP and IMAP (see RFC 2195 [9]). It is intended to replace the much weaker and -even more dangerous use of plaintext passwords; however, since it is -still a password based mechanism it avoids some of the potential -deployabilty issues with public-key, OTP or similar mechanisms. - -Digest Authentication offers no confidentiality protection beyond -protecting the actual password. All of the rest of the challenge -and response are available to an eavesdropper, including the -user's name and authentication realm. - - - @@ -902,6 +902,15 @@ Leach, Newman Standards Track [Page 15] +even more dangerous use of plaintext passwords; however, since it is +still a password based mechanism it avoids some of the potential +deployabilty issues with public-key, OTP or similar mechanisms. + +Digest Authentication offers no confidentiality protection beyond +protecting the actual password. All of the rest of the challenge +and response are available to an eavesdropper, including the +user's name and authentication realm. + 3.2 Comparison of Digest with Plaintext Passwords The greatest threat to the type of transactions for which these @@ -941,17 +950,8 @@ list is paid just once. Offline dictionary attacks are defeated if the client chooses a fresh nonce for each authentication, as this specification requires. -3.6 Man in the Middle -Digest authentication is vulnerable to "man in the middle" (MITM) -attacks. Clearly, a MITM would present all the problems of -eavesdropping. But it also offers some additional opportunities to the -attacker. -A possible man-in-the-middle attack would be to substitute a weaker qop -scheme for the one(s) sent by the server; the server will not be able to -detect this attack. For this reason, the client should always use the -strongest scheme that it understands from the choices offered, and @@ -963,6 +963,17 @@ Leach, Newman Standards Track [Page 16] +3.6 Man in the Middle + +Digest authentication is vulnerable to "man in the middle" (MITM) +attacks. Clearly, a MITM would present all the problems of +eavesdropping. But it also offers some additional opportunities to the +attacker. + +A possible man-in-the-middle attack would be to substitute a weaker qop +scheme for the one(s) sent by the server; the server will not be able to +detect this attack. For this reason, the client should always use the +strongest scheme that it understands from the choices offered, and should never choose a scheme that does not meet its minimum requirements. @@ -1002,17 +1013,6 @@ server realm associated with this file. On the other hand, decryption, or more likely a brute force attack, would be necessary to obtain the user's password. This is the reason that the realm is part of the digested data stored in the password file. It means that if one Digest -authentication password file is compromised, it does not automatically -compromise others with the same username and password (though it does -expose them to brute force attack). - -There are two important security consequences of this. First the -password file must be protected as if it contained plaintext passwords, -because for the purpose of accessing documents in its realm, it -effectively does. - -A second consequence of this is that the realm string should be unique -among all realms that any single user is likely to use. In particular a @@ -1024,6 +1024,17 @@ Leach, Newman Standards Track [Page 17] +authentication password file is compromised, it does not automatically +compromise others with the same username and password (though it does +expose them to brute force attack). + +There are two important security consequences of this. First the +password file must be protected as if it contained plaintext passwords, +because for the purpose of accessing documents in its realm, it +effectively does. + +A second consequence of this is that the realm string should be unique +among all realms that any single user is likely to use. In particular a realm string should include the name of the host doing the authentication. @@ -1045,10 +1056,19 @@ strength may vary depending on the implementation. 4 Example This example shows the use of the Digest SASL mechanism with the IMAP4 -AUTHENTICATE command [RFC 2060]. The base64 encoding of the challenges -and responses is part of the IMAP4 AUTHENTICATE command, not part of the -Digest specification itself. (Note: linebreaks added for editorial -clarity are not part of the mechanism): +AUTHENTICATE command [RFC 2060]. + +In this example, "C:" and "S:" represent a line sent by the client or +server respectively including a CRLF at the end. Linebreaks and +indentation within a "C:" or "S:" are editorial and not part of the +protocol. The password in this example was "secret". Note that the +base64 encoding of the challenges and responses is part of the IMAP4 +AUTHENTICATE command, not part of the Digest specification itself. + + + + + @@ -1057,11 +1077,50 @@ clarity are not part of the mechanism): +Leach, Newman Standards Track [Page 18] + + Digest SASL Mechanism September, 1999 + S: * OK elwood.innosoft.com PMDF IMAP4rev1 V6.0-9 + C: c CAPABILITY + S: * CAPABILITY IMAP4 IMAP4rev1 ACL LITERAL+ NAMESPACE QUOTA + UIDPLUS AUTH=CRAM-MD5 AUTH=DIGEST-MD5 AUTH=PLAIN + S: c OK Completed + C: a AUTHENTICATE DIGEST-MD5 + S: + cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNlPSJPQTZNRzl0 + RVFHbTJoaCIscW9wPSJhdXRoIixhbGdvcml0aG09bWQ1LXNlc3MsY2hh + cnNldD11dGYtOA== + C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2 + QuaW5ub3NvZnQuY29tIixub25jZT0iT0E2TUc5dEVRR20yaGgiLG5jPTAw + MDAwMDAxLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLGRpZ2VzdC11cmk9Im + ltYXAvZWx3b29kLmlubm9zb2Z0LmNvbSIscmVzcG9uc2U9ZDM4OGRhZDkw + ZDRiYmQ3NjBhMTUyMzIxZjIxNDNhZjcscW9wPWF1dGg= + S: + cnNwYXV0aD00YjJiYjM3ZjA0OTEwNTA1Nzc3YzJmNjM4YzkyMjcyNQ== + C: + S: a OK User logged in + --- + + The base64-decoded version of the SASL exchange is: + + S: realm="elwood.innosoft.com",nonce="OA6MG9tEQGm2hh",qop="auth", + algorithm=md5-sess,charset=utf-8 + C: charset=utf-8,username="chris",realm="elwood.innosoft.com", + nonce="OA6MG9tEQGm2hh",nc=00000001,cnonce="OA6MHXh6VqTrRk", + digest-uri="imap/elwood.innosoft.com", + response=d388dad90d4bbd760a152321f2143af7,qop=auth + S: rspauth=4b2bb37f04910505777c2f638c922725 + + The password in this example was "secret". + +This example shows the use of the Digest SASL mechanism with the ACAP, +using the same notational conventions and password as in the previous +example. Note that ACAP does not base64 encode and uses fewer round +trips that IMAP4. + @@ -1077,7 +1136,9 @@ clarity are not part of the mechanism): -Leach, Newman Standards Track [Page 18] + + +Leach, Newman Standards Track [Page 19] Digest SASL Mechanism September, 1999 @@ -1085,35 +1146,21 @@ Leach, Newman Standards Track [Page 18] - * OK elwood.innosoft.com IMAP4 Server PMDF5.3-1 at Mon, 28 Sep 1998 - 09:16:30 -0700 (PDT) - c CAPABILITY - * CAPABILITY IMAP4 IMAP4REV1 NAMESPACE STARTTLS AUTH=CRAM-MD5 - AUTH=DIGEST-MD5 AUTH=LOGIN AUTH=PLAIN - c OK CAPABILITY completed - a AUTHENTICATE DIGEST-MD5 - + cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNlPSJENlBpNXVvT2xp - RzI4WFZidVRYQ0l3Iixxb3A9ImF1dGgi - dXNlcm5hbWU9ImNocmlzIixyZWFsbT0iZWx3b29kLmlubm9zb2Z0LmNvbSIsbm - 9uY2U9IkQ2UGk1dW9PbGlHMjhYVmJ1VFhDSXciLG5jPTAwMDAwMDAxLGNub25j - ZT0iZS9nWG5wRW94ODNzVzNERXU3b1FoZyIscmVzcG9uc2U9IjRmNjA2NTBhYW - FmNDQxNzkyOWViNjg3Zjc2NmNlOTMyIixxb3A9ImF1dGgi - a OK AUTHENTICATE completed + S: * ACAP (IMPLEMENTATION "Test ACAP server") (SASL "CRAM-MD5" + "DIGEST-MD5" "PLAIN") + C: a AUTHENTICATE "DIGEST-MD5" + S: + {94} + S: realm="elwood.innosoft.com",nonce="OA9BSXrbuRhWay",qop="auth", + algorithm=md5-sess,charset=utf-8 + C: {206} + C: charset=utf-8,username="chris",realm="elwood.innosoft.com", + nonce="OA9BSXrbuRhWay",nc=00000001,cnonce="OA9BSuZWMSpW8m", + digest-uri="acap/elwood.innosoft.com", + response=6084c6db3fede7352c551284490fd0fc,qop=auth + S: a OK (SASL {40} + S: rspauth=d84489141f9d86605c6a77b95cb5365a) "AUTHENTICATE + Completed" --- - - Decoding the base64, gets: - - realm="elwood.innosoft.com",nonce="D6Pi5uoOliG28XVbuTXCIw",qop="auth - " - - and - - username="chris",realm="elwood.innosoft.com",nonce="D6Pi5uoOliG28XVb - uTXCIw", - nc=00000001,cnonce="e/gXnpEox83sW3DEu7oQhg", - response="4f60650aaaf4417929eb687f766ce932",qop=auth - - The password was "secret". The server uses the values of all the directives, plus knowledge of the users password (or the hash of the user's name, server's realm and the @@ -1134,27 +1181,29 @@ the user has authenticated. Part 3: Latin alphabet No. 3, ISO-8859-3, 1988. Part 4: Latin alphabet No. 4, ISO-8859-4, 1988. Part 5: Latin/Cyrillic alphabet, ISO-8859-5, 1988. + Part 6: Latin/Arabic alphabet, ISO-8859-6, 1987. + Part 7: Latin/Greek alphabet, ISO-8859-7, 1987. + Part 8: Latin/Hebrew alphabet, ISO-8859-8, 1988. + Part 9: Latin alphabet No. 5, ISO-8859-9, 1990. + [RFC 822] D. H. Crocker, "Standard for The Format of ARPA Internet Text + Messages," STD 11, RFC 822, UDEL, August 1982. + +[RFC 1321] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, + April 1992 -Leach, Newman Standards Track [Page 19] - Digest SASL Mechanism September, 1999 +Leach, Newman Standards Track [Page 20] - Part 6: Latin/Arabic alphabet, ISO-8859-6, 1987. - Part 7: Latin/Greek alphabet, ISO-8859-7, 1987. - Part 8: Latin/Hebrew alphabet, ISO-8859-8, 1988. - Part 9: Latin alphabet No. 5, ISO-8859-9, 1990. + Digest SASL Mechanism September, 1999 + - [RFC 822] D. H. Crocker, "Standard for The Format of ARPA Internet Text - Messages," STD 11, RFC 822, UDEL, August 1982. -[RFC 1321] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, - April 1992 [RFC 2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, @@ -1194,15 +1243,6 @@ West Covina, CA 91790 USA chris.newman@innosoft.com - -Leach, Newman Standards Track [Page 20] - - - Digest SASL Mechanism September, 1999 - - - - 7 ABNF What follows is the definition of the notation as is used in the @@ -1212,6 +1252,18 @@ Since it is intended that a single Digest implementation can support both HTTP and SASL-based protocols, the same notation is used in both to facilitate comparison and prevention of unwanted differences. Since it is cut-and-paste from the HTTP specifications, not all productions may + + + + +Leach, Newman Standards Track [Page 21] + + + Digest SASL Mechanism September, 1999 + + + + be used in this specification. It is also not quite legal ABNF; again, the errors were copied from the HTTP specifications. @@ -1251,26 +1303,26 @@ rule1 | rule2 The character "*" preceding an element indicates repetition. The full form is "*element" indicating at least and at most occurrences of element. Default values are 0 and infinity so that + "*(element)" allows any number, including zero; "1*element" requires + at least one; and "1*2element" allows one or two. +[rule] + Square brackets enclose optional elements; "[foo bar]" is equivalent + to "*1(foo bar)". +N rule + Specific repetition: "(element)" is equivalent to -Leach, Newman Standards Track [Page 21] - Digest SASL Mechanism September, 1999 +Leach, Newman Standards Track [Page 22] + Digest SASL Mechanism September, 1999 - "*(element)" allows any number, including zero; "1*element" requires - at least one; and "1*2element" allows one or two. -[rule] - Square brackets enclose optional elements; "[foo bar]" is equivalent - to "*1(foo bar)". -N rule - Specific repetition: "(element)" is equivalent to "*(element)"; that is, exactly occurrences of (element). Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three alphabetic characters. @@ -1297,12 +1349,17 @@ N rule a comment that continues to the end of line. This is a simple way of including useful notes in parallel with the specifications. -implied *LWS - Except where noted otherwise, linear white space ("LWS") can be - included between any adjacent "token", "quoted-string", or - "separators" constructs, as these are defined in the basic rules - below; such LWS is ignored. + + implied *LWS + The grammar described by this specification is word-based. Except + where noted otherwise, linear white space (LWS) can be included + between any two adjacent words (token or quoted-string), and between + adjacent words and separators, without changing the interpretation of + a field. At least one delimiter (LWS and/or separators) MUST exist + between any two tokens (for the definition of "token" below), since + they would otherwise be interpreted as a single token. + 7.2 Basic Rules The following rules are used throughout this specification to describe @@ -1310,10 +1367,15 @@ basic parsing constructs. The US-ASCII coded character set is defined by ANSI X3.4-1986 [USASCII]. OCTET = + CHAR = + UPALPHA = + LOALPHA = + ALPHA = UPALPHA | LOALPHA + DIGIT = -Leach, Newman Standards Track [Page 22] +Leach, Newman Standards Track [Page 23] Digest SASL Mechanism September, 1999 @@ -1321,11 +1383,6 @@ Leach, Newman Standards Track [Page 22] - CHAR = - UPALPHA = - LOALPHA = - ALPHA = UPALPHA | LOALPHA - DIGIT = CTL = CR = @@ -1333,6 +1390,7 @@ Leach, Newman Standards Track [Page 22] SP = HT = <"> = + CRLF = CR LF All linear white space, including folding, has the same semantics as SP. A recipient MAY replace any linear white space with a single SP before @@ -1343,7 +1401,7 @@ interpreting the field value or forwarding the message downstream. The TEXT rule is only used for descriptive field contents and values that are not intended to be interpreted by the message parser. Words of *TEXT MAY contain characters from character sets other than ISO-8859-1 -[ISO 8859]only when encoded according to the rules of RFC 2047 [RFC +[ISO 8859] only when encoded according to the rules of RFC 2047 [RFC 2047]. TEXT = qdstr-val <"> ) + qdstr-val = *( qdtext | quoted-pair ) + qdtext = > + -Leach, Newman Standards Track [Page 23] +Leach, Newman Standards Track [Page 24] Digest SASL Mechanism September, 1999 @@ -1382,11 +1444,12 @@ Leach, Newman Standards Track [Page 23] - quoted-string = ( <"> qdstr-val <"> ) - qdstr-val = *( qdtext | quoted-pair ) - qdtext = > - -The backslash character ("\") MAY be used as a single-character quoting +Note that LWS is NOT implicit between the double-quote marks (<">) +surrounding a qdstr-val and the qdstr-val; any LWS will be considered +part of the qdstr-val. This is also the case for quotation marks +surrounding any other construct. + + The backslash character ("\") MAY be used as a single-character quoting mechanism only within qdstr-val and comment constructs. quoted-pair = "\" CHAR @@ -1434,8 +1497,7 @@ necessary. - -Leach, Newman Standards Track [Page 24] +Leach, Newman Standards Track [Page 25] Digest SASL Mechanism September, 1999 @@ -1446,8 +1508,8 @@ Leach, Newman Standards Track [Page 24] /* if the string is entirely in the 8859-1 subset of UTF-8, then * translate to 8859-1 prior to MD5 */ - void MD5_UTF8_8859_1(MD5_CTX *ctx, const unsigned char *base, int - len) + void MD5_UTF8_8859_1(MD5_CTX *ctx, const unsigned char *base, + int len) { const unsigned char *scan, *end; unsigned char cbuf; @@ -1457,7 +1519,7 @@ Leach, Newman Standards Track [Page 24] if (*scan > 0xC3) break; /* abort if outside 8859-1 */ if (*scan >= 0xC0 && *scan <= 0xC3) { if (++scan == end || *scan < 0x80 || *scan > 0xBF) - break; + break; } } /* if we found a character outside 8859-1, don't alter string @@ -1487,7 +1549,7 @@ Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or -assist in its implmentation may be prepared, copied, published and +assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself @@ -1496,7 +1558,7 @@ or references to the Internet Society or other Internet organizations, -Leach, Newman Standards Track [Page 25] +Leach, Newman Standards Track [Page 26] Digest SASL Mechanism September, 1999 @@ -1557,4 +1619,4 @@ FITNESS FOR A PARTICULAR PURPOSE. -Leach, Newman Standards Track [Page 26] \ No newline at end of file +Leach, Newman Standards Track [Page 27] \ No newline at end of file -- 2.39.5