Subject: Re: [MSEC] Comments on GSAKMP lite

From: Hugh Harney <[email-masked]>
Date: Mon, 7 Apr 2003 08:25:57 -0400

Ran,

I've been thinking about our discussions at the IETF for a week or two. 
You made two suggestions - use cookies a la IKEv2 to prevent some DOS 
attacks and replace the signature on the GSAKMP ACK message with a 
signed MAC.

I believe that cookies must be added to the GSAKMP spec and that will 
happen.

However, I've been thinking about changing the authentication on the 
ACK message from a signature to a keyed MAC as you suggested. We would 
get some efficiencies in protocol processing, however we would be 
loosing the non-reputation characteristic of the signed ACK.

I think the signed ACK would give a subordinate GC/KS a non-reputable 
proof of key delivery that could be handed off to the master GC/KS. In 
a group scenario this would help manage the group. A GC/KS could store 
this signed ACK as proof of authorization to charge or to verify that 
an Sub GC/KS is acting properly.

I believe the non-reputability property is only important in a group 
scenario. In peer SAs both sides have direct proof of the connection 
and SA creation. In peer SAs it makes perfect sense to switch to a 
keyed MAC for processing efficiencies. I don't think the same thing can 
be said in the Group paradigm.

Thanks

Hugh

On Thursday, Mar 20, 2003, at 22:32 US/Eastern, Ran Canetti wrote:

>
> 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
>
>
Hugh Harney							Sparta, Inc.
[email-masked]						7075 Samuel Morse Drive
(410) 872-1515 x203					Columbia, MD, 21046

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

---

From: Ran Canetti <[email-masked]>
Date: Mon, 7 Apr 2003 14:54:04 -0400

Hugh,

> From [email-masked] Mon Apr  7 08:27:32 2003
> 
> Ran,
> 

Great!

> be said in the Group paradigm.

oops...

i just re-read the draft and my remarks, and my suggestion to remove the
signature in message 3 is wrong. the signature must be there for the core
security of the exchange. The initiator must sign the responder's DH
exponent and/or nonce, othewise some attacks may be possible.
So in the current design the 3rd message must be signed.

Ran

> Hugh

BTW, as a side, I'd like to remark that there is still something unsatisfying 
in the fact that the same signature (in message 3) is used both for the core
security of the exchange and for billing/logging purposes. first, the two
signatures could have different security requirements or certificates. 
furthermore, it would be nice to have a protocol that uses only a single 
member-generated signature whenever the billing-signature is not needed.

Here is a potential (and very sketchy) design that separates the two
signatures. There are either 4 or 5 messages here, depending on whether the
member signature on the key-download is needed. Note however that the KS 
is not required to make any on-line exponentiation until message 3 is
received. This means that the cookie mechanism could be piggybacked on 
messages 2,3 withut additional round trips.
(It is true that the KS has to generate g^y, which requires exponentiation.
but: (a) this can be done in advance, off-line, (b) the KS can use the same
g^y form multiple exchanges within a given time period. in this case the 
per-session freshness is guaranteed by a separate Nonce.)

member -> KS : g^x, ID, Cert
KS -> member : g^y, Nonce 
memver -> KS : sig_member(g^x,g^y,KS,Nonce,member-ID)
KS -> member : sig_KS(g^x,g^y,KS,member-ID,e=ENC(key download info))
member -> KS : sig_member(KS,member-ID,e)  /* this signature is optional */