Subject: [MSEC] msec spec language

From: Andrea Colegrove <[email-masked]>
Date: Mon, 25 Aug 2003 12:49:49 -0400

All,
    Discussions of the future msec token have been in the forefront of 
this list recently.  Obviously, the content of the token is and will 
continue to be hotly debated.  Another issue that should be carefully 
considered, though, is the specification language of the token.  One of 
the recent proposals has been for Diameter's AVP framework.

    Having very little experience (none) with AVP in the past, I spent a 
little bit of time looking at it the past couple of days.  It does 
provide a structural framework for defining many different types of 
parameters -- security and others.  It does allow for some "grouping" 
and nesting of attributes.  While quite suitable for many types of 
policy, I am sure, I don't think that it is the best choice for the msec 
policy token.

    ASN.1 seems to provide much more flexibility in expressing content 
choices and constraints.  More importantly, it is the specification 
language for the main security infrastructure (X.509) in use.  ASN.1 
will allow us to use many of the mechanism and naming conventions 
already defined by the security community. Using encoding techniques 
such as DER will allow us to interface easily with the infrastructure 
and will also allow us to define major structural components without 
needing to manually keep track of type assigments for internal structures.

    As I admitted above, my lack of familiarity with AVP may have caused 
me to inadvertantly overlook some of its features.  Given what I have 
seen, however, I feel that ASN.1 is much more suitable.

--- Andrea

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

---

From: Brian Weis <[email-masked]>
Date: Mon, 25 Aug 2003 11:08:56 -0700

One consideration in the choice of specification language would be to
consider what functional code unit will be constructing and processing
it, and then choose a specification language that is native to that code
unit.

For example, will the key management code be more likely to process the
policy token itself, or pass it on to a policy subsystem?

I believe the suggestion of AVPs came from a believe that the key
management code will often hand the policy token over to a AAA subsystem
for actual processing. In that case, AVPs make a lot of sense.

Group key management protocols based on ISAKMP (e.g., GDOI) might find
ISAKMP TLVs and TVs to be most efficient, if they are going to process
the policy token code themselves.

Andrea's suggestion of ASN.1 implies that the key management will be
more likely to process the policy token. If the key management code is
already doing ASN.1 processing locally, then that makes a lot of sense.

To summarize, I think we need to understand the whole interaction
between the Policy and Key Management areas before we choose a policy
token specification language.

Thanks,
Brian

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

---

From: George Gross <[email-masked]>
Date: Tue, 26 Aug 2003 11:48:45 -0400 (EDT)

Hi Brian,

> it, and then choose a specification language that is native to that code

I would say another criteria for selection is minimizing the incremental
development and operational cost of adding the secure multicast capability
to the AAA infrastructure. That criteria includes minimizing the amount of
re-inventing the wheel that we as a working group must do. When I take
stock of the Diameter base AVP lexicon, and augment it with a subset of
the network access application lexicon, my hunch is that we will discover
reuse for secure multicast group policy tokens.  Examples include AVP for
re-authentication timers, filtering rules for what endpoints are
authorized to talk to other endpoints, interaction with Enterprise
authentication systems...

> token specification language.

That's a fair expectation. It sounds like you'd like to see an
architectural model/framework, and a usage case showing the policy token
flow through the components in that framework. would that help the
decision process?

br,
	George

---

From: Brian Weis <[email-masked]>
Date: Wed, 27 Aug 2003 10:42:39 -0700

Hi George,

> authentication systems...

When you ay "reuse for secure multicast group policy tokens", do you
mean adding more policy to the policy token, or re-using the basic
structure for unicast protocols? The examples you mention above could be
both, I think.

> flow through the components in that framework. would that help the

That's a great idea. In fact, it could very well fit into the Policy
Architecture document that we originally thought would be written. There
seem to be different views on how the policy token can be used, and
getting those written down somewhere would be beneficial. I'm not sure
what the best document structure would be.

Thanks,
Brian

---

From: George Gross <[email-masked]>
Date: Wed, 27 Aug 2003 12:32:26 -0400 (EDT)

Hi Brian,

> structure for unicast protocols? The examples you mention above could be

yes, I do see reuse of the AVP syntax and semantics for both unicast and
multicast cases of distributing the policy token. where I'm fuzzy at the
moment is which AVP for which sender/recipients pairings. understanding
that more precisely is kinda coupled to the framework/model that describes
policy token flow, as per our discussion below.

> what the best document structure would be.

	My working view was that would be a candidate sub-section in the
msec-gspt-02.txt draft. Starting a new "policy token arch" draft has alot
of inertia to get off the block.

	I sorta had foreseen the need for this framework/model, but had
been assuming it would be oriented towards showing the linkage of the
GCKS/group owner/group member to a Diameter/AAA approach. So I was
thinking I'd float some text for the msec-gspt-02.txt draft once I had
enough cycles free to flesh it out early next week. Adding a discussion of
tradeoffs for policy token preferred encoding scheme had not been on my
radar until now. I'll perk on this over the weekend...

I'd welcome your contribution of text/ASCII art on this topic ;o)

br,
	George