Subject: [MSEC] Comments on MSEC architecture draft

From: Ran Canetti <[email-masked]>
Date: Tue, 8 Apr 2003 16:53:27 -0400

Here are some remarks on the MSEC architecture draft
(http://www.ietf.org/internet-drafts/draft-ietf-msec-arch-00.txt).
In all, the draft looks good, but there are several issues that seem to
require addressing.

I encourage people to give this document a thorough reading, it is an
important one.

Ran

* The document does not address MIKEY and how it is incorporated into the
MSEC architecture. True, MIKEY is a belated addition to the working group,
and it works a bit differently than GDOI and GSAKMP. Still, we should 
fit it in the current framework (or alternatively decide that it doesnt fit).

One option would be to use MIKEY as a registration protocol; but 
then: (a) MIKEY should be able to generate a GSA in the same way that GDOI
and GSAKMP do. (b) There should probably be a rekey (or, "PUSH") protocol
associated with MIKEY. 

However, this option does not cover the use of MIKEY for small groups with
single sender, potentially without a GCKS at all. Do we wantto includethis
option within the MSEC architecture or do we want to leave it out for now?
Any thoughts/suggestions?

* The framework should probably mention explicitly that in some scenarios
a member may need to establish additional secure unicast connection with 
the GCKS, on top of the registration protocol. These may be to "resynch"
in case of running out of synch regarding group keys, or to "de-register"
in case this is relevant.

* Regarding the registration SA: It should probably be discussed whether the
Reg SA should be long-lived (ie, should exist throughout the lifetime of the
group) or short-lived (ie, should exist only as long as the registration 
protocol is alive). 
The long-lived case is less scalable since the GCKS needs to maintain an SA
for each member. (This can be somewhat less of a problem for distributed
designs). If short-lived SA is used then it should be said that a new SA is
set-up for each "resynch" or "de-register" connection with the GCKS. 

* Regarding the data SA: The recent advancements regarding structure of the
data SA in conjunction with IPSEC should probably be reflected in this 
document. Full details can be refered to the MESP document (which will
probably change its name to the data security architecture document), 
but at least the principles (including the fact that we are using the 
ESP format with the ESP protocol number) are definitely part of the general 
architecture.

Also, currently the document says nothing on how the data is actually protected,
it is not even mentioned in which layer of the communication the protection
takes place. It should probably be said that we use IP layer protection,
and more specifically that the transforms we use are compatible with ESP and
AH. (In fact, do we want to use AH at all in the context of MSEC, or does
ESP answer all our needs?) 

* Section 5 (security services) is probably more appropriate for a
requirements document, but in lack of such (at least so far), it should
probably stay.

* The reference [CP99] should probably be changed to 

 [CCPRRS] Canetti R., Cheng P. C., Pendarakis D., Rao, J., Rohatgi P.,
   Saha D.,  "An architecture for secure IP multicast", NDSS 2000.

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

---

From: Brian Weis <[email-masked]>
Date: Fri, 11 Apr 2003 08:36:44 -0700

Ran,

Thanks very much for your comments. Please see remarks inline below.

> and GSAKMP do. (b) There should probably be a rekey (or, "PUSH") protocol

Regarding (a), both MIKEY and GKMARCH state that MIKEY fits into the
architecture as a registration protocol, so it clearly does fit into the
MSEC architecture. A description of how and why it fits as a
registration protocol protocol probably belongs in the GKMARCH document
rather than the MSEC Arch document.

Regarding (b), the GKMARCH does point out that a re-key protocol is
optional for a GKM system. That has been MSEC's intent. However, the
MSEC Arch draft appears to be missing that discussion so I'll add it. 

> Any thoughts/suggestions?

One can consider the sender as acting as a GCKS to his receivers. I
think that fits the architecture. It would be a good idea to mention
that the role of a GCKS can be played by a group member (e.g., sender).

> in case this is relevant.

OK, I'll add those concepts.

> set-up for each "resynch" or "de-register" connection with the GCKS.

OK, will do.

> ESP format with the ESP protocol number) are definitely part of the general

Shouldn't the MSEC architecture be agnostic as to what types of data
security SAs are used? I can imagine SRTP SAs for example, or other data
security protocols which are not related to IPsec at all.

(For that matter, I wonder if the data security arch document should
also not be so closely tied to IPsec. Maybe there does need to be a
separate document there.)

> ESP answer all our needs?)

But from an overall architecture perspective a data security SA could be
at any layer of the protocol, can't it? For example, I've run into
scenarios where the old SMuG concept of AMESP would have been useful.
I'd rather we left it that way in the architecture.

>    Saha D.,  "An architecture for secure IP multicast", NDSS 2000.

OK, will do.

Thanks,
Brian

-- 
Brian Weis
Strategic Cryptographic Development, ITD, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

---

From: Mark Baugher <[email-masked]>
Date: Tue, 22 Apr 2003 13:05:54 -0700

At 04:53 PM 4/8/2003 -0400, Ran Canetti wrote:

>One option would be to use MIKEY as a registration protocol;

When we admitted MIKEY as a work item to msec, we said that it was a 
registration protocol, but there is another dimension to this 
question:  Will group security be used in IP telephony?  Most of us in 
business use conference calls almost as much as point-to-point calls.  Do 
we expect that an ad-hoc or "meet me" conference to use group keys?  Will 
we continue to have middle boxes such as multipoint control units when we 
add security?  I think this is worthy of some consideration.

Mark

>but