Subject: [MSEC] security problem in GDOI proof of possesion (and fix)

From: "Catherine A. Meadows" <[email-masked]>
Date: Fri, 30 Jan 2004 15:47:39 -0500 (EST)

This message describes a security problem that Dusko Pavlovic and
I found in the GDOI proof of possession while doing a formal analysis,
as well as a proposed fix, which we have developed
in cooperation with Ran Canetti and the
GDOI authors.  Comments are welcome.

1.  Background.  Proof-of-possession prvides and optional means of providing
authorization for group members.  For example, suppose that a group member
has made arrangements with a content provider, and then wants to join a
group that distributes the content.  Proof-of-possesion provides the means
by which the member can prove to the GCKS that the content provider has authorized
it to join the group.

Proof-of-possession works as follows. A member obtains a credential
containing certain privileges, a public key, and a new identity (this new
identity could actually be the key, as in SPKI/SDSI).  The member also receives the corresponding private key. The  member joins a group by
initiating a groopkey-pull protocol with a GCKS
that is encrypted and authenticated with a Phase 1 IKE key.   Ownership
of the private key (and hence possession of the authorizations) is given
by signing two nonces, one provided by the member, and one by the GCKS,
along with the prepended string "pop" (to prevent type confusion attacks.
This is call proof-of-posession, or POP.

A protocol with member PoP (slightly simplifed) appears as follows.
All information is assumed to be encrypted and authenticated with the Phase 1
key.

1. M  --> GCKS :   Ni, ID  
ID is the identifier of the group
2. GCKS --> M  :  Nr, SA
SA is the security association of the current group key
3. M --> GCKS  : CERT, POP = S_P(hash(pop,Ni,Nr))
CERT is the certificate containing the new identity and authorizations,
POP is the signature with the key corresponding to the new identity
on the nonces Ni and Nr
4. GCKS --> M : KD
KD is the  the actual keying material, and SEQ is a sequence
number

Suppose now that there are two groups.  Group 1 is managed by a rogue GCKS
who does not have authorization to join Group 2.  Let A be a member with
a CERT that gives it authorization to join both Groups 1 and 2,let B be the GCKS of group 2, and let I be the Group 1
GCKS.  I can use the PoP to pass off A's credentials as its own, as follows:

1.  A  --> I : Ni, ID1

A requests to join I's Group 1, sending a nonce Ni

1.' I_member --> B :  Ni, ID2

I requests to join B's group, forwarding A's nonce Ni

2.' B --> I_member :  Nr', SA'

B  responds to I with its nonce Nr'

2.  I --> A  :  Nr', SA

I responds to member A, but using B's nonce Nr'

3.  A  -->  I:   CERT(for A's ID P in Group 2), POP = 
S_P(hash(pop,Ni,Nr'))

A responds to I with a POP taken over A's and B's nonce

3.'  I_member --> B:   CERT(for A's ID in Group 2), POP = 
S_P(hash(Ni,Nr'))

I as a member responds to B, using A's CERT and POP

4.  B --> I_member :  KD

B sends keying information for Group 2
to I under impression the identity in A's  certificate
belongs to I

step 4' is not necessary and isn't included

Proof-of-possesion is also optionally provided for the GCKS, and other
attacks involving a dishonest group member impersonating a GCKS are
possible if that option is used.

We are recommending the following solution for fixing this problem:

The point of proof-of-possession is to prove that the owner of the
identity associated with the Phase 1 key is the same as the owner of the
key distributed in the CERT.  One way of achieving this is to use a PoP
that could only be constructed with a knowledge of the Phase 1 key and
the CERT key.  The version of the PoP we recommend using is thus of
the following form:  S_P(hash("pop",SKEY_A,Ni,Nr)), where SKEY_A is a
key derived from the Phase 1 key, Ni is the member's nonce, and Nr is
GCKS's  nonce.

We are working on an ID describing the problem and the
recommended change, with the ultimate
goal of including it in the next GDOI RFC.  Comments are welcome.

Cathy Meadows

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