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

[Lakshminath Dondeti <[e-mail]>]

Hi Scott,

We have received all the reviews and are now ready to update the 
document, once you give the go ahead that the proposed resolutions 
are ok.  Please let us know at your earliest convenience.  Thanks.

Lakshminath

At 07:11 PM 5/20/2006, Lakshminath Dondeti wrote:
>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
>
>_______________________________________________
>msec mailing list
>[e-mail]
>http://six.pairlist.net/mailman/listinfo/msec


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