I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call
comments you may receive.
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 <key, IV> 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 <key, IV> 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.
Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
black_david(_at_)emc(_dot_)com Mobile: +1 (978) 394-7754
----------------------------------------------------