idnits 2.17.1 draft-ietf-krb-wg-sha1-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 3667, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 148. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 138), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 33. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 2) being 70 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 4 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 68 has weird spacing: '...osystem any...' -- 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 18, 2005) is 6938 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) == Unused Reference: 'SHA1' is defined on line 111, but no explicit reference was found in the text == Unused Reference: 'KRB' is defined on line 116, but no explicit reference was found in the text == Unused Reference: 'PKINIT' is defined on line 120, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA1' == Outdated reference: A later version (-34) exists of draft-ietf-cat-kerberos-pk-init-20 Summary: 10 errors (**), 0 flaws (~~), 9 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT K. Raeburn 2 Kerberos Working Group MIT 3 Document: draft-ietf-krb-wg-sha1-00.txt October 18, 2004 4 expires April 18, 2005 6 Unkeyed SHA-1 Checksum Specification 7 for Kerberos 5 9 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 or will be disclosed, and any of which I become aware will be 13 disclosed, in accordance with RFC 3668. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than a "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 Copyright Notice 33 Copyright (C) The Internet Society (2004). All Rights Reserved. 35 Abstract 37 The Kerberos cryptosystem specification requires a profile detailing 38 several operations for a new checksum type for ensuring the integrity 39 of data in Kerberos and related protocol exchanges. This document 40 specifies the use of a simple unkeyed checksum type based on SHA-1. 42 1. Introduction 44 The Kerberos cryptosystem specification requires a profile detailing 45 several operations for a new checksum type for ensuring the integrity 46 of data in Kerberos and related protocol exchanges. This document 47 specifies the use of a simple unkeyed checksum type based on SHA-1. 49 (...to be expanded on a bit, describe PKINIT use...) 51 2. Checksum Definition 53 The SHA-1 Kerberos checksum type calculates a checksum using the 54 SHA-1 hash algorithm. This algorithm takes as input a message of 55 arbitrary length, and produces as output a 160-bit (20 octet) hash 56 value. 58 Any general specification of a Kerberos checksum value to be computed 59 must include the encryption key and a key usage value [KCRYPTO]. 60 Both of these values are ignored for the SHA-1 checksum type, thus 61 this checksum algorithm may be used with any encryption key type. 63 The parameters for the Kerberos checksum profile for this type are 64 thus: 66 sha1 67 ---------------------------------------------- 68 associated cryptosystem any 70 get_mic sha1(msg) 72 verify_mic get_mic and compare 74 The sha1 checksum algorithm is assigned a checksum type number of 14. 76 3. Security Considerations 78 Unkeyed checksum types should be used with caution, in limited 79 circumstances where the lack of a key does not provide an avenue for 80 an attacker to compromise the integrity of the data being conveyed. 81 Even when encrypted, the use of unkeyed checksums may allow some 82 forms of attack; this is discussed in the Security Considerations 83 section of [KCRYPTO]. 85 The use of unkeyed checksums for integrity protection should be done 86 with great care. 88 4. IANA Considerations 90 The Kerberos checksum type values 10 and 14 have both been reserved 91 for "sha1 (unkeyed)" per [KCRYPTO], the latter with intent to use it 92 with this specification, and the former on the basis of speculation 93 that some implementation might have used that value for the same 94 purpose. 96 XXX...mention PKINIT above as the intended use? 98 IANA is directed to assign the Kerberos checksum type value 14 to 99 "sha1" with a reference to this document. 101 As no supporting information has been found regarding any existing 102 experimental use of or specification for Kerberos checksum type 10, 103 IANA is directed to delete that registry entry, leaving the value 104 available for future assignment. 106 Normative References 108 [KCRYPTO] 109 Raeburn, K., "Encryption and Checksum Specifications for Kerberos 110 5", draft-ietf-krb-wg-crypto-07.txt, February 2004. 111 [SHA1] 112 NIST, "Secure Hash Standard", FIPS PUB 180-1, April 1995. 114 Informative References 116 [KRB] 117 Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos 118 Network Authentication Service (V5)", draft-ietf-krb-wg-kerberos- 119 clarifications-07.txt, September 2004. 120 [PKINIT] 121 Tung, B., Neuman, C., Hur, M., Medvinsky, A., Medvinsky, S., Wray, 122 J., and J. Trostle, "Public Key Cryptography for Initial 123 Authentication in Kerberos", draft-ietf-cat-kerberos-pk- 124 init-20.txt, July 2004. 126 Author's Address 128 Kenneth Raeburn 129 Massachusetts Institute of Technology 130 77 Massachusetts Avenue 131 Cambridge, MA 02139 132 raeburn@mit.edu 134 Full Copyright Statement 136 Copyright (C) The Internet Society 2004. This document is subject to 137 the rights, licenses and restrictions contained in BCP 78, and except 138 as set forth therein, the authors retain all their rights. 140 Disclaimer 142 This document and the information contained herein are provided on an 143 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 144 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 145 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 146 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 147 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 148 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.