Subject: [MSEC] Re: Comments on MSEC architecture draft

From: Ran Canetti <[email-masked]>
Date: Mon, 14 Apr 2003 00:11:55 -0400

Brian,

See remarks inline. 

> From [email-masked] Fri Apr 11 19:30:04 2003
> 
> Ran,
> 
> Thanks very much for your comments. Please see remarks inline below.
> 
> Ran Canetti wrote:
> > 
> > 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.
> 
> 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. 

ok.

> 
> > 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?
> 
> 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).

I think its a bit more than that: With 1-to-many using MIKEY there is no
real "registration protocol" - the key exchange is initiated by the sender
and consists of a single message from the sender to the recipient(s).
Do we want to accept this way of setting up a 1-to-many session,
say with small number of recipients? (I dont see any reason not to, does
anybody else see any?)

> 
> > * 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.
> 
> OK, I'll add those concepts.
> 
> > * 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.
> 
> OK, will do.
> 
> > * 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.
> 
> 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.)

I very much agree that in principle there is no reason to do exclusively
ipsec. But the architecture should represent reality. And in reality 
we're only doing IPSEC (for now at least). So, I'd think the arch should say
that we currently use IPSEC, and that in the future it may be possible to 
have an an SRTP-based data transmission for MSEC. 
(And if anybody is interested making the future into present then they's
most welcome to!)
  
> 
> > 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?)
> 
> 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.

Again, you're right that in principle it can be in either layer, and it was
appropriate for the SMuG draft to be more generic, being an IRTF draft.
But I think that the current arch should reflect what is actually being done, 
and that's IPSEC.

Best,

Ran

> 
> > * 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.
> 
> OK, will do.
> 
> Thanks,
> Brian
> 
> -- 
> Brian Weis
> Strategic Cryptographic Development, ITD, Cisco Systems
> Telephone: +1 408 526 4796
> Email: [email-masked]
> 

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

---

From: Brian Weis <[email-masked]>
Date: Wed, 23 Apr 2003 02:21:00 -0700

Hi Ran,

> say with small number of recipients? (I dont see any reason not to, does

I agree that we should accept this way of setting up a 1-to-many
session. But I would argue that a single message does take the role of a
registration protocol. This deserves some discussion in the GKMARCH
document which, as I understand it, is meant to expand upon the key
management architecture points in the MSEC Arch document.

> But I think that the current arch should reflect what is actually being done,

Well, this is an interesting question. I think we are coming from
different directions with respect to the purpose of the MSEC
Architecture document. Let me try to explain for what purpose I thought
it was intended. I'm anxious to hear other people's thoughts on the
subject.

Here's the question: should our Architecture documents be constrained to
current working group items, or are Architecture documents supposed to
consider the overall architecture that we are working with?

The MSEC charter does not restrict us to any particular protocols, nor
does it restrict us to a particular layer in the network stack.

Also, It has seemed to me that one of MSEC's valuable contributions has
been to carry forward and further the unpublished architectural work
done in SMuG. Since the SMuG work remains unpublished, but remains the
base of all of our work, we have an obligation to publish it. Indeed
that work needs to be brought up to date to encompass newer work, but
that's a matter of expanding the architecture rather than restricting
it!

One could contrast the MSEC Architecture document with RFC 2401. RFC
2401 very specifically defines one method of securing IP packets, so it
must be very restrictive. But there isn't exactly one method of securing
group traffic. In some sense, the MSEC Arch document is at a higher
level than RFC 2401, and it does in fact point to IPsec as one way of
securing group traffic.

The other point I want to make is that we have in our charter a second
layer of architecture documents which further define data transform
arch, group key mgmt arch, and policy arch. Those indeed should talk
about protocols as examples, and discuss the protocols in more detail.
But there's no reason the high level MSEC Architecture document should
be so restrictive.

To play devils advocate, if on the other hand the the MSEC Architecture
document just was concerned with IPsec, then the MSEC Architecture
document wouldn't be necessary, because RFC 2401 already encompasses how
to encrypt multicast packets and talks about the possible future of
group key management.

In summary, I strongly feel that the MSEC Arch document needs to
describe the general concepts of how to secure group traffic. One of the
main contributions that MSEC can make is to publish general principles
around how to secure multicast, as well as defining protocols (e.g.,
MESP) which fit into that architecture.

As I said above, I'm anxious to hear other opinions.

Thanks,
Brian

---

From: canetti <[email-masked]>
Date: Wed, 23 Apr 2003 14:18:14 -0400 (EDT)

Brian, just a quick reply:

On Wed, 23 Apr 2003, Brian Weis wrote:

...

> management architecture points in the MSEC Arch document.

It definitely should be mentioned and elaborated in GKMARCH.
I also think it is central/important enough to be mentioned in the
general architecture document (albeit more tersely, ofcourse).
Wouldn't you say?

> As I said above, I'm anxious to hear other opinions.

Brian, I didnt mean to say that the architecture document should not
mention several options of what can be done. It definitely should. But it
should also say what is actually being done. no?

BTW, hopefully, the upcoming d-star (data security transforms
architecture)  draft will include a non-ipsec method, so we will not be
restricted to ipsec exclusively.

Ran