Subject: [MSEC] Generic Policy Token issues

From: "hugh harney" <[email-masked]>
Date: Wed, 20 Aug 2003 14:25:38 -0400

All,

Several side exchanges have gone between George and I concerning the Generic Policy Token. Mostly, we were trying to understand each others issues and concerns.

As is the nature of these exchanges, some technical suggestions have been made and we wanted to put these suggestions in front to the MSEC group for consideration.

In a side exchange George Gross suggested the following:

"1. We borrow the Diameter protocol base specification's Attribute
Value-Pair (AVP) syntax and framework for encoding the policy token. See
attached e-mail wrt/ to Diameter status, it is in the RFC editors queue.
Diameter offers a comprehensive encoding scheme for all types of data, and
includes mechanisms for digital signature and encryption based on CMS.

2. We do not require implementation of the Diameter base protocol
specification, we simply reserve from IANA a set of AVP codes for MSEC
usage, the first set of which are allocated for the GSAKMP policy token
related AVP.

3. For each parameter in the current GSAKMP policy token, we do a one for
one mapping of the fields into a corresponding "group AVP" as
characterized in section 4.4 of the Diameter specification. We define a
syntax for the mandatory and optional AVP for each group AVP."

My questions to the group and to George are: 

If we (the Generic Policy Token work) focus on the core aspects of the policy token for version 1 of the Generic Policy Token, how long would it take to get this written?

This is assuming that the Diameter framework is universally acceptable. Is this true?

Hugh

---

From: "Andrea Colegrove" <[email-masked]>
Date: Wed, 20 Aug 2003 15:17:52 -0400

Given that probably most of the working group does not have the extensive experience in Diameter that George has, it might be of benefit to both provide members time to review Diameter as well as perhaps for George to highlight some of the reasons why Diameter is a good starting point for the msec token.  This is probably a case where no immediate objection does not mean consensus.

--- Andrea

---

From: George Gross <[email-masked]>
Date: Wed, 20 Aug 2003 14:40:40 -0400 (EDT)

Hi,
	at the moment, I don't have time for an elaborate reply, so I'll
focus on a short version, and elaborate in future e-mails as cycles
permit...

	The essence of why one would to consider the Diameter framework
for the policy token is simple: network service operators use
Authentication, Authorization, and Accounting (AAA) for their back office
operations that assure the bill gets paid for those services that span
administrative (and business) domains. In its first application, Diameter
is being standardized for roaming network access. Another application is
the Mobile IP AAA. Diameter has a rich model for multi-party sessions that
include brokers, so it scales well.

	Now let's look at secure multicast as a billable multi-realm
network service. As a representative example, let's suppose that the home
administrative domain is an Enterprise that wants to do secure
collaborative teleconferencing. The visited administrative domain may be a
Streaming Media Service Provider, and an employee of the Enterprise wants
to join the teleconference while he/she is traveling and staying at a
hotel that offers Internet access with that Service Provider.

	Diameter as currently formulated could provide the AAA
capabilities to do vanilla Internet access, but it does not currently have
an extension defined for secure multicast services. In all likelyhood,
such a definition is quite away down the road, but the generic policy
token is a first step on that road.

	The Enterprise home admin domain is the secure multicast group
owner (i.e. the entity who pays the bill). It stands to reason that the
group policy token signed by the owner needs to be placed in a Diameter
framework, and conveyed to the GCKS that resides in the visited admin
domain. What's more, the policy token contains information that both that
GCKS and the group members would need to decrypt and interpret. Diameter
has mechanisms to assure confidentiality and integrity on a per AVP basis.
The GCKS would be in a position to handle authentication that interacts
with the Enterprise's Authentication server, enforce authorization for the
service, meter its usage, and generate accounting records.

	My conviction is that to become commercially widespread, secure
multicast must interact with the AAA infrastructure already being used by
Service Providers. Encoding the policy token in the Diameter framework is
a natural step towards that objective, as policy and AAA are really
close cousins of one another.

more to come later (putting on flame-proof suit)...

br,
	George

>   This is assuming that the Diameter framework is universally acceptable. Is this true?

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

---

From: Haitham Cruickshank <[email-masked]>
Date: Thu, 21 Aug 2003 12:35:52 +0100

Hi All,

I have one comment about Diameter usage for the security policy
distribution in relation to GSAKMP protocol: One important property of
GSAKMP, that I like, is
that it is SELF CONTAINED, and does not depend on any other protocols.
So, why we should rely on Diameter within a GSAKMP managed group, this
adds more interworking complications.  May be, Diameter is useful for
interworking between GSAKMP and others such as MIKEY and future versions
of
GDOI (GDOI with policy).

My suggestion is that for the generic Policy Token (PT), there should be
an option to carry the PT within the protocol itself in order to reduce
the dependency on Diameter, if it is not available.

Any comments are welcome.
Haitham

hugh harney wrote:

> All, Several side exchanges have gone between George and I concerning
> the Generic Policy Token. Mostly, we were trying to understand each
> others issues and concerns. As is the nature of these exchanges, some
> technical suggestions have been made and we wanted to put these
> suggestions in front to the MSEC group for consideration.
> syntax for the mandatory and optional AVP for each group AVP." My
> questions to the group and to George are:
> If we (the Generic Policy Token work) focus on the core aspects of the
> policy token for version 1 of the Generic Policy Token, how long would
> it take to get this written?
>

--
Dr. Haitham S. Cruickshank

Senior Research Fellow in Communications
Centre for Communication Systems Research (CCSR)
School of Electronics, Computing and Mathematics
University of Surrey
Guildford, Surrey GU2 7XH, UK

Tel: +44 1483 686007 (indirect 689844)
Fax: +44 1483 686011
e-mail: [email-masked]
http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/

---

From: George Gross <[email-masked]>
Date: Thu, 21 Aug 2003 13:31:53 -0400 (EDT)

Hi Haitham,

> that it is SELF CONTAINED, and does not depend on any other protocols.

It is still self contained, albeit one does need to be able to parse the
Diameter AVP syntax and then understand the semantics for the repertorie
of only those AVP defined for a GSAKMP policy token. We would not mandate
implementation of a Diameter base protocol and its secure multicast
extension, although there may be powerful economic incentives for a
network operator to want to do that in a deployment.

Also, I anticipate that GSAKMP will have an option for you to define and
"roll your own" policy token payload by setting the "policy token ID type"
field to a non-standard value (see section 6.3 of msec-gsakmp-sec-03.txt).
Of course, that private policy token would not interoperate with anyone
other than consenting parties who understand that private token type.

> interworking between GSAKMP and others such as MIKEY and future versions

Yes, that is a very compelling advantage, that earlier e-mails did not
mention or emphasize. It would be a good thing for the group owner to
encode and sign one policy token syntax that is endpoint protocol
independent. the group owner that signs the token would not have to know
which protocols are in use amongst the group members:  GSAKMP, GDOI-v2, or
MIKE. The latter two would have to rev their design v1->v2 to add the
policy token concept.

Note that using the AVP encoding scheme, some Diameter AVP could be
considered "base" and used across multiple MSEC protocols, whereas other
AVP may be protocol-specific.

> the dependency on Diameter, if it is not available.

ummmm... if I understand what you are saying, I think you will get that
capability. The Diameter encoded generic policy token would be the
contents of the policy token data field within a GSAKMP policy token
payload. See section 6.3 in the GSAKMP protocol spec.

hth,
	George