Subject: RE: [MSEC] De-registration protocol?

From: Ran Canetti <[email-masked]>
Date: Thu, 12 Jul 2001 01:27:02 -0400

Thomas,

I'm all for simplicity... and all for not getting into the guts of the MMD. 

> I am suggesting a simple database (similar to the SAD in functionality)
> that has a collection of information.  It doesn't have to be
> a complete module (as the term "module" implies).
> 
> I don't know if we need a standardized way for a member to talk
> with the MMD.  The IPsec/IKE RFCs does not even talk about *how*
> the SAD is accessed.  Its an implementation issue.

Yes. That's because in IPSEC the SAD is not accessed by protocols that
communicate with other parties (other than  IPSEC/IKE). So the SAD is
rightfully treated as something internal to the peer and not subject to 
standardization. 

It would be great to treat the MMD in the same way. But if we allow the MMD
to be accessed by external protocols that are not part of msec and have
their own communications and security requirements then we may be inviting 
problems for ourselves - since security flaw/features in these other
protocols may adversely affect the security of msec.

> >This my or may not go through the key management protocol, but
> >it should be taken care of. (As usual, if people want to ignore parts of
> >the standard that's ok. But the standard should provide a complete service.)
> 
> 
> Historically, the IETF tries to to make practical and implementable
> standards that vendors can implement.  This process has a better
> chance of suceeding if the issue being solved is well defined
> and does not try to incorporate unncessary componenets/elements.
> 
> If vendors later want certain things to be included in the MSEC standards,
> I'm sure they will bring up the issue.
> 
> We don't want to spend time on parts of MSEC that no one will use,
> even if it means sacrificing the perception of a "complete service".

Agreed. as long as we dont sacrifice security.

> 
> 
> >My feeling is that it may often be convenient to "piggyback" the
> >communication between the member and the MMM (membership management module)
> >on the member-KDC communication (and have the KDC forward the necessary info
> >to the MMM). But this is only an option, as long as the entire service is
> >taken care of.
> 
> 
> Again, I think it is unwise to start talking about communications
> between the MMD and the member.  This may de-focus our current
> discussion on key management, Rekey-Protocol, and the need of
> some membership data within the Rekey-Protocol.

Agreed. At this stage we should only interested in the design of the 
MMD/MMM in as far as it affects the design of the key management protocol. 
(Recall - this discussion started from the question of whether we want 
to support an optional de-register protocol in key management.) 

> 
> Ran,
> 
> I would appreciate if you would not twist the simple MMD
> into an MMM (whatever MMM may be).  Lets just look at the concept of
> a simple collection of membership information that can be used also
> by the Registration Prot., Rekey Prot., and IGMP.
> If it is not needed, then we'll forget about it.
> 
> Each time I suggest something, you seem to turn it into something else :)

Sorry Thomas, I'll try to concentrate on turning other people's suggestions,
at least for a while (until they start complaining)... :)

Ran

> thomas

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

---

From: Thomas Hardjono <[email-masked]>
Date: Fri, 13 Jul 2001 19:37:20 -0400

Ran,

>I'm all for simplicity... and all for not getting into the guts of the MMD.

Well, perhaps there is no guts to it :)  I was wanting only a simple list
of items that may make-up a MMD.

>protocols may adversely affect the security of msec.

My intent with the idea of an MMD is to allow read-access by other
protocols (perhaps IGMP, perhaps not) that are related to multicast.
Thus, for example,in the case that a group utilizes two multicast
addresses (video and audio), then it would convenient for this
relationship to be represented somewhere.  This will help
the Registration protocol to request a join to both addresses
through IGMP.

I also realize that an RFC that simply pronounces that some state-information
belonging to one protocol (eg. IPsec) must not be accessed/modified
by other protocols, does not guarantee anything in the implementation.
That is, saying X in an RFC does not guarantee the coder will do X.
At the most, we can say that if a developer does modify state X,
it will result in a "less-secure" implementation.

Thus, the documents may say, for example, that IGMP *must not* modify MMD,
but can read it.  However, a human implementor may make a mistake
and in fact corrupt the MMD.  This an implementation-quality issue,
not a design flaw.

Again, if the notion of a collection of group-related state-info is
a bad one, we can just throw it away.

My feeling is that since multi-party secure communication using a GSA
is more complicated that pair-wise secure comms., I would expect that
additional state-info (other than the SAD & SPD) will be needed.

Perhaps we may end up with a GSAD (Group SAD), which would be
an extension of the SAD where the relationship between all
three Cat-1/2/3 SAs are coded and stored.

>Agreed. as long as we dont sacrifice security.

Not to be picky, but a "complete service" does not guarantee security
either.

>to support an optional de-register protocol in key management.)

Right.  Hence this new thread.

Thomas
------

---

From: Thomas Hardjono <[email-masked]>
Date: Sat, 14 Jul 2001 15:17:21 -0400

Ran,

I have been following the De-Registration Protocol thread, and my reading
of the postings on this list is that we do NOT want such
a De-Registration Protocol as part of group key management.

My suggestion (for better or worse) is for MSEC to drop the topic
and focus on the other topics ahead (eg. Rekey issues, announcements, etc).

Both our roles are as Co-Chairs to help MSEC meet the deadline, and
I think we should take heed of the consensus in the group about
this particular topic. We have other more pressing issues.

cheers,

thomas
------

---

From: Thomas Hardjono <[email-masked]>
Date: Mon, 16 Jul 2001 17:56:23 -0400

Please re-start the discussion on Deregistration protocol.

I received email this morning complaining about my posting below,
which was considered to be too harsh and preventing the democratic
discussion on this open list.

sigh :)

thomas
------

---

From: Mark Baugher <[email-masked]>
Date: Mon, 16 Jul 2001 15:53:25 -0700

Well, does anyone (else) support the notion of a de-registration protocol?
It's gotten a fair amount of airtime already.

Mark