[Gen-art] Re: gen-art review of draft-ietf-msec-mikey-rsa-r-04.txt

[Lakshminath Dondeti <[e-mail]>]

Hi Scott,

Many thanks for your review.  You make very good points.  Some notes 
and proposed resolutions below.  We'll wait for the sec-dir review 
also and incorporate all the comments in one revision.

Dragan, Ping, and Francois, please feel free to correct me or make 
further clarifications.  Thanks.


>-----Original Message-----
>From: Scott W Brim [mailto:[e-mail]]
>Sent: May 18, 2006 1:52 PM
>To: Ignjatic, Dragan; [e-mail]; [e-mail];
>[e-mail]; [e-mail]; [e-mail];
>[e-mail]; [e-mail]; [e-mail]
>Subject: gen-art review of draft-ietf-msec-mikey-rsa-r-04.txt
>
>I am the assigned Gen-ART reviewer for
>draft-ietf-msec-mikey-rsa-r-04.txt.
>
>For background on Gen-ART, please see the FAQ at
><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.
>
>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.

We are RECOMMENDING, but if an Initiator chooses to not contribute 
randomness, that's ok.  It is generally desirable that both parties 
contribute randomness to key derivation, but MIKEY-RSA doesn't do it 
and RSA-R doesn't force it either.  We can add a note to this effect 
in the revision.


>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.

For this, I am proposing rephrasing to "A RAND payload MAY be included ... "


>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?

5.1 I guess could contain notes to the effect of "desirable that both 
parties contribute and so we added the feature that's absent in MIKEY-RSA."


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

This is a matter of two parties with data to send contributing 
entropy to derivation of keys that protect the said data.  The two 
parties are interested in protecting their individual streams and so 
either they can pick their own key (the sdescriptions protocol does 
this for instance) or the two parties can contribute entropy to key 
derivation (IKEv2 is an example here).  In group communication, the 
sender cares about the confidentiality of data and so it's in the 
sender's interest to generate strong 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?

The responder (group sender or controller) may choose to use the RAND 
payload to seed it's random number generator, but I don't want to 
suggest that in the draft, as that is merely a technique not central 
to the operation of the protocol.  I am ok with MUST ignore it.  Even 
with that end systems may choose to use the RAND information, but 
that does not impact externally observable behavior.


>... 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).

5.1 and 5.1.2 of RFC 3830 suggest SHOULD and we are continuing that 
here.  I guess the intention is to allow silent discarding.  Other 
signaling (SIP for instance) could indicate that the security context 
establishment did not succeed.  We want to allow that.  Thoughts?


>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.

So, this is a feature that we contemplated about not specifying in 
the RSA-R document.  The conclusion after a discussion between Dragan 
and me is that this should be removed from this specification and if 
there is interest should be specified in the general sense 
elsewhere.  We propose to remove the specification of how to carry 
multiple TGKs in RSA-R (they can be carried, some notes are in 3830, 
full details belong elsewhere.).  Any objections from anyone (MSEC 
folks are also recipients of this message)?

regards,
Lakshminath

>Thanks.
>
>swb


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