Subject: [MSEC] Re: IGAP to RFC? (fwd)

From: canetti <[email-masked]>
Date: Thu, 11 Dec 2003 13:57:45 -0500 (EST)

Folks, 

You may want to wait for the revised version.

Thanks,

Ran and Thomas

    > On Wed, 10 Dec 2003, Tsunemasa Hayashi wrote:

    >> Ran and Thomas,
    >> 
    >> Thank you for the informing MSEC of our IGAP draft.  But, we
    >> would like to revise the both sections of abstract and
    >> introduction of the draft. We are explicitly going to describe
    >> the topic IGAP solves. We will update it soon.
    >> 
    >> Regards,
    >> 
    >> Tsune.
    >> 
    >> >>>>> "canetti" == canetti <[email-masked]> writes:
    >> 
    canetti> Folks,
    canetti> The private I-D
    canetti> http://www.ietf.org/internet-drafts/draft-hayashi-igap-03.txt
    canetti> describes IGAP, a group membership authentication protocol
    canetti> that allows users to authenticate themselves to a group
    canetti> center for billing and accounting purposes. The draft
    canetti> provides no means for encrypting or authenitcating the
    canetti> multicasted data.
    canetti> The authors of this I-D have asked the IESG to publish this
    canetti> document as an informational RFC. Since this is a
    canetti> security-related and multicast-repated protocol, the
    canetti> security ADs and the MSEC chairs were asked by the IESG
    canetti> whether we see a danger in endorsing the proposed protocol,
    canetti> either by providing an "insecure work around" to the MSEC
    canetti> protocols, or by interacting badly with MSEC protocols - or
    canetti> alternatively whether we think it is ok to publish the
    canetti> draft as an informational RFC. We would like to poll the WG
    canetti> for opinions. Please take the time to look ad the I-D and
    canetti> opinionate.
    canetti> Thanks,
    canetti> Ran and Thomas

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

---

From: George Gross <[email-masked]>
Date: Sun, 14 Dec 2003 20:18:18 -0500 (EST)

Hi,
	I took a 2nd look at IGAP just to be sure it really was as bad I
thought the 1st time I looked. From a both multicast security and AAA
perspective, IMHO it is unacceptable that the IETF move this forward to
informational RFC status.

	For example, passwords in the clear using PAP as per section
3.2.1. The CHAP authentication is weak against offline dictionary attacks.
No digital signature source authentication mechanism. Lots of opportunity
for fraud, DoS, theft of service.

	The fact that a service provider and a vendor banded together to
build something like this is their private business. I recommend that it
should not be published, as it easily could become a marketware tool, and
obstruct future movement in our industry towards a secure and
comprehensive standard solution.

	For a summary of a design direction and open issues that is
congruent with both the MSEC and AAA standards, I would encourage the
folks who want to pursue MSEC/AAA please please take a look at my
presentation from IETF58 Minneapolis:

http://www.identaware.com/IETF58_MSEC_AAA_v00.ppt

and I would welcome their discussion on its assessment.

br,
	George

---

From: [email-masked]
Date: Wed, 17 Dec 2003 17:03:47 +0100

dear all,
I took a look at the IGAP draft a few moths ago. I don’t know if it has changed
since then. 

My understanding is that one of the goals of  IGAP is to provide receiver access
control (with respect to the multicast delivery tree). This aims at avoiding
fake IGMP report messages and reducing DoS attacks risks against the delivery
tree [T. Hardjono :-)]. 
I noticed that in the Msec charter the receiver access control problem (or group
membership security) has not been quoted. Is this an intended omission?. 

Best regards

Mounir

> >     canetti> for opinions. Please take the time to look ad the I-D and

-------------------------------------------------
Laboratoire Heudiasyc. UMR CNRS 6599
http://www.hds.utc.fr

---

From: canetti <[email-masked]>
Date: Wed, 17 Dec 2003 11:44:37 -0500 (EST)

> membership security) has not been quoted. Is this an intended omission?. 

Depends on what you mean by "group membership security". MSEC charter
certainly addresses access control for the multicasted data.
(That is, it is a requirement that non-members do not have access
to the plaintext data.) However, the charter does not address protecting
the multicast routing infrastructure from DoS attacks. This is indeed
intentional, in order to have a focused set of goals that can be
completed in reasonable time. Once we near completion of the present set of
goals, we can start discussion on rechartering msec to deal also with this
set of problems.

Regarding IGAP, from reading the present draft, it looked like the
intention there is controlling access to the multicasted data, including
billing and accounting, rather than protecting the infrastructure from
DoS attacks. But perhaps we should wait for the revised version for
clarifications.

Best,

Ran

---

From: [email-masked]
Date: Wed, 17 Dec 2003 18:09:15 +0100

Ran, thank you for your useful explanations,

Just a little remark: as far as I know, regarding the term "group membership",
it has been used in the msec WG area to describe both the registration and
rekeying procedures (member-GCKS). The "group membership" term is also used to
describe IGMP/MLD protocols (member-router). On the other hand, the term
"access control" has been used in the msec WG area to deal with multicast data
confidentiality.  In the literature, we also can find the term "access control"
in the work that addresses the security issues in the edge of the multicast
distribution tree.

Mounir

Selon canetti <[email-masked]>:

> > > >     canetti>
> http://www.ietf.org/internet-drafts/draft-hayashi-igap-03.txt

---

From: Brian Weis <[email-masked]>
Date: Thu, 18 Dec 2003 11:58:20 -0800

Folks,

After a lot of thought I'm still having a hard time coming up with a
justification for accepting a document that specifies the use of
clear-text passwords (i.e., use of PAP). That really has no place in new
RFCs, even Informational ones. Issues with clear-text passwords aren't
discussed at all in the Security Considerations document.

On suggestion would to take out the support for PAP, leaving only CHAP.
But I believe that CHAP is probably not so likely to be deployed because
it appear to require new challenge/response message flows. 

Finally, I surprised that IGAP is an update to IGMPv2, which has been
made obsolete by the latest version of IGMP (IGMPv3, RFC 3376). I
understand why it might be desirable to do this in ones product, but I
don't think it's appropriate to specify a new standard adding to an
obsolete version of a protocol.

Brian

-- 
Brian Weis
Strategic Cryptographic Development, ITD, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]