Subject: [MSEC] MSEC policy token and AAA

From: George Gross <[email-masked]>
Date: Tue, 9 Sep 2003 21:48:52 -0400 (EDT)

Hi,
	In previous e-mails, I've suggested that there is a fairly
strong coupling between Diameter-based AAA and the MSEC generic policy
token. This e-mail opens the discussion on that topic, with a few sample
use cases setting the context. The goal is to build a set of requirements
and a framework that allows:

1) the large-scale commercial deployment of a secure multicast group
spanning multiple administrative domains,

2) has the future potential to work as an extension within the Diameter AAA
framework that does group membership authentication, authorization,
and accounting. where feasible, it should be possible to selectively reuse existing
AVP syntax and semantics from the network access, EAP, and accounting applications.

3) the policy token can express numerous group related attributes, both
security related and still others that are not security related. Examples
of the latter include: rekey reliable multicast transport parameters,
constraints on time and pricing, QoS parameters, group owner contact
info...

4) allows Enterprises to continue to use their existing employee authentication
methods, and allows gradual migration to PKI based authentication.
In particular, this requirement includes the ability to use the NAI as an
end user identifier.

5) The policy token must be extensible to assure that new attributes
can be introduced without breaking an embedded base of MSEC endpoints that
understand only earlier versions of the policy token.

6) allows a group membership comprised of a mixture of GSAKMP and GDOI
endpoints, i.e. the registration protocol selected by each endpoint
may be different, but the data SA and its keying material is homogenous
across the group's endpoints.  BTW, I don't rule out having MIKE endpoints
in the group too, but that seems like a stretch goal.

7) able to express multiple alternative policy profiles, any one of which
is acceptable in a Request To Join sent to the GCKS.

8) can support roaming/mobile users as a natural consequence of the design
(i.e. roaming is when the end user visits a foreign admin domain/ISP).

9) has some limited form of backward compatibility with some portions of
the GSAKMP policy token encoding found in msec-tokenspec-sec-00.txt and
the policy related aspects of GDOI RFC3547.

10) easily able to translate group policy into other representations suitable
for use in a group announcement.

11) minimizes the use of embedded IP-v4 addresses within the policy token that would
need translation at NAT gateways.

12) able to acommodate the "pull", "push", and "agent" authorization models.

	Folks on this list are welcome to chime in with additional requirements,
just keep in mind the spirit of the main requirement: large-scale commercial secure
multicast group AAA across multiple administrative domains.

While designing a Diameter application extension for secure multicast service remains
on the horizon, it still helps to keep that in mind when organizing the policy token's
design.  So what does the Diameter oriented architecture look like? Here's a
representative diagram of a MSEC/AAA architecture composed of:

- three administrative domains: ISP[x], ISP[y], and home admin domain A
- three Diameter servers: X, Y, and A with peer-to-peer Diameter connections
- Group owner server for the Group "Z"
- Group "Z" group security association stradding the three admin domains
- Home administrative domain's Authentication Server A, speaking EAP
- GDOI GCKS in ISP[x] domain
- GSAKMP GCKS in ISP[y] domain
- bi-lingual GCKS in home domain A
- six Group Members (GM) belonging to group "Z", distributed across the three domains
- registration Security Associations (SA) coupling the GM to their GCKS
- Diameter client/server sessions between each GCKS and the domain's Diameter server

                    |                     |                             |
ISP[x] admin domain | ISP[y] admin domain | Home[a] admin domain        |
                    |                     |                             |
   +----------+     |   +-----------+     | +----------+    +---------+ |
   | Diameter |     |   | Diameter  |     | | Diameter <####>Group "Z"| |
   |   AAA    <=========>   AAA     <=======>   AAA    |    |  Owner  | |
   | server X |     |   | server Y  |     | | server A <*** |  Server | |
   +----/\----+     |   +----/\-----+     | +----/\----+ ** +---------+ |
        ||Diameter  |        ||Diameter   |      ||      EAP            |
   +----\/----+     |   +----\/-----+     | +----\/----+ ** +---------+ |
   | GDOI GCKS|     |   |GSAKMP GCKS|     | |G-wiz GCKS| ** |Authntctn| |
   | Diameter |     |   | Diameter  |     | | Diameter | ***> server A| |
   | client X |     |   | client Y  |     | | client A |    |         | |
   +-A------A-+     |   +-A-------A-+     | +-A------A-+    +---------+ |
     |      |       |     |       |       |   |      |                  |
  registration SA   |  registration SA    | registration SA             |
     |      |       |     |       |       |   |      |                  |
   +-V-+  +-V-+     |   +-V-+   +-V-+     | +-V-+  +-V-+                |
   |GM1|  |GM2|     |   |GM3|   |GM4|     | |GM5|  |GM6|                |
   +-A-+  +-A-+     |   +-A-+   +-A-+     | +-A-+  +-A-+                |
     |      |       |     |       |       |   |      |                  |
   +-V------V-------|-----V-------V-------|---V------V-+                |
   |         Group "Z" group security association      |                |
   +----------------|---------------------|------------+                |
                    |                     |                             |

So, on the one hand, I freely acknowledge that portions of the above
architecture are out of scope of the MSEC charter. that said, I think it
is reasonable to size up the surrounding network operational model in
which the group policy token gets processed and circulated between
components. That way, we can clarify which components should be allowed to
see which portions of the token because they have a need to know. Usually
in architectures like the above, there are contractual relationships
between the various domains, spelling out what each is trusted to do with
priviledged information.

It is my intention to put the above diagram and some explainatory text into
section 5 of the Generic Policy Token spec. kinda ran out of gas for the moment,
will continue this later...

	George

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