Subject: Re: [MSEC] msec spec language

From: George Gross <[email-masked]>
Date: Fri, 29 Aug 2003 06:47:11 -0400 (EDT)

Hi Brian,

	this is a resend of my e-mail originally sent yesterday that did
not make it to the MSEC list archive or make it back to my own e-mail
address from [email-masked].

	George

On Wed, 27 Aug 2003, Brian Weis wrote:
> >
> Hi George,
>
> George Gross wrote:
> >
> > Hi Brian,
> >
> > On Mon, 25 Aug 2003, Brian Weis wrote:
> >
> > > 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.
> >
> > 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...
>
> 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.
> >

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.
> >
>
> > >
> > > 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.
> >
> > 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?
>
> 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.
> >

        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

<snip the rest to save bandwidth>

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