Subject: [MSEC] Review of GDOI Update

From: Yoav Nir <[email-masked]>
Date: Mon, 7 Jun 2010 16:29:48 +0300

Hi all

As I promised in Anaheim, I have reviewed the GDOI update draft. 

The draft has most everything you need to implement GDOI, but I think the structure of the document could be improved. The Introduction starts off with a list of 5 new payloads. I believe that this could wait until section 5, or at least 3 & 4. Also, that introduction uses terminology without having defined it.  For example:

   The new Phase 2 exchange, called "GROUPKEY-PULL," downloads keys for
   a group's "Re-key" SA and/or "Data-security" SA. 

This is before anyone has defined what a "Re-key" SA is, or what a "Data-security" SA is. Perhaps a terminology section would help here.

Section 2 says that GDOI is a phase 2 protocol, which MUST be protected by a phase 1 protocol. I think it should mention that only PULL exchanges are actually protected by the phase 1. The push messages are protected by other means.

Section 2.1.2 says that port 848 has been assigned for GDOI. It doesn't say if port 848 is used for PUSH, PULL, both, or also the phase 1. It also doesn't say why they didn't just re-use ports 500 and 4500 already assigned to IKE.

Section 3 says that a GROUPKEY-PULL exchange downloads TEK and/or KEK. What's missing at this point is a discussion about why we would download a TEK, why a KEK, or why both. IOW it doesn't say what it means if the GROUPKEY-PULL contains one, the other, or both. Only in the middle of section 3.4 do we first read the bracketed explanation below, and still there's not equivalent bracketed remark to tell us when a TEK will not be   present:
   The GCKS constructs the second GDOI message, including a nonce Nr,
   and the policy for the group in an SA payload, followed by SA TEK
   payloads for traffic SAs, and SA KEK policy (if the group controller
   will be sending Re-key messages to the group).

Section 3.2.1 says this:
   Cookies are used in the ISAKMP header as a weak form of denial of
   service protection.  
Cookies are not any form of DoS protection. They're merely identifiers for separating two IKE SAs, and that is why IKEv2 renamed them to "IKE SPIs". Stateless cookies are a weak form of DoS protection, as described in section 6.1.5.

Section 3.4 says that KEK policy is included only if the GKCS will be sending Re-key messages to the group. It doesn't say what the alternative is. Is it that only PULL messages will ever be used?

Section 4.3 says that the GKCS SHOULD NOT use the same key to sign the SIG payload in the PUSH as was used for authentication in the PULL. Why? Also, section 4 doesn't specify what key is used to create the SIG payload. Section 4.6 says "A CERT payload is added if the initiator needs to provide its certificate." and section 4.7 says "The signature of the decrypted message is then validated, possibly using the CERT payload if it is included." From this I can infer that in a CERT payload is included we use the private key associated with the public key in the certificate. But CERT is optional. What do we use if it's not included? And when does the initiator need to provide its certificate?

The document is missing requirement levels, as in what algorithms MAY, SHOULD, or MUST be implemented. One way to add this, is to add a requirement level column to the tables in section 5, kind of like those in RFC 4305.

Section 5.3.6 says that SIG_HASH_MD5 and SIG_HASH_SHA1 SHOULD NOT be used. IANAC but this seems wrong to me. The signature algorithms are used here to sign messages created by the GKCS. The attack we're defending against is that the attacker generate a rogue message with the same hash as  a valid message, so that the signature on one is also appropriate for the other. But this would require a 2nd pre-image attack on the hash function, and currently no such attacks exist for either MD5 or SHA1. This is different from the case of certificates, where the same attacker generates both the valid and rogue messages, so only a collision attack needs to be done.

Also, the same section says that SIG_ALG_DSS and SIG_ALG_ECDSS imply SIG_HASH_SHA1. Why is this true?  It's not any property of the algorithm that forces this. As an example, in RFC 4754 ECDSA signatures are defined to use a hash function according to their key size, so ECDSA with the 256-bit random ECP group uses SHA-256.

Section 5.3.7.3 is about using ECDSA for digital signatures. It doesn't say what curve to use. This may be redundant, because if the public key in included in a certificate, the certificate already tells you what curve is in use.

LKH: The introduction points to RFC 2627 for a definition of LKH. However, that RFC does not contain either the LKH acronym or the name "Logical Key Hierarchy". Also, I believe the use of LKH is under-specified. For example, in section 5.6.3.1 in the description of the LKH key structure, we have "LKH ID" which is supposed to be the "position"  of this key in the binary tree structure. How is this position determined?  Is it just some random identifier like the letters in RFC 2627?. Also there's a "Key Handle", which is randomly generated, and is used to "uniquely identify a key within an LKH ID." When do we have more than one key in an LKH ID?  When we rekey? And how does a group member learn the LKH IDs of the nodes between it and the GKCS? Is it from the array in the PULL? 

Minor nits:
- In the introduction, we have "a Data-security SA includes a data encryption key, or TEK". You probably want to say "traffic encryption key"
- In section 3.2 (page 11 after the hash calculation) it says: "Note that nonces are included in the first two exchanges, with the GCKS…" This is a mistake. The nonces are included in the first two *messages* of a single exchange.
- Section 5.6.3 says this: "The LKH key packet is comprised of attributes representing different leaves in the LKH key tree." I think you meant "nodes" rather than "leaves"

Yoav

---

From: "Sheela Rowles (sheela)" <[email-masked]>
Date: Mon, 7 Jun 2010 09:43:43 -0700

Thanks Yoav!  I'll look through your comments and get back to you as
soon as I can. 

Thanks,
Sheela

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Yoav Nir
Sent: Monday, June 07, 2010 6:30 AM
To: [email-masked]
Subject: [MSEC] Review of GDOI Update

Hi all

The draft has most everything you need to implement GDOI, but I think
the structure of the document could be improved. The Introduction starts
off with a list of 5 new payloads. I believe that this could wait until
section 5, or at least 3 & 4. Also, that introduction uses terminology
without having defined it.  For example:

This is before anyone has defined what a "Re-key" SA is, or what a
"Data-security" SA is. Perhaps a terminology section would help here.

Section 2 says that GDOI is a phase 2 protocol, which MUST be protected
by a phase 1 protocol. I think it should mention that only PULL
exchanges are actually protected by the phase 1. The push messages are
protected by other means.

Section 2.1.2 says that port 848 has been assigned for GDOI. It doesn't
say if port 848 is used for PUSH, PULL, both, or also the phase 1. It
also doesn't say why they didn't just re-use ports 500 and 4500 already
assigned to IKE.

Section 3 says that a GROUPKEY-PULL exchange downloads TEK and/or KEK.
What's missing at this point is a discussion about why we would download
a TEK, why a KEK, or why both. IOW it doesn't say what it means if the
GROUPKEY-PULL contains one, the other, or both. Only in the middle of
section 3.4 do we first read the bracketed explanation below, and still
there's not equivalent bracketed remark to tell us when a TEK will not
be   present:
   The GCKS constructs the second GDOI message, including a nonce Nr,
   and the policy for the group in an SA payload, followed by SA TEK
   payloads for traffic SAs, and SA KEK policy (if the group controller
   will be sending Re-key messages to the group).

Section 3.2.1 says this:
   Cookies are used in the ISAKMP header as a weak form of denial of
   service protection.  
Cookies are not any form of DoS protection. They're merely identifiers
for separating two IKE SAs, and that is why IKEv2 renamed them to "IKE
SPIs". Stateless cookies are a weak form of DoS protection, as described
in section 6.1.5.

Section 3.4 says that KEK policy is included only if the GKCS will be
sending Re-key messages to the group. It doesn't say what the
alternative is. Is it that only PULL messages will ever be used?

Section 4.3 says that the GKCS SHOULD NOT use the same key to sign the
SIG payload in the PUSH as was used for authentication in the PULL. Why?
Also, section 4 doesn't specify what key is used to create the SIG
payload. Section 4.6 says "A CERT payload is added if the initiator
needs to provide its certificate." and section 4.7 says "The signature
of the decrypted message is then validated, possibly using the CERT
payload if it is included." From this I can infer that in a CERT payload
is included we use the private key associated with the public key in the
certificate. But CERT is optional. What do we use if it's not included?
And when does the initiator need to provide its certificate?

The document is missing requirement levels, as in what algorithms MAY,
SHOULD, or MUST be implemented. One way to add this, is to add a
requirement level column to the tables in section 5, kind of like those
in RFC 4305.

Section 5.3.6 says that SIG_HASH_MD5 and SIG_HASH_SHA1 SHOULD NOT be
used. IANAC but this seems wrong to me. The signature algorithms are
used here to sign messages created by the GKCS. The attack we're
defending against is that the attacker generate a rogue message with the
same hash as  a valid message, so that the signature on one is also
appropriate for the other. But this would require a 2nd pre-image attack
on the hash function, and currently no such attacks exist for either MD5
or SHA1. This is different from the case of certificates, where the same
attacker generates both the valid and rogue messages, so only a
collision attack needs to be done.

Also, the same section says that SIG_ALG_DSS and SIG_ALG_ECDSS imply
SIG_HASH_SHA1. Why is this true?  It's not any property of the algorithm
that forces this. As an example, in RFC 4754 ECDSA signatures are
defined to use a hash function according to their key size, so ECDSA
with the 256-bit random ECP group uses SHA-256.

Section 5.3.7.3 is about using ECDSA for digital signatures. It doesn't
say what curve to use. This may be redundant, because if the public key
in included in a certificate, the certificate already tells you what
curve is in use.

LKH: The introduction points to RFC 2627 for a definition of LKH.
However, that RFC does not contain either the LKH acronym or the name
"Logical Key Hierarchy". Also, I believe the use of LKH is
under-specified. For example, in section 5.6.3.1 in the description of
the LKH key structure, we have "LKH ID" which is supposed to be the
"position"  of this key in the binary tree structure. How is this
position determined?  Is it just some random identifier like the letters
in RFC 2627?. Also there's a "Key Handle", which is randomly generated,
and is used to "uniquely identify a key within an LKH ID." When do we
have more than one key in an LKH ID?  When we rekey? And how does a
group member learn the LKH IDs of the nodes between it and the GKCS? Is
it from the array in the PULL? 

Minor nits:
- In the introduction, we have "a Data-security SA includes a data
encryption key, or TEK". You probably want to say "traffic encryption
key"
- In section 3.2 (page 11 after the hash calculation) it says: "Note
that nonces are included in the first two exchanges, with the GCKS..."
This is a mistake. The nonces are included in the first two *messages*
of a single exchange.
- Section 5.6.3 says this: "The LKH key packet is comprised of
attributes representing different leaves in the LKH key tree." I think
you meant "nodes" rather than "leaves"

Yoav
_______________________________________________
MSEC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/msec