Subject: Re: [MSEC] MSEC v01 arch, comments on section 2 (fwd)

From: George Gross <[email-masked]>
Date: Wed, 25 Jun 2003 07:18:26 -0400 (EDT)

Hi,
	With Mounir's permission, I'm forwarding an exchange we had wrt/
securing IGMP/MLD/PIM as part of MSEC...

	George

---------- Forwarded message ----------
Date: Wed, 25 Jun 2003 05:12:18 -0400 (EDT)
From: George Gross <[email-masked]>
To: [email-masked]
Cc: George Gross <[email-masked]>
Subject: Re: [MSEC] MSEC v01 arch, comments on section 2

Hi Mounir,

	My goal with the section 2 questions was to tease out some of the
unspoken assumptions that lurk in the architecture if one were to actually
deploy MSEC.

	While Brian and Tom have yet to weigh in on this topic, I imagine
that adding refs to the GSEC RG work is a beginning, but not all that
needs to be said in the arch doc wrt/ to this comment. I think the
architecture doc has to describe, and the MSEC protocols have to define an
extensible mechanism(s) to encapsulate an opaque IGMP/MLD
authorization/authentication information payload within the {GSAKMP, GDOI,
whatever} key management protocol to each group member.  With this
coupling, I think that the multicast session becomes far more secure.

securing PIM or the multicast routing protocol du jour is another
interface to MSEC that needs to be mentioned in the arch doc, and perhaps
ultimately standardized...

br,
	George

On Tue, 24 Jun 2003 [email-masked] wrote:

> Hi George,
>
> I think that you asked very intersting questions with respect to section 2.
>
> For your follwong questions:
> >   2 - how to assure the security of the IGMP, MLD, and the multicast
> > routing protocol(s) like PIM?
> >
>
> I think Group Membership (MLD, IGMP) security issues as well as multicast
> routing porotocols security issues are adressed (exclusively) in GSEC RG. For
> the security issues in multicast routing protocols, it seems that there is a
> specific solution for each protocol.
>
> May be next GKarch draft can mention the drafts "draft-irtf-gsec-igmpv3-
> security-issues-01" and "draft-irtf-gsec-pim-sm-security-issues-01" as they
> both propose extending GDOI to secure respectively IGMP and PIM-SM.
>
> However, I think that securing Group membership and multicast protocol
> protocols basing on GkmArch may not be a good thing as it makes the securty
> solution (for MLD and IGMP ,and e.g. PIM) dependent on GKmArch . Decoupling (at
> least partially) GkMArch form the other two issues can ensure a multi-
> (independent)level security need.
>
>
> Mounir
>
> -------------------------------------------------
> Laboratoire Heudiasyc. UMR CNRS 6599
> http://www.hds.utc.fr
>

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

---

From: [email-masked]
Date: Wed, 25 Jun 2003 15:44:00 +0200

Hi all,
Hi George,
It may be an intersting idea. However, the GCKSs are not MLD/IGMP-capable. 
Group membership managment (MLD/IGMP) process is typically performed by 
multicast routers. The drafts I mentioned in the previous e-mail suggest 
enxtending GSA to multicast routers...Why not..

Mounir

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 25 Jun 2003 09:45:22 -0400

There are several old expired drafts that discussed IGMP and PIM 
security.  Most of the folks in MSEC are aware of that work, yet decided 
to not include protocol security in the charter.  It may belong in a 
separate WG IMO (e.g., IPSEC WG designs protocols for data protection 
and RPSEC discusses routing protocol protection).

<GSEC co-chair hat on>  You are welcome to bring any new ideas (or 
revise old I-Ds and bring them for discussion) to the GSEC meeting; most 
MSEC regulars will show up and the RG might decide how to proceed <GSEC 
co-chair hat off>.

I think the MSEC architecture I-D should proceed with its current scope.

regards,
Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 25 Jun 2003 09:53:22 -0400

Mounir,

I assume you are talking about a separate GSA for routing protocol 
protection.

Lakshminath

[email-masked] wrote:
>>>I think that you asked very intersting questions with respect to section
>>
>>2.
>>
>>>routing porotocols security issues are adressed (exclusively) in GSEC RG.
>>
>>For
>>
>>>the security issues in multicast routing protocols, it seems that there is
>>
>>a
>>
>>>security-issues-01" and "draft-irtf-gsec-pim-sm-security-issues-01" as
>>
>>they
>>
>>>protocols basing on GkmArch may not be a good thing as it makes the
>>
>>securty
>>
>>>solution (for MLD and IGMP ,and e.g. PIM) dependent on GKmArch . Decoupling
>>
>>(at
>>

---

From: [email-masked]
Date: Wed, 25 Jun 2003 16:01:59 +0200

Lakshminath
Yes, you are right to mention it. Multicast routers do not get TEK and KEKs ( 
they are not trusted in the viewpoint of data secrecy in particular) 

Mounir

---

From: George Gross <[email-masked]>
Date: Wed, 25 Jun 2003 08:22:51 -0400 (EDT)

Hi Lakshminath,

	inline below...

br,
	George

> MSEC regulars will show up and the RG might decide how to proceed <GSEC

regretably, I won't be in Vienna, ;o( no doubt it would be great place to
visit

please let me know what comes out of those discussions...

> I think the MSEC architecture I-D should proceed with its current scope.

I am not asking that the MSEC architecture expand its scope; rather it
should be _completed_ to describe the requirement to have a mechanism/hook
through which this type of information can be included/tunneled in the
MSEC protocols without defining its structure or semantics (i.e.  it is
opaque and to be defined). In the short term, this is likely to be as
simple as reserving a TLV payload type for this future use.

	In the arch ID, the text should simply acknowledge that there is a
set of entities, multicast routers, that must participate in the group
membership's multicast data distribution and they do so securely under the
direction of the GKCS. Unlike point to point IPSEC which is independent of
the routing infrastructure, in MSEC there is a concept of group membership
that has a direct relationship with the multicast routing tables. The text
could be written in very general terms. The text should allow the
flexibility of allowing either the multicast router or the group member
securely initiating the group join/leave routing table update.

---

From: [email-masked]
Date: Wed, 25 Jun 2003 16:44:03 +0200

George,
Just a little remark,
The concept of group membership in the view point of MsecArch is different from 
that of MLD/IGMP. I think this was explicitly mentioned in the last draft of 
GKMArch  

Mounir

---

From: Thomas Hardjono <[email-masked]>
Date: Wed, 25 Jun 2003 11:04:34 -0400

I think the model underlying the GCKS was that it *could* be the key server 
for routers (in PIM or IGMP), though it would use a different instance of 
the GSA.

However, I do agree that an architecture-level document such as this could 
benefit from some explanation with respect to Group Membership Management 
security.

Specifically on GDOI, if GDOI was used for router-entities (vs. 
hosts/humans), then it would be interesting to see if the Policy Token 
could carry the opaque "IGMP/MLD authorization/authentication information 
payload".

In general, there is still this open problem (I think) about the best way 
to communicate authorization information to multicast-routers, both an the 
core and edge of the network.

thomas
------

---

From: Mark Baugher <[email-masked]>
Date: Wed, 25 Jun 2003 10:27:46 -0700

hi
   Pardon my lateness in responding, I've been out of the office.

At 11:04 AM 6/25/2003 -0400, Thomas Hardjono wrote:

>I think the model underlying the GCKS was that it *could* be the key 
>server for routers (in PIM or IGMP), though it would use a different 
>instance of the GSA.
>

There is no IGMP security work going on inside any IETF working group to my 
knowledge, is there?

Mark

---

From: Mark Baugher <[email-masked]>
Date: Wed, 25 Jun 2003 10:31:54 -0700

Lakshminath,

At 09:45 AM 6/25/2003 -0400, Lakshminath Dondeti wrote:
>separate WG IMO (e.g., IPSEC WG designs protocols for data protection and 
>RPSEC discusses routing protocol protection).
>
><GSEC co-chair hat on>  You are welcome to bring any new ideas (or revise 
>old I-Ds and bring them for discussion) to the GSEC meeting; most MSEC 
>regulars will show up and the RG might decide how to proceed <GSEC 
>co-chair hat off>.

Thanks.  I should add that the issue of IGMP security has been raised at 
least twice and rejected as a work item by the IETF.  That does not mean 
that it should not be considered, but it should be considered in GSEC (and 
informed by the previous discussions in GSEC and MAGMA), not in msec.

Mark

---

From: canetti <[email-masked]>
Date: Fri, 27 Jun 2003 01:48:31 -0400 (EDT)

George,

Sorry for jumping into the discussion late.

I'm very glad you brought up this point.
One of the main design principles of msec (coming from smug) is that the
security we provide should be end-to-end, and furthermore should be as
indepenent as possible from the underlying routing mechanism.

Protecting the routing mechanism provides "only" protection against DoS
(ie, it is not needed for guaranteeing secrecy or authenticity of thedata).
While this is a very important concern, the feeling was that this should
be dealt with on a different level than the basic msec goals of
guaranteeing secrecy and authenticity of the data.

So, in other words, the lack of discussion of the routing mechanisms and
their protection is intentional.

I'd suggest that some text clarifying this point be added to the document.
(The point will be elaborated on in the upcoming requirements document;
still it may be good to refer to it also in the architecture document.)

Hope this clarifies.

Ran