upstream/openldap
1
0
Fork 0
mirror of https://git.openldap.org/openldap/openldap.git synced 2026-01-05 22:50:51 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions

rev 5

Browse source
This commit is contained in:
Kurt Zeilenga 1999-11-22 01:20:49 +00:00
parent eeecbd0ea1
commit 72e2d53143
2 changed files with 691 additions and 408 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

581
doc/drafts/draft-good-ldap-ldif-xx.txt
View file

@ -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
ldif-file = ldif-content / ldif-changes
Good February 22, 1999 [Page 2]
Good October 18, 1999 [Page 2]
INTERNET-DRAFT LDAP Data Interchange Format 22 February 1999
INTERNET-DRAFT LDAP Data Interchange Format 19 October 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)
ldif-content = version-spec 1*(1*SEP ldif-attrval-record)
version-spec = "version:" *SPACE version-number
version-number = 1*DIGIT ; version-number MUST be "1" for the
; LDIF format described in this document.
ldif-changes = version-spec 1*(1*SEP ldif-change-record)
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]>
ldif-attrval-record = dn-spec SEP 1*attrval-spec
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]>
ldif-change-record = dn-spec SEP *control changerecord
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
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
Good February 22, 1999 [Page 3]
Good October 18, 1999 [Page 3]
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) >
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
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 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 19 October 1999
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.
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 which begins with a pound-sign ("#", ASCII 35) is a
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
INTERNET-DRAFT LDAP Data Interchange Format 19 October 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.
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) 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.
8) Values or distinguished names that end with SPACE SHOULD be base-
64 encoded.
9) Values 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:: <JapaneseOU>
Good October 18, 1999 [Page 8]
INTERNET-DRAFT LDAP Data Interchange Format 19 October 1999
ou;lang-ja:: 5Za25qWt6YOo
# ou;lang-ja:: <JapaneseOU>
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 <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]
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,
<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,
@ -602,6 +830,14 @@ 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,
Good October 18, 1999 [Page 15]
INTERNET-DRAFT LDAP Data Interchange Format 19 October 1999
<URL:http://ds.internic.net/rfc/rfc1521.txt>
[6] T. Berners-Lee, L. Masinter, M. McCahill, "Uniform Resource
@ -609,14 +845,6 @@ References
<URL:http://ds.internic.net/rfc/rfc1738.txt>
[7] S. Bradner, "Key Words for use in RFCs to Indicate Requirement
Good February 22, 1999 [Page 11]
INTERNET-DRAFT LDAP Data Interchange Format 22 February 1999
Levels", Harvard University, RFC 2119, March 1997,
<URL:http://ds.internic.net/rfc/rfc2119.txt>
@ -624,6 +852,11 @@ INTERNET-DRAFT LDAP Data Interchange Format 22 February 1999
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
@ -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]

518
doc/drafts/draft-leach-digest-sasl-xx.txt
View file

@ -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,6 +768,18 @@ 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
Leach, Newman Standards Track [Page 13]
Digest SASL Mechanism September, 1999
for the handling of "stale", after sending the "digest-challenge"
authentication proceeds as in the case of initial authentication.
@ -770,16 +792,6 @@ 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.
Leach, Newman Standards Track [Page 13]
Digest SASL Mechanism September, 1999
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,25 +1056,14 @@ 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.
@ -1085,35 +1085,82 @@ 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: * 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
---
Decoding the base64, gets:
The base64-decoded version of the SASL exchange is:
realm="elwood.innosoft.com",nonce="D6Pi5uoOliG28XVbuTXCIw",qop="auth
"
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
and
The password in this example was "secret".
username="chris",realm="elwood.innosoft.com",nonce="D6Pi5uoOliG28XVb
uTXCIw",
nc=00000001,cnonce="e/gXnpEox83sW3DEu7oQhg",
response="4f60650aaaf4417929eb687f766ce932",qop=auth
The password 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 19]
Digest SASL Mechanism September, 1999
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"
---
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,17 +1181,6 @@ 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.
Leach, Newman Standards Track [Page 19]
Digest SASL Mechanism September, 1999
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.
@ -1156,6 +1192,19 @@ Leach, Newman Standards Track [Page 19]
[RFC 1321] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992
Leach, Newman Standards Track [Page 20]
Digest SASL Mechanism September, 1999
[RFC 2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
University of Tennessee, November 1996.
@ -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,17 +1303,6 @@ rule1 | rule2
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
Leach, Newman Standards Track [Page 21]
Digest SASL Mechanism September, 1999
"*(element)" allows any number, including zero; "1*element" requires
at least one; and "1*2element" allows one or two.
@ -1271,6 +1312,17 @@ Leach, Newman Standards Track [Page 21]
N rule
Specific repetition: "<n>(element)" is equivalent to
Leach, Newman Standards Track [Page 22]
Digest SASL Mechanism September, 1999
"<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.
@ -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 = <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]
Leach, Newman Standards Track [Page 23]
Digest SASL Mechanism September, 1999
@ -1321,11 +1383,6 @@ Leach, Newman Standards Track [Page 22]
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)>
@ -1333,6 +1390,7 @@ Leach, Newman Standards Track [Page 22]
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
@ -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 = <any OCTET except CTLs,
@ -1371,10 +1429,14 @@ to be used within a parameter value.
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]
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 = <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
@ -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]
Leach, Newman Standards Track [Page 27]