Subject: [MSEC] Comments on http://www.ietf.org/internet-drafts/draft-ietf-msec-gdoiv2-00.txt

From: Mark Baugher <[email-masked]>
Date: Wed, 11 Aug 2004 13:56:49 -0700

Lakshminath, all
    I read the GDOIv2 draft and think we should go back to the drawing 
board.  We do need a version 2 of GDOI but this draft redefines GDOI 
into yet-another group key management protocol - and says so plainly.  
My objections are explained in what follows and my points are numbered.

1. The title of the GDOIv2 I-D is changed from GDOIv1 RFC.  Why rename 
something when the version number changes?  I am the one who named GDOI 
as the "group domain of interpretation" for ISAKMP.  If it is no longer 
a group domain of interpretation for ISAKMP, then I would not call it 
GDOI.  And I'm unaware of any evidence that ISAKMP-based protocols are 
"efficient."  If you really want something that is Group IKE and not an 
ISAKMP DOI, then you should just invent a new protocol and give it a 
new name.  I am interested in developing a second version of GDOI.

2.  I am interested in a second version of GDOI that supports a two 
message exchange, like IKEv2, and better supports devices on home 
entertainment networks.  In fact, I would port some of the functions 
and even some of the design from GSAKMP into GDOIv2 as well as the 
2-message exchange (Child-SA functionality) from IKEv2.  We need to 
support the policy token, perhaps in a form adapted to GDOI (e.g. no 
ASN.1, thank you :).  We need to support GCKS discovery.  And we need 
to support GCKS-GCKS exchanges.

3. The IKEv2 phase 1 functionality is pretty much the focus of this I-D 
and it's the least interesting technical issue in GDOIv2 IMHO.  If 
fact, this should be a no-brainer.  Fixing the proof-of-possession 
protocol in the second version is also pretty much a no-brainer.

4. What's more interesting is the inter-GCKS protocol.  We need to 
discuss a number of alternative designs.  For example, should we do it 
like SMTP, which is a client/server protocol that allows each server to 
act as a forwarding client.  Or do we invent another protocol for 
GCKS-GCKS communication?

5. Also of interest is the policy token, which could use a core/profile 
design to allow application-specific policies such as PERM rights 
management payload.

6. We need to consider how to securely discover GCKS nodes.  (Cathy 
Meadow's successful attack on the GDOIv1 POP involves a GCKS server 
that acts as a client to another GCKS unbeknownst to a requesting 
client/member.)  We can roll our own secure service discovery protocol 
or use a general-purpose standard (rendezvous, upnp,  
http://www.ietf.org/html.charters/svrloc-charter.html - and possibly 
some others).  This needs to be discussed.

So, I want to stop work on this I-D and reset the work on a second 
version of GDOI, which I personally want to contribute to.  We used to 
refer to GDOI as "group IKE" and that is one attribute of GDOI - among 
many.  If Lakshminath or others think we need a better group IKE, then 
I think they and perhaps even the WG might want to pursue it.  But GDOI 
is named in the context of the ISAKMP DOI framework and it is what it 
is.

thanks, Mark

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

---

From: "Dondeti, Lakshminath" <[email-masked]>
Date: Wed, 11 Aug 2004 20:49:04 -0400

Mark,

First, let me say that I am open to changes including the title :-). My 
goal is a group key download protocol similar to IKEv2, so we can reuse 
the basic constructs.  I am open to the use cases you mention below as 
well as adding support for GCKS discovery and inter-GCKS protocol 
(although I am curious if that work should be in a separate document).  
I will try and address the items below. 

> new name.  I am interested in developing a second version of GDOI.
IKEv2 is considerably more efficient than IKE, and removes the DOI 
concept.  I am thinking of GDOIv2 in the same vein.  As you note in one 
of your points below, and I noted at the meeting, the work is mostly 
cut-and-paste from IKEv2 I-D and reuse of constructs from GDOI and 
policy token from GSAKMP.

> to support GCKS-GCKS exchanges.
I am also interested in GCKS discovery and inter-GCKS communication.

> protocol in the second version is also pretty much a no-brainer.
Agreed :-).

> design to allow application-specific policies such as PERM rights
I need to think about PERM fits in here.

I think there is common ground, although we may have slightly different 
view points.  I would rather see us discuss and converge on a single 
IKEv2+GDOI-based protocol rather than adding more KM protocols to the 
mix.  To reiterate, my interest is to design a protocol as efficient as 
IKEv2 without morphing it too much (so we can reuse as much code as 
possible).

best,
Lakshminath

---

From: Mark Baugher <[email-masked]>
Date: Wed, 11 Aug 2004 18:13:53 -0700

Lakshminath,

On Aug 11, 2004, at 5:49 PM, Dondeti, Lakshminath wrote:

> Mark,
>
> First, let me say that I am open to changes including the title :-). 
> My goal is a group key download protocol similar to IKEv2, so we can 
> reuse the basic constructs.  I am open to the use cases you mention 
> below as well as adding support for GCKS discovery and inter-GCKS 
> protocol (although I am curious if that work should be in a separate 
> document).  I will try and address the items below.
> Mark Baugher wrote:
>
>> Lakshminath, all
> concept.
Two ideas are juxtaposed that may have not correspondence.  It is true 
that IKEv2 has a more efficient phase 1 and phase 2 negotiation.  And 
it is also true that it removes the DOI concept.  It is not true that 
IKEv2 is more efficient because it removes the DOI concept.

We want the DOI concept since we want to use a core key establishment 
framework with a profile, for groups in our case.  If you throw out the 
DOI concept in IKEv2 in one door, it comes in through another, because 
you are using IKEv2 as a core protocol and extending with a distinct 
profile, e.g. with some new payloads.  At least with ISAKMP, this is 
explicit.

> I am thinking of GDOIv2 in the same vein.  As you note in one of your 
> points below, and I noted at the meeting, the work is mostly 
> I think there is common ground, although we may have slightly 
> different view points.  I would rather see us discuss and converge on 
> a single IKEv2+GDOI-based protocol rather than adding more KM 
> protocols to the mix.  To reiterate, my interest is to design a 
> protocol as efficient as IKEv2 without morphing it too much (so we can 
> reuse as much code as possible).

I have not heard anyone say that they cannot deploy GDOI because it is 
not efficient enough in its exchanges.  We have seen the need for a 
simple 2-message key establishment and have MIKEY for this purpose.  
The 2-message case is a specialized need that has to do with assuming 
only one (e.g., SIP) roundtrip available for the key establishment.  
That's fine, but this efficiency comes at a cost in terms of identity 
protection, i.e. there are good reasons for having a 3 or 4 message 
exchange from a security standpoint.

I'd say that if all you want is an IKEv2 type of exchange, then why not 
write a less ambitious I-D that simply adds a new, combined Phase 1 and 
Phase 2 for GDOI.  You could call it "a new Phase 1 and Phase 2 
exchange for GDOI."

cheers, Mark

---

From: "Dondeti, Lakshminath" <[email-masked]>
Date: Thu, 12 Aug 2004 16:57:20 -0400

Mark,

I still think we are not that far apart, although I am realizing that 
there are some differences in our approach to this.   

I am starting out with a simple spec, but Ran's and Hugh's suggestions 
for TESLA and policy token (you also suggest this, right?), EAP, and 
other requirements such as distributed GCKS operation (the old intra-gkm 
I-D by Thomas, Brad and Inder is what I have in mind, at least to start 
with) and GCKS discovery look to be some additional features, that might 
make this a fairly bulky document.   As I noted in my previous email, 
the last two topics may be separated from a "core spec."

Please see inline for some additional thoughts:

Mark Baugher wrote:

>>> into yet-another group key management protocol - and says so 
>>> plainly. My objections are explained in what follows and my points 
>>> are numbered.
>>>
> framework with a profile, for groups in our case.  If you throw out 
> the DOI concept in IKEv2 in one door, it comes in through another, 
> because you are using IKEv2 as a core protocol and extending with a 
> distinct profile, e.g. with some new payloads.  At least with ISAKMP, 
> this is explicit.
>
With distinct ports being used, for instance in case of IKE and GDOI, my 
understanding is that we can do without the DOI field (so port 500 would 
indicate an IKE/IKEv2 message and 848 would mean GDOI message, 
irrespective of what's in the DOI field; of course following the specs 
strictly would mean that we still check what's in that field - w.r.t. 
IKE and GDOI only - and reject messages with illegal values).

Although, I think I understand what you mean - in that the DOI is there 
explicitly or implicitly.  Anyway, if you care to clarify your thoughts 
on this further, I will appreciate it!

>> protocol as efficient as IKEv2 without morphing it too much (so we 
>> can reuse as much code as possible).
>
>
Here is my perspective of this: IKEv2 is simpler, has lower latency, 
simpler to analyze, reliable, flexible, compared to IKE (this 
characterization is from ikev2-14, put in one sentence :-) ).  If that 
is the justification for someone to implement IKEv2, it is natural to 
look for a group key download protocol that is along the same lines (in 
other words, why implement/deploy GDOI - based on IKE, which is supposed 
to be replaced by IKEv2, whenever that happens).

So, In a way, I set out to do what you suggest below (would give it a 
shorter name though :-)), but looks like will end up adding some new 
features.

regards,
Lakshminath

> I'd say that if all you want is an IKEv2 type of exchange, then why 
> not write a less ambitious I-D that simply adds a new, combined Phase 
> 1 and Phase 2 for GDOI.  You could call it "a new Phase 1 and Phase 2 
> exchange for GDOI."
>
> cheers, Mark
>
>>
>> best,
>> Lakshminath
>>

---

From: Mark Baugher <[email-masked]>
Date: Thu, 12 Aug 2004 16:41:27 -0700

Lakshminath,

On Aug 12, 2004, at 1:57 PM, Dondeti, Lakshminath wrote:

> for TESLA and policy token (you also suggest this, right?),

I think we need to at least consider whether to add a policy token 
payload in GDOI, yes.

> EAP,

I don't know why EAP is in the picture.

> and other requirements such as distributed GCKS operation (the old 
> intra-gkm I-D by Thomas, Brad and Inder is what I have in mind, at 
> least to start with)

Like I said, some protocols such as SMTP allow the entity to act as a 
client and a server, perhaps GDOI's protocol can allow a GDOI entity to 
act as a member or a controller, i.e. we use the Phase 1 and Phase 2 
exchanges as a GCKS-GCKS protocol.  (I would call this an "inter-GCKS" 
protocol and I don't recall the "intra-GCKS" protocol very well from 
the SMuG days).

> and GCKS discovery look to be some additional features, that might 
> make this a fairly bulky document.

Maybe.  I think we would need to get into the work to see what's 
involved.

> As I noted in my previous email, the last two topics may be separated 
> from a "core spec."

I think the core spec is RFC 2408 - at least that's one way to look at 
it.  The change to the core spec would be the 2-message exchange.

>> Two ideas are juxtaposed that may have not correspondence.  It is 
>> true that IKEv2 has a more efficient phase 1 and phase 2 negotiation. 
>>  And it is also true that it removes the DOI concept.  It is not true 
>> that IKEv2 is more efficient because it removes the DOI concept.
>>
> With distinct ports being used, for instance in case of IKE and GDOI, 
> my understanding is that we can do without the DOI field (so port 500 
> would indicate an IKE/IKEv2 message and 848 would mean GDOI message, 
> Although, I think I understand what you mean - in that the DOI is 
> there explicitly or implicitly.  Anyway, if you care to clarify your 
> thoughts on this further, I will appreciate it!

The DOI field is the outward expression of the ISAKMP design, which 
provides a framework that gets bound to a DOI having specific payloads 
plus optional additional extensions such as new exchanges.  It seems to 
be a clean approach to extending a pairwise key establishment system to 
take a "group key" approach to multicast key establishment.  In this 
extension, the point-to-point key management protocol serves to 
establish a group key at a group member in addition to a pairwise key, 
which forms the security association between member and controller.  
With the DOI field, it is possible to build this right on top of the 
existing protocol, e.g. IKEv1.  Without the DOI field, then the design 
is not so clean.

IKEv1 never seemed to accept its fate as an ISAKMP DOI.  IKEv1 wanted 
to be the framework.  IKEv2 eliminates the framework.  But it may be 
straightforward to extend an IKEv2 implementation to offer GDOI 
functionality.

>
>>> I am thinking of GDOIv2 in the same vein.  As you note in one of 
>>> your points below, and I noted at the meeting, the work is mostly 
>>> different view points.  I would rather see us discuss and converge 
>>> on a single IKEv2+GDOI-based protocol rather than adding more KM 
>> I have not heard anyone say that they cannot deploy GDOI because it 
>> is not efficient enough in its exchanges.  We have seen the need for 
>> a simple 2-message key establishment and have MIKEY for this purpose. 
>>  The 2-message case is a specialized need that has to do with 
>> assuming only one (e.g., SIP) roundtrip available for the key 
>> establishment.  That's fine, but this efficiency comes at a cost in 
>> terms of identity protection, i.e. there are good reasons for having 
>> a 3 or 4 message exchange from a security standpoint.
>>
> look for a group key download protocol that is along the same lines 
> (in other words, why implement/deploy GDOI - based on IKE, which is 
> supposed to be replaced by IKEv2, whenever that happens).
>

I think that the narrower effort of just adding an IKEv2 Phase 1 or 
Phase 1/2 to GDOI would meet your objectives.  You can leave the 
policy, GCKS-GCKS protocol, and GCKS discovery to a larger effort that 
should use the name "GDOIv2."

Mark