Document: draft-martin-ibcs-03 Reviewer: David L. Black Review Date: April 3, 2007 IETF LC End Date: April 9, 2007 Summary: This draft is on the right track, but has open issues, described in the review. Comments: The draft contains an immense amount of cryptographic mathematics, beyond what is reasonably possible for me to review in detail. The draft needs detailed review by an expert cryptographer to look for subtle errors in the notation and mathematics - this is not such a review. The draft has a number of open issues - the most important are: [1] Lack of hash agility [2] Lack of IPR disclosures [3] Use of a stream cipher without discussion of protection against reuse. These three items are tagged with their numbers below. In addition, there is no discussion of rekeying - based on [3] it will be necessary to change the "key" for an identity in order to avoid collisions. In order to do that it will be necessary to change the "possibly augmented with a time stamp and other attributes" identity material alluded to in the definition of Identity in section 2. This is not discussed or specified. There is no guidance about use of the mechanisms in this document. It is *very* important to understand that the ability to encrypt or decrypt on behalf of an identity is not proof of that identity, and hence the mechanisms described in this draft MUST NOT be used for authentication purposes, and any identity used with these mechanisms MUST be authenticated or verified by other means. The architecture behind this work envisions a key server that would have to impose access controls on its clients if there is a need to enforce trust restrictions that prevent an arbitrary client from encrypting/decrypting on behalf of an arbitrary identity. This topic is not discussed in the draft. [1] The most important issue is that algorithms in this draft lack secure hash agility - SHA1 is hard-coded as the only hash supported, and the ASN.1 module in this draft does not contain any information to identify the hash that was used. This is a very bad design practice, particularly as the security considerations section describes how SHA1 collisions can be used to attack the techniques in this draft (i.e., pre-images are not necessary to mount an attack), so the possibility of needing to change the hash algorithm is realistic. If it is necessary to approve this draft as submitted, the IESG should add a strong statement expressing disapproval of the lack of hash agility and strongly discouraging non-hash-agile designs. [2] I do not see any IPR disclosures for this draft - a search for Voltage Security as the Assignee at the USPTO suggests that an IPR Disclosure may be required. The IESG should obtain an explicit affirmative assurance from the draft authors that they have complied with the IPR disclosure provisions of RFC 3979, and should withhold approval of this draft until that assurance is obtained. In addition, due to this draft's extensive use of elliptic curve cryptography, efforts should be made to obtain either an IPR disclosure from Certicom or a third-party IPR Disclosure from the draft authors regarding Certicom's patent portfolio. The security considerations (section 13) describe parameters for 3 cryptographic strength levels, 80-bit, 112-bit, and 128-bit, but the algorithm in Section 5.1.1 only supports the 80-bit level. This needs to be explained in the security considerations section or corrected in Section 5.1.1. Also, the absence of levels of security beyond 128-bit in this discussion renders this draft incomplete by comparison to other IETF work that includes the 256-bit level of security. SHA1 will not be usable to realize 256-bit level security, see issue [1] above. The use of ASN.1 as the standard output encoding is unfortunate. With the exception of certificates (where ASN.1 is a necessity), ASN.1 is not the most convenient format for usage in IETF protocols. There appear to be a number of unstated range or boundary assumptions on the numbers used in this draft. Here are two examples: - The final modulus computation in Section 4.1 is questionable if n has an order of magnitude close to that of v_1. That computation appears to be assuming that v_1 is >>>> (much, much, much, much larger) than n. - Algorithm 4.1 will misbehave badly if its input n is <= 1. This is an example of what appear to be multiple failures to range-check the input to the lg() function - the draft needs an editing pass to range-check the inputs to all instances of the lg() function. The entire draft needs to be checked for all similar unstated assumptions, and statements of them need to be added, including adding algorithm checks for violations of them. I asked a cryptographer (Landon Noll, Neoscale) to take a look at the draft. In addition to the boundary conditions discussed above, he found a number of other things in a brief review: - Sections 4.1 and 4.2 reinvent cryptographic mechanisms that are already well-known. It is not clear why this reinvention is being done or whether the results are as sound as the existing mechanisms. Specifically: - For Section 4.1, see FIPS publication 800-90 (updated March 13, 2007) for a random bit generator that can be used to realize this function. - For Section 4.2, see Annex C of FIPS 140-2 (updated March 19, 2007). - The function HashToRangeq() is used in several places - it's apparently a specific instantiation of HashtoRangen() defined in Section 4.1, but this notation is problematic, for example, HashtoRange-n() and HashtoRange-q() would be better. Is the "-n" or "-q" here required to be identical to the second argument of this function? - Section 5.4 says: 3. Select s random 160-bit vector rho, represented as 20-byte string in big-endian convention. This is ambiguous about whether rho is a single vector or a sequence of s vectors - based on step 12, the latter appears to have been intended, in which case "vector" should be "vectors" and "string" should be "strings", but then step 11 needs to be clarified to only use the first vector. The other possibility is that "s random" should have been "a random, and step 12 is wrong (see below). Why does the representation of rho (big-endian) need to be specified, as rho is internal to this algorithm? - Section 5.5: In steps 5 and 6, should V, W and w instead be V', W' and w' respectively? - Section 5.4, step 12: should "W = HashStream(|m|, rho XOR m)" instead be "W = HashStream(|m|, rho) XOR m" ? The latter is consistent with the corresponding decryption step (5.5, step 6), whereas the former appears to use the message as part of the IV for keystream generation, which is peculiar. - [3] The encryption and decryption operations in this draft are stream ciphers, but this draft contains no warnings about or defenses against collisions for stream ciphers. That's not acceptable. Correcting this will require additions to the requirements on the generation of rho in section 5.4. Using a non-repeating salt as part of the IV (e.g., as is done in GCM) is one possibility. Minor Issue: The draft uses the word "believed" in several places to assert the strength of the cryptographic mechanisms it describes. The draft should cite references in support of this belief. Important Nit: The algorithm numbers do not match the section numbers (e.g., Algorithm 3.5.2 is in section 3.5.1). They should be aligned in order to improve readability. Nit: lg(x) is the base-2 logarithm. This needs to be added to the notation section.