Subject: Re: propose change to address multicast security issue

From: "Putzolu, David" <[email-masked]>
Date: Thu, 28 Aug 2003 10:59:58 -0700

I'd like to resolve this question asap.  Does anyone
else have any input on which of the following two
alternatives towards documenting relevant security
solutions for ForCES?

Are there any other unresolved issues people have with
the framework document?  Speak now or forever hold your peace!

-David

> -----Original Message-----
> From: Jamal Hadi Salim [mailto:[email-masked]] 
>
> The text i see fit is:
> "While TLS supports only unicast, IPsec can support both unicast and
> multicast transports."
> 
> Lets leave the rest of the discussion to protocol time.

vs. 

> > [ new text ]
> >  "IPsec can support both unicast and multicast transport. 
> However, RFC 2401 [14] acknowledged that it did not specify 
> complete support for IP multicast. At the time this document 
> was published, MSEC working group is actively working on 
> standardizing protocols to provide multicast security [17]. 
> Multicast-based solutions relying on IPsec should specify how 
> to meet the security requirements in [3].  "
> >
> > Adding the following to Section 9: Informative References:
> > [17] Hardjono, T. and Weis, B. "The Multicast Security 
> Architecture", work in progress, August 2003, 
> <draft-ietf-msec-arch-03.txt>.
> >
> > I would like the two of you and the WG review this. If 
> satisfactory, I would roll all the recent changes per 
> discussion on the list into v09 and ask for IESG review on it.
> >
> > Thanks,
> >
> > Lily
> >
>

---

From: "Yang, Lily L" <[email-masked]>
Date: Fri, 29 Aug 2003 11:39:08 -0700

Hi, Jamal -- 

I don't think I am making any specific assumptions here. I am merely ducumenting the fact that IPsec itself may not be sufficient and MSEC WG is looking at the issues. I do intend to leave all the details to the protocol discussion. 

I am glad that you brought this important issue to our attention at the first place. So it just puzzles me why we shouldn't at least capture this high level issue in the framework so that protocol designers are aware of it.

Lily

> Sent: Thursday, August 28, 2003 9:40 AM
> To: [email-masked]
> Subject: Re: propose change to address multicast security issue
> 
> 
> Lily,
> 
> Unless you are making assumptions about how multicast is to be
> used with IPSEC in a Forces protocol, you shouldnt be pointing
> out issues with "multicast and IPSEC"; just as you shouldnt 
> be worrying
> about TLS and its unfitness in some unicast protocol usage. Leave that
> to the protocol discussion.
> 
> cheers,
> jamal
> 
> PS: MSEC IETF group completed its chartered work and was shutdown. So
> all those docs are awaiting IESG approval to go RFC. Theres a recent
> activity to recharter MSEC.
> 
> On Thu, 2003-08-28 at 12:26, Yang, Lily L wrote:
> > Hi, Jamal --
> > But I believe it is also very important to point
> > out the fact that IPsec itself does not fully address
> > multicast security issues (that is exactly why there is MSEC
> > group working on these issues). So it is simply not sufficient
> > to just say "use IPsec for multicast".
> >
> > Lily
> >
> > > Sent: Thursday, August 28, 2003 4:09 AM
> > > To: [email-masked]
> > > Subject: Re: propose change to address multicast security issue
> > >
> > >
> > > Hi Lilly,
> > >
> > > Sorry - meant to respond to your earlier yesterday, but work
> > > comes first.
> > >
> > > The text i see fit is:
> > > cheers,
> > > jamal
> > > On Wed, 27 Aug 2003, Yang, Lily L wrote:
> > >
> > > > To address the issue over multicast security, I propose the
> > > following changes to framework section 7.2.3:
> > > >
> > > > [old 3rd paragraph]
> > > > "IPsec can support both unicast and multicast transport. When
> > > >     multicast is used, IPsec can be used with manual 
> keying with no
> > > >     replay protection and no automatic rekeying.  This 
> meets  the
> > > >     confidentiality and integrity requirements.  Multicast-based
> > > >     solutions relying on IPsec should specify how rekeying
> > > and replay
> > > >     protection are provided.  "
> > > >
> > > > [ new text ]

---

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Fri, 29 Aug 2003 13:58:08 -0700

2 comments on this issue...

I thought the initial point was that this issue was not sufficiently
covered
and so the authors should do some research and add some text to clarify
this.
The text sent out by Lily shows that the authors did their due diligence
in
terms of research and added appropriate text/pointers. Also, the text
looks
very neutral to me, does not seem to be biased in anyway.

The other comment based on experience on the Requirements RFC is that
the
Security Directorate would prefer the security text be as explicit as
possible
and not miss out any important details. So if the text doesn't reflect
that the authors are aware of MSEC and looked into this, it might be a
problem
with getting IESG approval.

My 2 cents
Hormuzd

-----Original Message-----
From: Putzolu, David 
Sent: Thursday, August 28, 2003 11:00 AM
To: [email-masked]
Subject: Re: [FORCES] propose change to address multicast security issue

-David

vs.