[Gen-art] RE: Gen-ART review of draft-martin-ibcs-03

[[e-mail]]

Luther,

> Some comments are in-line below. 
> 
> We've added hash agility, specifying a different hash algorithm for
each
> of the defined levels of bit security as well as including an
additional
> parameter that defines the hash function used in each of the relevant
> algorithms. 
> 
> We've also added the longer key lengths that the extremely
> security-conscious might want - now specifying parameters for up to
and
> including the equivalent of 256 bits of symmetric strength.

Ok.
 
> > > Next, regarding point [3], the algorithms described in this draft
are
> > > public-key algorithms and are definitely not stream ciphers.
> > 
> > I stand behind point [3], here's a longer explanation and example:
> > 
> > At least Section 8.4 and 8.5 perform encryption and decryption by
> > XOR-ing a keystream with the plaintext or ciphertext (Sections
> > 5.4 and 5.5 appear to do likewise, but there are potential mistakes
> > in those sections that make this somewhat unclear).  While "stream
> > cipher" may not be a precise term for these constructs, they are
> > at least a stream-cipher-like operating mode for the public key
> > algorithms.  In particular, they are subject to <key,IV> reuse
> > concerns that apply to stream ciphers.
> > 
> > Specifically, for section 8.4, the actual encryption step for the
> > message m is:
> > 	y = HashStream(|m|, h') XOR m
> > where h' does not depend on m, so if the same s (effectively an IV)
> > is ever used twice with the same identity and public parameters for
> > different messages that have the same length (e.g., m1 and m2), the
> > HashStream element will be the same, so one can obtain the XOR of
> > the plaintext messages by XORing the corresponding ciphertexts,
i.e.:
> > 	y1 XOR y2 = m1 XOR m2
> > This is usually considered undesirable, as it tends to leak
information
> > about m1 and m2.  At a minimum, this needs to be discussed in the
> > security considerations section, even if the countermeasures to
> > prevent this from happening are left to other documents that apply
> > these algorithms to particular contexts.
> 
> We've added text that says that users SHOULD use a PRNG like those
> specified in FIPS 186-2 or X9.62. I believe that the definition of
> "random" should take care of this. After all, if your source of
entropy
> is random enough, then the probability of generating the same random
> value twice is cryptographically small.

Ok, please add a discussion to the security considerations section about
the consequences of ever using the same s value twice with the same key
as a reason why strong random numbers are needed.

> > > Are architectural issues, like the restrictions on letting
arbitrary
> > > clients decrypt on behalf of an arbitrary identity, more suitable
for
> > > other documents? After all, this document just describes two
> > > cryptographic algorithms. Are issues surrounding their
applications
> > > better described elsewhere?
> > 
> > Yes and no.  Let me start with an apology.  The following text from
> > my review is not correct:
> > 
> > -> 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.
> > 
> > With a suitably configured key server including proper use of
> > authentication with key server clients, proof of possession of
> > the private key for an identity could be used as proof of that
> > identity (i.e., authentication), but the configuration restrictions
> > are important.  In any case, the above text is wrong as written,
> > and I apologize for that mistake.
> > 
> > At the very least, the draft needs an architectural diagram showing
> > the key server and the clients showing which keys flow where for
> > at least one example - that would have saved me from this mistake,
> > and the fact that I made it is a backhanded indication that such
> > a diagram and associated discussion is needed.  I think that
> > discussion also needs to bring out the dependence on the key
> > server and authentication to the key server in restricting
> > availability of private keys to their corresponding identities
> > if one intends to use them for authentication.
> > 
> 
> There is another draft that gives an overall description of a complete
> IBE system. We've added a reference to that document. 

There should be a diagram and a summary of the roles of the components
in this draft.

> I have a draft that includes the above comments; let me know what
> additional points need to be addressed.

See the original review at:

http://www.alvestrand.no/ietf/gen/reviews/draft-martin-ibcs-03-black.txt

There are a number of additional comments on the body of the draft in
that review which should be addressed.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
[phone]             FAX: [phone]
[e-mail]        Mobile: [phone]
----------------------------------------------------


_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art