Draft:  draft-ietf-msec-mikey-rsa-r-04.txt
Reviewer: Scott W Brim [sbrim@cisco.com]
Review Date: Thursday 5/18/2006 3:52 PM CST
IETF LC Date: 5/19/2006

Summary: This draft is basically ready for publication, but has nits that
should be fixed before publication.

Here is my review:

Just before I went through this draft we had been having a discussion
of SHOULD, MUST, etc., and thus I was more aware than usual of their
usage.  I found several uses of SHOULD which I believe should be
improved, to make the document clearer for implementors.  

RFC2119 says

        3. SHOULD This word, or the adjective "RECOMMENDED", mean that
           there may exist valid reasons in particular circumstances
           to ignore a particular item, but the full implications must
           be understood and carefully weighed before choosing a
           different course.

To help implementors "understand and carefully weigh" their decision,
SHOULDs actually require more supporting text than MUSTs.

The draft says:

   The RAND payload SHOULD be included in the I_MESSAGE when
   MIKEY-RSA-R mode is used for unicast communication.  It SHOULD be
   omitted when this mode is used to establish group keys.  The reason
   for the inclusion of the RAND payload in unicast scenarios is to
   allow for the Initiator to contribute entropy to the key derivation
   process (in addition to the CSB_ID).

There are two SHOULDs here.  For the first one, under what conditions
would a Initiator not contribute entropy?  Should this SHOULD be a
MAY?  A MUST?  If it should be a SHOULD, please explain the
exceptions.  

For the second one ("SHOULD be omitted"), are there any conditions
under which it might be legitimate to include the RAND payload for
group keys?  If so those conditions should be listed.  If not, it
should be a MUST.

There is some discussion down in 5.1 but it doesn't seem to answer
these questions.  If 5.1 is meant to do so, then please put more
explicit information there and have these SHOULDs refer to it.
Similarly, if I could find the exceptions in rfc3830 somewhere, could
you give a more specific reference to where?

(One also wonders about the threat model where more entropy is needed
for unicast keys than group keys.)

Here is a related SHOULD issue:

   o  If a RAND payload is present in the I_MESSAGE, both sides use
      that RAND payload as the RAND value in the MIKEY key
      computation.  In case of multicast, if a RAND payload is present
      in the I_MESSAGE, the Responder SHOULD ignore the payload.  In
      any case, the R_MESSAGE for multicast communication MUST contain
      a RAND payload and that RAND payload is used for key
      computation.

So the sender should omit the RAND payload in the multicast case
stated above), and if sent, the receiver SHOULD ignore it.  Under what
conditions is it appropriate for the receiver NOT to ignore it?
Should this be a MUST?

... and then two more, unrelated:

   The Initiator MAY also send security policy (SP) payload(s)
   containing all the security policies that it supports.  If the
   Responder does not support any of the policies included, it SHOULD
   reply with an Error message of type "Invalid SPpar" (Error no. 10).

Under what conditions would the Responder not reply with that error
message?  Is this a MAY?

   When used in group scenarios with bi-directional media, the
   Responder SHOULD include two TGKs or TEKs in the KEMAC payload.
   The first TGK or TEK SHOULD be used for receiving media on the
   Initiator's side and the second one to encrypt/authenticate media
   originating on the Initiator's side.  This allows all the multicast
   traffic to be encrypted/authenticated by the same group key, while
   keys used for unicast streams from all the group members can still
   be independent.

Again ... when is it appropriate not to include two TGKs or TEKs?
When is it appropriate for the Initiator not to use the first key for
receiving and the second for sending?  Should these two SHOULDs be
MUSTs?  If not, please make the exceptions clear.