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

On 05/23/2006 19:20 PM, Lakshminath Dondeti allegedly wrote:
> 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.

Sorry, I was shuffling between email accounts and misplaced your mail!

I'm happy with all your suggestions except as noted below (all positive).

> At 07:11 PM 5/20/2006, Lakshminath Dondeti wrote:
>>> From: Scott W Brim [mailto:sbrim@cisco.com]
>>> 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.

So there is no reason to disallow it.  It sounds to me like you want a
MAY ignore.

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

Perhaps you could say something like: SHOULD reply with an error message
... for fast resolution of the state, but a response is not required for
the protocol to work, and is not needed if it is known that another
protocol such as SIP will indicate that the security context
establishment did not succeed.

Thanks much ... Scott

_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art