Hi Brian,
Thank you for addressing most of my comments in the new version, and for
clarifying points where I was off the mark.
The only remaining comment that's only partly addressed is the one on
crypto agility. Quoting myself:
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.
In other words, supporting more algorithms in not sufficient. The
question is whether we support incremental deployment of a new algorithm
to a large group of GMs.
Thanks,
Yaron
On 24/08/17 19:48, Brian Weis (bew) wrote:
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 <yaronf.ietf@xxxxxxxxx
<mailto:yaronf.ietf@xxxxxxxxx>> 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: +1 408 526 4796
Email: bew@xxxxxxxxx <mailto:bew@xxxxxxxxx>