[Gen-art] Gen-ART review of draft-martin-ibcs-04.txt

[[e-mail]]

IETF-ACTION: The IPR disclosure search is failing to find IPR
disclosures for this draft.  A search for draft-martin-ibcs-04.txt
should return IPR disclosures #821 and #751.  Please make it so.

Xavier and Luther,

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 wait for direction from your document shepherd 
or AD before posting a new version of the draft. 

Document: draft-martin-ibcs-04.txt
Reviewer: David L. Black
Review Date: 03 July 2007
IESG Telechat date: 05 July 2007 

Summary:

This draft is basically ready for publication as an Informational
RFC, but has nits that should be fixed before publication.

Comments:

The -04 version of this draft is much improved over the -03 version,
and has addressed most of the concerns raised in the GenART review
of the -03 version.  In particular, the serious lack of hash agility
and the related lack of support for the 256-bit level of security
have both been corrected in the -04 version, there is now a
discussion of use of IBE at the front of the draft, and the security
considerations section has been significantly improved.  Many thanks
to the authors for dealing with these issues.

The IPR disclosure was in fact filed at the time of the previous
review, but the IETF IPR search tool fails to find it.  This review
has been cc:'d to IETF-ACTION in order to correct this failure.
I've cc:'d the smime WG chairs to ensure that they are aware of the
contents of this disclosure - https://datatracker.ietf.org/ipr/821/ .

The security considerations section does not explicitly address
the stream-cipher-like behavior of encryption/decryption noted
in the previous GenART review.  This is ok because this security
concern has been addressed  by other means in the -04 version;
the plaintext is now required to be a random session key in
Sections 5.4 and 6.4.  If the crucial value that effectively
initializes the stream cipher (l in Section 5.4, s in Section
6.4), is ever reused, an adversary learns only the XOR of two
random session keys, which should be of no value to the adversary
for truly random session keys.

I still have one concern - there is no discussion of rekeying an
individual user.  In order to rekey a user whose private keying
material has been compromised without changing the master IBE
secret, the user's identity has to change.  The draft defines
identity in Section 2.2 as:

        Identity - An identity an arbitrary string, usually a human-
        readable unambiguous designator of a system user, possibly 
        augmented with a time stamp and other attributes. 

The "possibly augmented ... " wording may be describing a feature
that is crucial to enabling a user to be rekeyed without changing
her name (e.g., given name, email address).  Some discussion of
rekeying of users without changing the master IBE secret should be
included in the security considerations section, as it appears to
have relevance to the choice of structure of identities used with
these algorithms.

Nit: the parameter space for V in Sections 5.4.1 and 5.5.1 should
be "{0, ... , 255}^hashlen" instead of "{0, ... , 255}^20" .

Nit: I don't see the point of the [KERLAW] reference to an 1883
paper in French.  The added [BF] citations in the -04 version are
sufficient for the request in the previous review that a reference
be cited to support the statements of belief about strength of
these cryptographic techniques.

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