Subject: [MSEC] Comments on GSAKMP lite

From: Ran Canetti <[email-masked]>
Date: Thu, 20 Mar 2003 22:32:42 -0500

Folks,

I enclose a summary of a discussion I had with Hugh and Andrea in SFO
where I raised some issues regarding the GSAKMP-lite document. In general,
I felt that the protocol is good (modulo the points below) and the document 
is well written. However, the points below seem to require addressing.

Best,

Ran

* One editorial point was the lack of a "Security considerations" section.
Beyond being a formal requirement, such a section is a great place to
discuss many security issues relating to GSAKMP. (some examples can be
extracted from the remarks below.)

* DOS resilience: In the current protocol, the first message (coming from
the joining member) contains a Diffie-Hellman exponent. the GCKS needs 
to compute the DH secret before sending the response message. This requires
a modular exponentiation - which is a costly operation. Thus, a naive
implementation of a GCKS is highly susceptible to DOS attack that floods 
the GCKS with bogus DH exponents and causes the GCKS to do a costly 
exponentiation in response to each one. Andrea pointed out that if the GCKS
has a list of "acceptable group members" then the GCKS could 
reject bogus join requests  without doing the exponentiation. 
But such lists are not always available, and furthermore verifying that a
join request really comes from an acceptable member involves verifying
certificates, which is costly by itself.

Therefore I think it would be a very good idea to add an anti-DOS mechanism
to the protocol. One such mechanism, that is currently used in IKEv2, is to
add a optional cookie exchange between message 1 and 2. the exchange will be
turned on by the GCKS whenever it feels it is under DOS attack.

* Currently the third message (the ACK message sent by the member) is
digitally signed by the member. Instead of signing, it is enough to MAC this
message using a key derived from the agreed DH key. This will save an
unnecessary and costly signature generation and verification.
(Derivation of an additional MAC key is easy - just extend the derivation 
of the encryption key (used in message 2) to derive also a MAC key.)

* Recall the attack that Cathy Meadows found against a prior version of
GDOI: It was possible to use a signature generated by the GCKS in the
registration protocol to spoof a rekey message (and vice versa). The
solution in GDOI was to add reserved values to the signed texts that 
make it clear in which context a signature is generated.
A similar mechanism should be done explicitly in GSAKMP, to avoid similar
attacks. Apparently there are currently such values in the GSAKMP message
headers; but these should be made explicit and it should be made sure that
the values are actually signed.

* Another concern was to add the identity of the GCKS to the signed text
in the join request. This may mitigate the damage caused by a rogoue GCKS in
a distributed architecture. Hugh pointed out that there may be
interoperabiltiy advantages in NOT doing that. I'm interested to hear what
other people have to say about this traddeoff. In any case, the issue should
probably be discussed in the security considerations section.

* Regarding the order of encyption and signature in the key download
message: It wasnt clear to me whther the intention was first to encrypt the
polcy token and key download payloads, and then sign the ciphertexts (along
with the other fields to be signed), or alternatively to encrypt the
signature. I strongly vote for the first method - since the second method
does not guarantee the secrecy of the data. (See for instance the attack
in [K01].) 

* The current draft specifies "minimum fields to be included un der the
signature" in the three messages. For sake of unambiguity, it would be 
better to specify these fields deterministically - without allowing 
for potentially additional signed fields.

* Some additional work needs to be done in order  to make GSAKMP compatible
with TESLA. The main issue is to augment GSAKMP so that it will be possible to 
piggyback a time synchronization exchange on the GSAKMP messages. I will not
get into more details here; this should probably be done in cooperation
with the authors of the TESLA drafts.

* I think it will be a very good idea to discuss in the security considerations
section why the protocol may be secure. This is especially in place since
the current version is doing things from scratch, and does not use
off-the-shelf (and hopefully analyzed) key exchange protocols.

Here is my 2c towars this goal. The basic exchange in the registration protocol 
can be regarded as a variant of the ISO 9798-3 protocol, which is sketched 
below. The policy token and the group keys are then encrypted using a key 
derived from the agreed DH secret. The ISO 9798-3 protocol was analyzed in
[CK01].

The ISO 9798-3 protocol:

   A->B: A,N_a,g^a
   B->A: B,N_b,g^b,SIG_b(N_a,N_b,g^a,g^b,B,A)
   A->B: SIG_a(N_a,N_b,g^a,g^b,A,B)

 A salient point about this protocol is that each party signs, in
addition to the nonces and the two public DH exponents, also the
identity of the peer. (If the peer's identity is not signed then
the protocol is completely broken.) In the context of GSAKMP the 
identity of "B" is the group ID.

[Note though that this relates only to a small part of the GSAKMP protocol.
Full analysis should include the entire protocol, including the rekey
messages and group evolution over time.]

[CK01]     Canetti and Krawczyk, "Analysis of Key-Exchange Protocols
           and Their Use for Building Secure Channels", Eurocrypt 01.
           Available at http://eprint.iacr.org/2001/040.

[K01]      H. Krawczyk, "On the order of encryption and authentication, or
           how secure is SSL", Crypto 01.

_______________________________________________
msec mailing list
[email-masked]
http://www.pairlist.net/mailman/listinfo/msec

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 21 Mar 2003 13:42:18 -0500

Ran,

First of all many thanks for the quick analysis.  I have a couple of 
comments.

I too talked to Hugh and Andrea at the GSEC meeting and noted that the 
GSAKMP I-D needs more detail on, for example, how keys are derived.  In 
general, I would like the document to contain sufficient detail so an 
engineer can implement the protocol by reading it.  On a side note, 
while implementing GDOI, while I asked Brian for additional details a 
few times, I could refer to ISAKMP and IKE RFCs for insights and rationale.

Finally, I agree with you that the document needs explanations on the 
protections offered and not offered, in a detailed security 
considerations section.

best regards,
Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 21 Mar 2003 13:43:18 -0500

Considering the remote access application, IKEv2 was designed to protect 
the Responder from DoS attacks.  For key download protocols, this attack 
is all the more important, as the GCKS is always the Responder. 
Furthermore, it is quite possible that Registration requests arrive at a 
GCKS closer together (to each other) than remote access requests at an 
IPsec gateway.  Thus, the GCKS may not be able to differentiate between 
an attack and a high volume of legitimate requests.

Instead of the 3/5 message option (Ran's suggestion), why not make 
GSAKMP an always 5 message protocol.

regards,
Lakshminath

---

From: Hugh Harney <[email-masked]>
Date: Fri, 21 Mar 2003 15:37:38 -0500

Lakshminath,

I see architectures where groups could be created within protected 
enviroments and would never need the cookie exchange to prevent DOS. I 
also think that "normal" operation may well use the 3 message protocol 
instead of requiring the additional delay imposed by a two message 
cookie exchange.

I'd like to point out that GSAKMP can distribute the key dissemination 
function to several subordinate GC/KSs. This distributed operation 
avoids having an over worked centralized point of service / failure for 
group key distribution. Any one GC/KS or subordinate GC/KS should be 
able to determine when it is under attack and switch to cookie mode.

  I'd like to keep the 3 message protocol as the core with an optional 5 
message version for periods where there is stress.

Hugh

On Friday, Mar 21, 2003, at 13:43 US/Eastern, Lakshminath Dondeti wrote:

> Considering the remote access application, IKEv2 was designed to 
> protect the Responder from DoS attacks.  For key download protocols, 
> this attack is all the more important, as the GCKS is always the 
> Responder. Furthermore, it is quite possible that Registration 
> requests arrive at a GCKS closer together (to each other) than remote 
> access requests at an IPsec gateway.  Thus, the GCKS may not be able 
> to differentiate between an attack and a high volume of legitimate 
> requests.
>
>> the joining member) contains a Diffie-Hellman exponent. the GCKS 
>> needs to compute the DH secret before sending the response message. 
>> This requires
>> implementation of a GCKS is highly susceptible to DOS attack that 
>> floods the GCKS with bogus DH exponents and causes the GCKS to do a 
>> costly exponentiation in response to each one. Andrea pointed out 
>> that if the GCKS
>> has a list of "acceptable group members" then the GCKS could reject 
>> bogus join requests  without doing the exponentiation. But such lists 
>> are not always available, and furthermore verifying that a
>> (Derivation of an additional MAC key is easy - just extend the 
>> derivation of the encryption key (used in message 2) to derive also a 
>> MAC key.)
>> in [K01].) * The current draft specifies "minimum fields to be 
>> included un der the
>> signature" in the three messages. For sake of unambiguity, it would 
>> be better to specify these fields deterministically - without 
>> allowing for potentially additional signed fields.
>> with TESLA. The main issue is to augment GSAKMP so that it will be 
>> possible to piggyback a time synchronization exchange on the GSAKMP 
>> messages. I will not
>> Here is my 2c towars this goal. The basic exchange in the 
>> registration protocol can be regarded as a variant of the ISO 9798-3 
>> protocol, which is sketched below. The policy token and the group 
>> keys are then encrypted using a key derived from the agreed DH 
>> secret. The ISO 9798-3 protocol was analyzed in
>> [CK01].
>> The ISO 9798-3 protocol:
>>    A->B: A,N_a,g^a
Hugh Harney							Sparta, Inc.
[email-masked]						7075 Samuel Morse Drive
(410) 872-1515 x203					Columbia, MD, 21046