Subject: Re: [MSEC] I-D Action:draft-ietf-msec-gdoi-update-07.txt

From: Vincent Roca <[email-masked]>
Date: Sun, 07 Nov 2010 04:21:50 +0100

Hello Brian, Sheela and Thomas,

After reading -07, I have a certain number of comments:

I- Concerning section 7 "Security considerations"

** Risks associated to compromised group members.
   It is said:
        "The security of GDOI, therefore, is as good as
        the degree to which group members can be trusted..."
   I agree. However I'd like to know what could happen if
   one of the GM is compromised. Last sentence of 7.3.5
   mentions that a compromised GM may launch a DoS. Is
   there anything else? This is an important question since
   as the group size increases, so does the probability of
   having a compromised GM.

** Section 7.2.4 "Replay/Reflection Attack Protection"
   I have two comments: first of all, the first paragraph is
   essentially devoted to "liveness" (following section 3
   terminology) rather than replay protection. This should
   be reflected in the title IMHO since the goal is
   different.

   Then to provide replay protection you suggest to
     "keep a record of recently received GROUPKEY-PULL
      messages and reject messages that have already been
      processed."
   This method is inherently limited since the number of
   messages kept (and to which each incoming message is
   compared) is limited. Last sentence says this mechanism
   provides an "early discard" protection, which suggests
   there is an additional solution, but nothing is said.

** Section 7.2.5 "Denial of Service Protection"
   It is said: "The replay protection mechanisms described
   above provide the basis for denial of service protection."
   Is it sufficient? Is there anything else (in addition to
   the cookie pair weak protection mentioned above)?
   It's not clear to me.

** Section 7.3.4. "Replay/Reflection Attack Protection"
   I agree that comparing incoming messages to those
   recently received can help identifying duplicates that
   may be caused by a replay attack. But it's also an
   additional processing (each messages is compared to
   1, 10, 100 messages) and the benefit is in any case
   limited (an attacker, knowing this limit, can
   replay older messages). The SEQ mechanism is sufficient,
   isn't it? And a GM can retrieve the SEQ after a symmetric
   deciphering, so it does not create a major risk of DoS.

** 7.3.5.  Denial of Service Protection
   Deliberately limiting the number of GROUPKEY-PUSH messages
   that will be processed per second is another way of
   mitigating a DoS attack. It does not guaranty that a valid
   message will be processed, but that's another problem. At
   least the GM will save some CPU for other tasks.

II- Concerning the other sections:

** A section listing acronyms would be welcome.

** I have the feeling that the terminology list should
   be extended.

** Section 1.5.1. discusses Forward Access Control
   Requirements but there is no 1.5.2 for Backward
   Access Control. Is it done on purpose?

** Section 3.3. "Initiator Operations"
   A novice question... It is said:
        "If the policy in the SA payload is acceptable to
        the initiator, it continues the protocol."
   Is anything special should be done otherwise?
   Said differently, is there a recommended way of
   aborting the exchange and let the GCKS know that, so
   that he can reset its exchange context? Is it done
   at a lower level or is it achieved only with a timeout
   mechanism?

   There are several places in the document where the
   same kind of remark can be formulated (something wrong
   happens and the exchange is stopped).

   If a context needs to be kept for some time at the
   GCKS, isn't it another way to launch a DoS attack (it
   reminds me of the attack to TCP consisting in partially
   opening a large number of connections). (NB: I assume
   here the GM has been compromised which is a strong
   assumption, otherwise anti-replay will prevent it).

** Section 5.3. "SA KEK payload"
   There must be a valid reason, but the presence of the
   RESERVED2 field remains mysterious to me...
   Another remark: there is no guaranteed 32-bit alignment
   in this payload since the last field is of variable
   length. Is it an issue for the following payloads?
   I think it's not discussed.

I have many minor comments (typos and ambiguities)
but we'll see that together, it's simpler for everybody.

Cheers,

   Vincent