idnits 2.17.1 draft-melnikov-sasl-auxprop-attrs-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 287. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 293. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 237), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 237. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages -- Found 8 instances of the string 'FORMFEED[Page...' -- is this a case of missing nroff postprocessing? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 8 instances of too long lines in the document, the longest one being 16 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 2004) is 7316 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '4' on line 79 == Unused Reference: 'KEYED-MD5' is defined on line 198, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2256 (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4519, RFC 4523) -- No information found for draft-ietf-sasl-crammd5-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SASL-CRAM' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'KEYED-MD5') -- No information found for draft-ietf-sasl-rfc2831bis-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SASL-DIGEST' -- No information found for draft-burdis-cat-srp-sasl-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SASL-SRP' Summary: 15 errors (**), 0 flaws (~~), 6 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Melnikov 3 Internet Draft Isode Limited 4 Document: draft-melnikov-sasl-auxprop-attrs-00.txt April 2004 5 Expires in six months 7 An LDAP Schema for CMU SASL auxiliary properties plugins 9 Status of this Memo 11 This document is an Internet Draft and is in full conformance with 12 all provisions of Section 10 of RFC 2026. 14 Internet Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its Areas, and its Working Groups. Note that 16 other groups may also distribute working documents as Internet 17 Drafts. Internet Drafts are draft documents valid for a maximum of 18 six months. Internet Drafts may be updated, replaced, or obsoleted 19 by other documents at any time. It is not appropriate to use 20 Internet Drafts as reference material or to cite them other than as 21 ``work in progress''. 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 A revised version of this draft document will be submitted to the RFC 30 editor as a Draft Standard for the Internet Community. Discussion 31 and suggestions for improvement are requested. Distribution of this 32 draft is unlimited. 34 Internet DRAFT SASL 2 April 2004 36 Abstract 38 The CMU SASL implementation of the RFC 2222 defines an API for auxiliary 39 properties (auxprop) plugins. Auxprop plugins can store properties. 40 A property can be a user password in cleartext or in a hashed form 41 used by a particular SASL mechanism, or any other information 42 associated with the user. This document describes a schema for the 43 storage of auxprop properties in an LDAP directory server. 45 1. Conventions used in this document 47 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 48 in this document are to be interpreted as defined in "Key words for 49 use in RFCs to Indicate Requirement Levels" [KEYWORDS]. 51 <<1.3.6.1.4.1.3.8 - "ldapResources" under CMU node. 53 1.3.6.1.4.1.3.8.1 - cmuSaslAuxprop 55 1.3.6.1.4.1.3.8.1.0 - Syntaxes 57 1.3.6.1.4.1.3.8.1.1 - Attributes types 59 1.3.6.1.4.1.3.8.1.2 - Object classes >> 61 2. SASL related Attribute Types 63 This document defines the attribute types cmusaslsecretCRAM-MD5, 64 cmusaslsecretDIGEST-MD5, cmusaslsecretOTP and cmusaslsecretSRP. Their 65 definition is provided below. 67 ( 1.3.6.1.4.1.3.8.1.1.1 68 NAME 'cmusaslsecretCRAM-MD5' 69 DESC 'Prehashed password as described in CRAM-MD5' 70 EQUALITY octetStringMatch 71 SINGLE-VALUE 72 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{32} ) 74 cmusaslsecretCRAM-MD5 attribute contains the binary representation of 75 the following C structure: 77 typedef struct HMAC_MD5_STATE_s { 78 UINT4 ipad_state[4]; 79 UINT4 opad_state[4]; 81 Internet DRAFT SASL 2 April 2004 83 } HMAC_MD5_STATE; 85 i.e. 16 bytes (4 element array of 32bit integers, each element in 86 network byte order) of ipad is followed by 16 bytes (4 element array 87 of 32bit integers, each element in network byte order) of opad. ipad 88 and opad are calculated as defined in [SASL-CRAM]. 90 ( 1.3.6.1.4.1.3.8.1.1.2 91 NAME 'cmusaslsecretDIGEST-MD5' 92 DESC 'Shared secret for DIGEST-MD5' 93 EQUALITY octetStringMatch 94 SINGLE-VALUE 95 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{16} ) 97 The cmusaslsecretDIGEST-MD5 attribute contains the binary 98 representation of SS (16-octets) as defined in section 2.1.2.1 of 99 [SASL-DIGEST]: 101 SS = H( { unq(username-value), ":", unq(realm-value), ":", passwd } ) 103 ( 1.3.6.1.4.1.3.8.1.1.3 104 NAME 'cmusaslsecretOTP' 105 DESC 'OTP secret' 106 EQUALITY octetStringMatch 107 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) 109 The cmusaslsecretOTP attribute is a tab separated octet string that 110 contains information relevant for OTP [SASL-OTP] authentication. The 111 syntax of the string is as follows: 113 \t \t \t \t 115 where \t is the horizontal tab character (%x09), 117 - name of the hashing algorithm as described in [SASL-OTP]; 119 - 16 hex digits (in lowercase) of the 8-byte OTP hash; 121 - 4 digit unsigned integer that specifies how many times the user 122 is allowed to log in using the password before it has to change it. 123 This value is decremented each time the user has successfully authenticated; 125 - random string that doesn't contain \t (<>) 127 20 digit unsigned integer, the time since the Epoch 128 (00:00:00 UTC, January 1, 1970), measured in seconds. It defines 129 the time when the record lock expires. This value is used to lock 131 Internet DRAFT SASL 2 April 2004 133 the record, as OTP doesn't allow for simultaneous authentication 134 by the same user. 136 This attribute is multivalued. For example, it may contain multiple 137 OTP hashes for different hashing algorithms. 139 ( 1.3.6.1.4.1.3.8.1.1.4 140 NAME 'cmusaslsecretSRP' 141 DESC 'base64 encoded SRP secret' 142 EQUALITY octetStringMatch 143 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) 145 This is the base64 encoding of the following data described in [SASL- 146 SRP]: 148 { utf8(mda) mpi(v) os(salt) } 150 where 152 mda - message digest algorithm name as defined in [SASL-SRP] 154 v - password verifier (<>) 156 salt - a random string, 1 to 255 octets in length 158 This attribute is multivalued. For example, it may contain data for 159 multiple message digest algorithms. 161 <> 163 3. Object Classes 165 This document defines the following object class: 167 ( 1.3.6.1.4.1.3.8.1.2.1 168 NAME 'cmuSaslUser' 169 SUP top 170 AUXILIARY 171 MAY ( userPassword $ cmusaslsecretCRAM-MD5 $ cmusaslsecretDIGEST-MD5 $ 172 cmusaslsecretOTP $ cmusaslsecretSRP) ) 174 The cmusaslsecretCRAM-MD5, cmusaslsecretDIGEST-MD5, cmusaslsecretOTP 175 and cmusaslsecretSRP attribute types are described in section 2 of 176 this document. The userPassword attribute type is defined in 177 [RFC2256]. 179 Internet DRAFT SASL 2 April 2004 181 4. Security considerations 183 <> 185 5. References 187 5.1. Normative References 189 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 190 Requirement Levels", RFC 2119, March 1997 192 [RFC2256] Wahl, A., "A Summary of the X.500(96) User Schema for use 193 with LDAPv3", RFC 2256, December 1997 195 [SASL-CRAM] Nerenberg, L. (Editor), "The CRAM-MD5 SASL Mechanism", 196 work in progress, draft-ietf-sasl-crammd5-XX.txt, replaces RFC 2195 198 [KEYED-MD5] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for 199 Message Authentication", RFC 2104, IBM and UCSD, February 1997. 201 [SASL-DIGEST] Leach, P., Newman, C., Melnikov, A., "Using Digest 202 Authentication as a SASL Mechanism", work in progress, draft-ietf- 203 sasl-rfc2831bis-XX.txt, replaces RFC 2831 205 [SASL-OTP] Newman, C., "The One-Time-Password SASL Mechanism", RFC 206 2444, October 1998 208 [SASL-SRP] Burdis, K.R., Naffah, R., "Secure Remote Password SASL 209 Mechanism", work in progress, draft-burdis-cat-srp-sasl-XX.txt 211 5.2. Informative References 213 6. Author's Address 215 Alexey Melnikov 216 Isode Limited 217 5 Castle Business Village 218 36 Station Road 219 Hampton, Middlesex 220 TW12 2BX, United Kingdom 222 Email: Alexey.Melnikov@isode.com 223 URI: http://www.melnikov.ca/ 225 Internet DRAFT SASL 2 April 2004 227 7. Acknowledgments 229 The author of the document would like to thank Howard Chu for 230 reminding that this document has to be written; to Chris Ridd, Damy 231 Mahl and Rob Siemborski for comments and suggestions to this 232 document; to Ken Murchison for designing the OTP and SRP secret 233 formats. 235 8. Full Copyright Statement 237 Copyright (C) The Internet Society (2004). All Rights Reserved. 239 This document and translations of it may be copied and furnished to 240 others, and derivative works that comment on or otherwise explain it 241 or assist in its implementation may be prepared, copied, published 242 and distributed, in whole or in part, without restriction of any 243 kind, provided that the above copyright notice and this paragraph are 244 included on all such copies and derivative works. However, this 245 document itself may not be modified in any way, such as by removing 246 the copyright notice or references to the Internet Society or other 247 Internet organizations, except as needed for the purpose of 248 developing Internet standards in which case the procedures for 249 copyrights defined in the Internet Standards process must be 250 followed, or as required to translate it into languages other than 251 English. 253 The limited permissions granted above are perpetual and will not be 254 revoked by the Internet Society or its successors or assigns. 256 This document and the information contained herein is provided on an 257 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 258 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 259 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 260 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 261 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 263 Acknowledgement 265 Funding for the RFC Editor function is currently provided by the 266 Internet Society. 268 9. Intellectual Property 270 The IETF takes no position regarding the validity or scope of any 271 Intellectual Property Rights or other rights that might be claimed to 272 pertain to the implementation or use of the technology described in 274 Internet DRAFT SASL 2 April 2004 276 this document or the extent to which any license under such rights 277 might or might not be available; nor does it represent that it has 278 made any independent effort to identify any such rights. Information 279 on the procedures with respect to rights in RFC documents can be 280 found in BCP 78 and BCP 79. 282 Copies of IPR disclosures made to the IETF Secretariat and any 283 assurances of licenses to be made available, or the result of an 284 attempt made to obtain a general license or permission for the use of 285 such proprietary rights by implementers or users of this 286 specification can be obtained from the IETF on-line IPR repository at 287 http://www.ietf.org/ipr. 289 The IETF invites any interested party to bring to its attention any 290 copyrights, patents or patent applications, or other proprietary 291 rights that may cover technology that may be required to implement 292 this standard. Please address the information to the IETF at 293 ietf-ipr@ietf.org. 295 Internet DRAFT SASL 2 April 2004 297 Status of this Memo .......................................... i 298 Abstract ..................................................... 2 299 1. Conventions used in this document ...................... 2 300 2. SASL related Attribute Types ........................... 2 301 3. Object Classes ......................................... 4 302 4. Security considerations ................................. 5 303 5. References ............................................. 5 304 5.1. Normative References ................................... 5 305 5.2. Informative References ................................. 5 306 6. Author's Address ........................................ 5 307 7. Acknowledgments ......................................... 6 308 8. Full Copyright Statement ................................ 6 309 9. Intellectual Property ................................... 6