Subject: [MSEC] New proposed MSEC Arch Security Considerations

From: Brian Weis <[email-masked]>
Date: Wed, 06 Aug 2003 15:08:30 -0700

This is a reminder that the last call for the MSEC Architecture
documents ends on Friday, August 8. I haven't seen any comments posted
against the -02 document yet.

Also, I noticed that the Security Considerations section is particularly
weak. I'd like to propose the following complete replacement text.

Thanks,
Brian

6. Security Considerations

This document describes a an architectural framework for protecting 
multicast and group traffic with cryptographic protocols. Three
functional
areas are identified within the framework. Each functional area has
unique security considerations, and these are discussed below.

This architectural framework is end-to-end, and does not rely upon the 
network that connects group controllers and group members. As such,
denial
of service, message deletion, and other active attacks on the unicast
or multicast routing infrastructures are not addressed by this
framework.

6.1 Multicast Data Handling

Cryptographic protocols protecting multicast data are responsible 
for providing confidentiality, group authentication, and replay
protection. They should also be able to provide source authentication
to uniquely identify senders to the group. Section 3.1 elaborates on
the security requirements for this area.

6.2 Group Key Management

Group key management protocols provide cryptographic keys and
policy to group members. They are responsible for authenticating and
authorizing group members before revealing those keys, and for providing
confidentiality and authentication of those keys during transit. They
are 
also responsible for providing a means for rekeying the group, in the
case that the policy specifies a lifetime for the keys. They also are
responsible for revocation of group membership, once one or more group
members have had their authorization to be a group member revoked.
Section
3.2 describes the security requirements of this area in more detail.

6.3 Multicast Security Policies

Cryptographic protocols providing multicast security policies are
responsible for distributing that policy such that the integrity of the
policy is maintained. If the policy itself is confidential, they also
are responsible for authenticating group controllers and group members,
and providing confidentiality of the policy during transit.

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

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

---

From: George Gross <[email-masked]>
Date: Thu, 7 Aug 2003 22:00:40 -0400 (EDT)

Hi Brian,

	The rev'd security considerations and the v02 ID look good, and
essentially ready for pub. A few dinkies:

o In section 1.1, the phrase "... then the connectivity of the senders and
receivers may be affected." would be clearer if it said "adversely
affected". BTW, did I correctly infer that the case that you are referring
to is:

   RFC1918_realm_A =>NAT=>public_Internet=>NAT=>RFC1918_realm_B

o Last paragraph in section 1.1 the phrase "by a lack of availability."
may read more easily as "by the omission of that capability from a
deployment."

o Page 20, Reference BHHW is now RFC3547 not an ID ;o)

Honestly, I haven't waded through my e-mail archive to look at every item
we ever talked about on this list, but clearly the major items have been
accomodated and moved to a good place, thank you!

AFAIC, its time to ship it ;o)

br,
	George

---

From: Brian Weis <[email-masked]>
Date: Fri, 08 Aug 2003 09:51:06 -0700

Hi George,

> affected". BTW, did I correctly infer that the case that you are referring

Ok, I've added the word "adversely".

>    RFC1918_realm_A =>NAT=>public_Internet=>NAT=>RFC1918_realm_B

Actually, I think even the case of 
     RFC1918_realm_A =>NAT=>public_Internet
would be a problem, because then the source IP address for an SA
distributed by key management wouldn't match the actual source IP
address on the packet. That's fits into the basic class of NAT issues of
a signaling protocol reporting the original IP address, when actually
NAT has changed it.

> may read more easily as "by the omission of that capability from a

Your wording sounds fine, thanks.

> o Page 20, Reference BHHW is now RFC3547 not an ID ;o)

Got it. :-)

> AFAIC, its time to ship it ;o)

Great! Thanks for all your good input.

Brian