Subject: Re: propose change to address multicast security issue

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 15 Sep 2003 10:00:11 -0400

Lilly,

I am not sure if i responded on this or not; if not i apologize
too swamped at work.
Heres the best alternative IMO; i am crossposting this to the msec
wg mailing list (also CCing the WG chairs in case the mailing list is
closed). To the folks in MSEC we need your help to come up with good
wording in regards to Multicast and security. To break it down, the
4 options that have to be met are:

1. No security - this is pretty obvious, so dont address this.
2. Data integrity - signatures etc.
3. Data authentication - encryption
4. Both integrity and authentication

I have read some of the MSEC drafts which are on the last call. From
what i read, 2-4 above are requirements that can be met for multicast
using IPSEC.
The only open issue seems to be that of source-authentication which is
still a "work-in-progress" in the form of the TESLA protocol.

I have been challenged that if you use both IPsec and Multicast then it
can only be done with no replay protection and no automatic rekeying.
My reading of those drafts leads me to believe this is based on old
data.
So the MSEC folks, can you please help us with the above given
the status quo or soon tobe status quo?
Secondly, what is the status of your different soon-to-be RFCs?
What is the scope of your new recharter?

cheers,
jamal

On Fri, 2003-08-29 at 14:39, Yang, Lily L wrote:
> 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
>
> > --Original Message--
> > From: Jamal Hadi Salim [mailto:[email-masked]]
> > 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
> > >
> > > > --Original Message--
> > > > From: Jamal Hadi Salim [mailto:[email-masked]]
> > > > 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:
> > > > "While TLS supports only unicast, IPsec can support both
> > unicast and
> > > > multicast transports."
> > > >
> > > > Lets leave the rest of the discussion to protocol time.
> > > >
> > > > 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 ]
> > > > >  "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: Tue, 23 Sep 2003 18:22:34 -0700

Jamal -- 
Since the real issue is going to be addressed else where (i.e., protocol) anyway, I don't want us to hold up the framework draft too long unless there is sth fundamentally incorrect here. This is what I suggest in the security section regarding multicast and IPsec, I hope you would agree that it is objective enough :-)

"IPsec can support both unicast and multicast transport. 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]. "

Lily

> -----Original Message-----
> From: Forwarding and Control Element Separation
> [mailto:[email-masked]]On Behalf Of Jamal Hadi Salim
> Sent: Monday, September 15, 2003 7:00 AM
> > 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
> >
> > > --Original Message--