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:[EMAIL PROTECTED]
Sent: May 18, 2006 1:52 PM
To: Ignjatic, Dragan; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [email protected]; [email protected]
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
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
