-
-
-
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
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
-Good February 22, 1999 [Page 1]
+Good October 18, 1999 [Page 1]
\f
-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.
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
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.
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]
+\f
+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
+ ; <name-component> 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]
+\f
+INTERNET-DRAFT LDAP Data Interchange Format 19 October 1999
+
+
+ url = <a Uniform Resource Locator, as defined in [6]>
+ ; (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]
\f
-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 = <a distinguished name, as defined in RFC 2253 [3]>
- base64-dn = <a dn which has been base-64 encoded, as
- defined in RFC 1521 [5]>
- rdn = <a relative distinguished name, as defined in RFC
- 2253 [3]>
- base64-rdn = <an rdn which has been base-64 encoded, as
- defined in RFC 1521 [5]>
-
- attrval-spec = attribute-description ((":") / (":" *SPACE value) /
- ("::" *SPACE base64-value) /
- (":<" *SPACE url))
- url = <a Uniform Resource Locator, as defined in [6]>
- ; (See Note 6, below)
- attribute-description = <an attribute description, as defined in [4].
- An attribute description MAY NOT contain a
- colon ":">
- value = 1*safe-initval *safe
- ; (See Note 9, below)
- safe = <any value except CR or LF>
- safe-initval = <any value except CR, LF, colon (":", ASCII 58
- decimal), SPACE, and less-than ("<" , ASCII 60
- decimal)>
- base64-value = <base-64-encoded value, as defined in RFC 1521 [5]>
-
- 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]
\f
-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 = <ASCII SP, space>
- SEP = (CR LF / LF)
- CR = <ASCII CR, carriage return>
- LF = <ASCII LF, line feed>
- DIGIT = <any ASCII decimal digit (60 - 71 decimal) >
+ BASE64-STRING = [*(BASE64-CHAR)]
Notes on LDIF Syntax
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:
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]
\f
-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
objectclass: top
objectclass: person
objectclass: organizationalPerson
+
+
+
+Good October 18, 1999 [Page 7]
+\f
+INTERNET-DRAFT LDAP Data Interchange Format 19 October 1999
+
+
cn: Bjorn Jensen
sn: Jensen
telephonenumber: +1 408 555 1212
objectclass:person
objectclass:organizationalPerson
cn:Barbara Jensen
-
-
-
-Good February 22, 1999 [Page 5]
-\f
-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
objectclass: organizationalUnit
ou:: 5Za25qWt6YOo
# ou:: <JapaneseOU>
+
+
+
+Good October 18, 1999 [Page 8]
+\f
+INTERNET-DRAFT LDAP Data Interchange Format 19 October 1999
+
+
ou;lang-ja:: 5Za25qWt6YOo
# ou;lang-ja:: <JapaneseOU>
ou;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2
userpassword: {SHA}O3HSv1MusyL4kTjP+HKI5uxuNoM=
objectclass: top
objectclass: person
-
-
-
-Good February 22, 1999 [Page 6]
-\f
-INTERNET-DRAFT LDAP Data Interchange Format 22 February 1999
-
-
objectclass: organizationalPerson
objectclass: inetOrgPerson
uid: rogasawara
Example 5: A file containing a reference to an external file
+
+
+Good October 18, 1999 [Page 9]
+\f
+INTERNET-DRAFT LDAP Data Interchange Format 19 October 1999
+
+
version: 1
dn: cn=Horatio Jensen, ou=Product Testing, dc=airius, dc=com
objectclass: top
telephonenumber: +1 408 555 1212
jpegphoto:< file:///usr/local/directory/photos/hjensen.jpg
-
-
-Good February 22, 1999 [Page 7]
-\f
-INTERNET-DRAFT LDAP Data Interchange Format 22 February 1999
-
-
Example 6: A file containing a series of change records and comments
version: 1
# 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]
+\f
+INTERNET-DRAFT LDAP Data Interchange Format 19 October 1999
+
+
# facsimiletelephonenumber attribute
dn: cn=Paula Jensen, ou=Product Development, dc=airius, dc=com
changetype: modify
telephonenumber: +1 408 555 1234
telephonenumber: +1 408 555 5678
-
-
-
-
-Good February 22, 1999 [Page 8]
-\f
-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
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]
+\f
+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.
ldif-02.txt
1) The BNF has been modified such that a simple attribute name
-
-
-
-Good February 22, 1999 [Page 9]
-\f
-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.
Differences between draft-ietf-asid-ldif-02.txt and draft-good-ldap-
ldif-00.txt
+
+
+Good October 18, 1999 [Page 12]
+\f
+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.
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
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.
3) Comment lines may be folded (this is now explicitly mentioned in
note 2).
-
-
-Good February 22, 1999 [Page 10]
-\f
-INTERNET-DRAFT LDAP Data Interchange Format 22 February 1999
-
-
4) Moved this section (differences between draft versions) to an
appendix.
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]
+\f
+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 <prose-val>.
+
+ 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]
+\f
+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
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
mation", RFC 2425, September 1998,
<URL:http://www.ietf.org/rfc/rfc2245.txt>
- [2] Crocker, D.H., "Standard for the Format of ARPA Internet Text
- Messages", RFC 822, August 1982,
- <URL:http://ds.internic.net/rfc/rfc822.txt>
+ [2] Crocker, D., Overell, P., "Augmented BNF for Syntax Specifica-
+ tions: ABNF" , RFC 2234, November 1997,
+ <URL:http://ds.internic.net/rfc/rfc2234.txt>
[3] Wahl, M., Kille, S., Howes, T., "A String Representation of Dis-
tinguished Names", RFC 2253,
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,
- <URL:http://ds.internic.net/rfc/rfc1521.txt>
- [6] T. Berners-Lee, L. Masinter, M. McCahill, "Uniform Resource
- Locators (URL)", RFC 1738, December 1994,
- <URL:http://ds.internic.net/rfc/rfc1738.txt>
- [7] S. Bradner, "Key Words for use in RFCs to Indicate Requirement
+Good October 18, 1999 [Page 15]
+\f
+INTERNET-DRAFT LDAP Data Interchange Format 19 October 1999
-Good February 22, 1999 [Page 11]
-\f
-INTERNET-DRAFT LDAP Data Interchange Format 22 February 1999
+ <URL:http://ds.internic.net/rfc/rfc1521.txt>
+ [6] T. Berners-Lee, L. Masinter, M. McCahill, "Uniform Resource
+ Locators (URL)", RFC 1738, December 1994,
+ <URL:http://ds.internic.net/rfc/rfc1738.txt>
+ [7] S. Bradner, "Key Words for use in RFCs to Indicate Requirement
Levels", Harvard University, RFC 2119, March 1997,
<URL:http://ds.internic.net/rfc/rfc2119.txt>
gan, April 1996. <URL:
http://www.umich.edu/~dirsvcs/ldap/doc/guides/slapd/toc.html>
+ [9] M. P. Armijo, "Tree Delete Control", Microsoft Corporation,
+ INTERNET-DRAFT June 1999, <URL:http://www.ietf.org/internet-
+ drafts/draft-armijo-ldap-treedelete-01.txt>
+
+
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.
-
-
-
-
-
-
-
-
-
-
-
-
-Good February 22, 1999 [Page 12]
-\f
+Good October 18, 1999 [Page 16]
+\f
\ No newline at end of file
- 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
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
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
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
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.
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
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.
+
+ 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
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" |
+ 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
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
+ 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
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.
-
+ 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
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.
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] \f
+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.
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
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" }
-
-
+ 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.
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
+
+
+
+ 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.
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.
+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),
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
-
+"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.
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
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.
-
-
-
+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
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
+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.
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
+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.
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.
+
+
+
+
+
+Leach, Newman Standards Track [Page 18] \f
+
+ 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.
+
-Leach, Newman Standards Track [Page 18] \f
+
+
+Leach, Newman Standards Track [Page 19] \f
Digest SASL Mechanism September, 1999
- * 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
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] \f
- Digest SASL Mechanism September, 1999
+Leach, Newman Standards Track [Page 20] \f
- 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,
chris.newman@innosoft.com
-
-Leach, Newman Standards Track [Page 20] \f
-
-
- Digest SASL Mechanism September, 1999
-
-
-
-
7 ABNF
What follows is the definition of the notation as is used in the
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] \f
+
+
+ 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.
The character "*" preceding an element indicates repetition. The full
form is "<n>*<m>element" indicating at least <n> and at most <m>
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: "<n>(element)" is equivalent to
-Leach, Newman Standards Track [Page 21] \f
- Digest SASL Mechanism September, 1999
+Leach, Newman Standards Track [Page 22] \f
+ 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: "<n>(element)" is equivalent to
"<n>*<n>(element)"; that is, exactly <n> occurrences of (element).
Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three
alphabetic characters.
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
ANSI X3.4-1986 [USASCII].
OCTET = <any 8-bit sequence of data>
+ CHAR = <any US-ASCII character (octets 0 - 127)>
+ UPALPHA = <any US-ASCII uppercase letter "A".."Z">
+ LOALPHA = <any US-ASCII lowercase letter "a".."z">
+ ALPHA = UPALPHA | LOALPHA
+ DIGIT = <any US-ASCII digit "0".."9">
-Leach, Newman Standards Track [Page 22] \f
+Leach, Newman Standards Track [Page 23] \f
Digest SASL Mechanism September, 1999
- CHAR = <any US-ASCII character (octets 0 - 127)>
- UPALPHA = <any US-ASCII uppercase letter "A".."Z">
- LOALPHA = <any US-ASCII lowercase letter "a".."z">
- ALPHA = UPALPHA | LOALPHA
- DIGIT = <any US-ASCII digit "0".."9">
CTL = <any US-ASCII control character
(octets 0 - 31) and DEL (127)>
CR = <US-ASCII CR, carriage return (13)>
SP = <US-ASCII SP, space (32)>
HT = <US-ASCII HT, horizontal-tab (9)>
<"> = <US-ASCII double-quote mark (34)>
+ 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
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 = <any OCTET except CTLs,
A string of text is parsed as a single word if it is quoted using
double-quote marks.
+ quoted-string = ( <"> qdstr-val <"> )
+ qdstr-val = *( qdtext | quoted-pair )
+ qdtext = <any TEXT except <">>
+
-Leach, Newman Standards Track [Page 23] \f
+Leach, Newman Standards Track [Page 24] \f
Digest SASL Mechanism September, 1999
- quoted-string = ( <"> qdstr-val <"> )
- qdstr-val = *( qdtext | quoted-pair )
- qdtext = <any TEXT except <">>
-
-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
-
-Leach, Newman Standards Track [Page 24] \f
+Leach, Newman Standards Track [Page 25] \f
Digest SASL Mechanism September, 1999
/* 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;
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
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
-Leach, Newman Standards Track [Page 25] \f
+Leach, Newman Standards Track [Page 26] \f
Digest SASL Mechanism September, 1999
-Leach, Newman Standards Track [Page 26] \f
\ No newline at end of file
+Leach, Newman Standards Track [Page 27] \f
\ No newline at end of file
projects / openldap / commitdiff