Re: [secdir] Secdir last call review of draft-weis-gdoi-rekey-ack-05

["Brian Weis (bew)" <[e-mail]>]

Hi Yaron,

Thanks for the review. We’ve added some clarification below, and made some changes in -06 to address your comments. Please let us know if we did not address them satisfactorily.

On Aug 5, 2017, at 8:49 AM, Yaron Sheffer <[e-mail]<mailto:[e-mail]>> wrote:

Reviewer: Yaron Sheffer
Review result: Has Issues

Summary: this reviewer is not clear about the value of the push-ack (compared
to a pull) and about the strategy that was chosen.

In a group key management system either a “pull” (triggered by a group member) or a “push” (by the key server)" could be used to provide updates to the group. However, a “pull” by the group member implies a polling method, which has the deficiency that the key server cannot cause a policy replacement any sooner than the polling method by the group members. Also “polling” can cause additional unnecessary traffic. So is is better for any update on the group policy or renewal of group keys to be distributed by the GCKS using a PUSH message. The ACK-message is used to offer a feedback mechanism to a policy update for the PUSH exchange.
* "For example, a GCKS policy can use the acknowledgements to determine [...]
which members may no longer be members of the group." This sentence is very
confusing: when are members not members?

We’ve reworded this text. It’s trying to convey that a missing ACK message (or a certain number of it) can be used to identify that a group member is no longer receiving group traffic, and is now may be considered an ex-group member. For example, it could be a multicast receiver that is no longer interested in being a receiver for the group. But it could also be that a network event has caused it to be unavailable for a sufficient length of time such that it doesn’t have current keying material and therefore can’t be considered a current group member. There is no reliable “I’m leaving the group” message flow, and of course in my second example no such messages would have been intended by the group member.

* The new protocol capability is defined as optional, but really isn't. "A GM
receiving the KEK_ACK_REQUESTED attribute can choose to ignore it, thus
appearing as if it does not support the KEK_ACK_REQUESTED attribute. However,
GCKS policy may consider a non-responsive GM to no longer desire to be a member
of the group." So if you want to play the game, you MUST support the new
attribute.

Point taken. We’ve changed the text to reflect this.

* I'm puzzled at the overall protocol. Being able to send ACKs is a GM software
capability. Why not have the GM announce this capability when it initially
registers to the GCKS? Then the GCKS would know what to expect, whereas with
the current protocol it is left waiting for an ACK that may never come, either
because the GM is dead or because it just doesn't feel like responding. Add the
long waits (jitter of "a few seconds" and potential retries), and this looks
like a far from optimal management experience.

Indeed a GM could announce its capability, but whether or not ACKs are desired is a component of the group policy. In the context of GDOI the GCKS is the entity that defines the group policy. There can be groups where the ACK is used, whereas others do not.  The capabilities announcement you suggest could certainly help the KS to know whether or not to expect the ACK from a particular GM, but the focus of this I-D is on the the declaration of the request for ACKs by the GCKS and the format of the ACK.

* 2.2: "This is a private key" - to avoid confusion, I suggest: "This is a
secret symmetric key" (if this is indeed the case). Obviously using the same
key for encryption and for HMAC is not a best practice.

We’ve made this change.

* Sec. 5: ACK messages can also be duplicated in the network. I suggest to add
a sentence describing what the GCKS should do in this case.

The Security Considerations (section 7.3) describes a method for the GCKS to detect replays. This is arguably better placed in this section, so we’ve moved it here..

* Sec. 6: I am confused about the notion of "jitter" here. If the PUSH messages
are sent as multicast (the recommended alternative AFAICT), I'm not sure about
the benefit of using multicast, given that each recipient responds with a
unicast ACK. And if the PUSH is unicast, there should be no reason for a jitter
as the sender can throttle the PUSH messages as necessary.

The concept of “jitter” is most valuable for responses to a multicast PUSH message. The use of a multicast PUSH message lower processing on the GCKS. Since each GM can e given the exact same policy, there’s no call to send it out as a unicast message. The jitter helps spread out the replies a bit to avoid inundating the GCKS.

* Moreover, everything would be much more predictable if the GCKS could
indicate if a jitter is expected and how much of a jitter (based on size of the
group, network throughput, and queue length). Specifically, this would allow
the GCKS to tell how long it should wait for an ACK.

This would be somewhat useful, but in practice might not help the GCKS as much as it seems. The jitter value provided would also be dependent on several network parameters that aren’t under the control of the GCKS or the GM. Even when the GM does not add any jitter to the ACK, the underlying network may delay the PUSH and/or for the ACK. And as stated in Section 6, the GCKS may be configured with additional policy actions like retransmissions to overcome lost ACKs. Altogether to add jitter to the ACK is not a must, it is a way to help the GCKS deal with a huge number of GMs. In practice, we’ve found that having the GMs choose the jitter has worked well, even when the GMs are different implementations.

* Cryptographic agility: this document specifies only one algorithm for the
HASH value, and says that if a new algorithm is needed, there will be a new
KEK_ACK_REQUESTED payload defined. However to make sure that this really
"works", we need to define whether multiple such payloads can be sent
simultaneously (if e.g. some GMs still support the old algorithm) and what's
the expected behavior. I would suggest to define an additional SHA-512 payload
just to make for a concrete example.

This is a good suggestion. We’ve added SHA-512 versions of the existing KEK_ACK_REQUESTED values.

See <https://tools.ietf.org/html/draft-weis-gdoi-rekey-ack-06>

Thanks,
Brian

--
Brian Weis
Security, CSG, Cisco Systems
Telephone: [phone]
Email: [e-mail]<mailto:[e-mail]>