Subject: Re: [MSEC] George's comments / splitting token from protocol

From: George Gross <[email-masked]>
Date: Wed, 13 Aug 2003 11:12:38 -0400 (EDT)

Hi Hugh,

	as a way for us to get to a common point of view on this topic,
I'd suggest that you please have a look at RFC3160, the Tao of the IETF.
Please look at specifically sections 6.4.2 and 6.5, which discuss the
criteria for Normative Reference and an Experimental RFC.

the reminder my comments are inline below...

br,
	George

On Wed, 13 Aug 2003, hugh harney wrote:

> George,
>
> My comments in-line.
>
> >
> > I was not aware that it was aimed at Experimental status. I infer then
> > that a new independent ID will become the standards track Policy Token
> > spec?
>
> I think a generic MSEC security policy token should be developed. I don't
> think GSAKMP should be dependant on the new MSEC PT.
>
> The GSAKMP Policy Token is our shot at a PT that supports GSAKMP, IPSec,
> Distributed operation, and LKH. It provides a great deal of flexibility, but
> is not yet fully inclusive of all potential group applications.
>
> I think the advancement of the current GSAKMP PT to an RFC is adiquate to
> provide an strong reference in the GSAKMP protocol spec.

I respectfully disagree. THe Experimental RFC policy token is embedded
within the policy token payload sent in the GSAKMP "Key Download" message.
In other words, it is part of the bits on the wire specification. BTW,
this is not an invitation to remove that payload from that message.
Rather, I am saying that the dependency on the policy token explicitly
exists in the GSKAMP protocol. What is more, by virtue of aspiring to be a
Proposed Standard, the GSAKMP protocol specification must refer to
Normative References that are also at Proposed Standards status, not
Experimental RFC status.

> We are writing an
> expanded version of the GSAKMP PT that provides a complete reference for
> implementers of GSAKMP. Implementers will be able to parse the GSAKMP PT and
> interoperate.
>
> I think any policy token is an Experimental RFC because it is not a
> protocol. It is information that supports a protocol.

the policy token payload is part of the GSAKMP protocol.

>
> > I have no problem with the standards track Policy Token spec being a
> > separate document from GSAKMP, but their inter-dependency for advancement
> > to PS remains, agreed?
>
> The only inter-dependency I see between GSAKMP and the GSAKMP Policy Token
> is that GSAKMP should not be any references to an I-D. GSAKMP should be able
> to point to an RFC for a representation of a policy token.

As indicated above, the Tao of the IETF does not align with that view
when one RFC is experimental and the other RFC is proposed standard...

>
> > Having the policy token as a common structure across key management
> > protocols makes sense.
>
> Yes, it does. However, GSAKMP is ready to be a standard, based on the
> current PT.

Candidly, I see GSAKMP married with the standard policy token and the
schedule (whatever that turns out to be) for its movement to PS. The
experimental policy token is relevant to the earlier (experimental)
incarnations of GSAKMP.

> I do not want to have to wait for all other potential users of
> the PT to hack at the PT spec.

Well, emm... didn't realize we were so much a part of the GSAKMP
schedule...  I mean, since this the policy token is on the GSAKMP critical
path, then this type of discussion would have done well to have started
sooner than now.

Rest assured, I am willing to work with you, and I'm sure the rest of this
group is to, to assure that the standard policy token arrives at the
finish line in as expedient manner as is feasible. As always, this is a
process of arriving at rough consensus, so it will take time.

Unfortunately, as it stands, I hear you asking this working group to
standardize a dependency on a vendor specific experimental policy token.
AFAIK, that is not gonna happen, the bar is set higher than that.

In particular, I don't want the standard policy token design painted into
a corner to comply with the precedent set by that experimental policy
token, such as its bits on the wire encoding or semantics, simply because
GSAKMP mistakingly refered to it as a normative reference.

>I'd like to document the current work on the
> PT. Then allow a more generic PT to be specified for general use and all
> potential network states. GSAKMP (the protocol) can use any policy token
> that is developed in the future, without modification.

I don't see the current GKAKMP Policy Token Payload being as extensible as
your above assertion would indicate. This is related to another comment
that I've had, that there is a good case for having the payload TLV header
be similar as defined for IKE-v2, with critical bit semantics. Also a
mechanism for vendor-specific payloads and code points. If you want to
define a vendor-specific policy token payload, that is fine, but the hole
in the GSAKMP protocol for that role should filled by be the standards
track policy token, which has not even had an ID published.

> In the end, GSAKMP
> only needs the policy engine to respond with a binary go or stop.

not quite, as the GM needs a copy of the policy to know the rules of the
day

>
> > As mentioned in my e-mail that raced with yours, I would advocate that the
> > policy token morph into an extensible TLV style encoding, a similar design
> > pattern as is seen in many other IETF protocols. I would also follow
> > precedents/MUSTs from IKE-v2 where feasible.
>
> I think a more flexible encoding is good for the MSEC PT that will come
> after the current GSAKMP PT is captured.

Agreed.

>
> GSAKMP today only needs the specified GSAKMP PT to provide distributed
> operation, delegation of operation, and key management for many to many
> multicast. I'd like to decouple the GSAKMP spec from the R&D into generic
> MSEC security policy.

I was not expecting to do group policy token R&D in this arena, my
expectation is that a well engineered extensible policy token could be
defined using the known state of the art. The experimental policy token
certainly provides a reasonable design starting point, and no doubt others
will contribute to it.

>
> As for IKE-v2, I think we need to be careful to adopt only those things that
> make sense. IKE-v2 operates in a different paradigm than GSAKMP.

Please clarify. There are several aspects of IKE-v2 that are good protocol
design: extensible TLV, strong review by the crypto community of which
algorithms are preferable for standardization. A variety of Notify
payloads that deal with topics like NAT and traffic selectors that aren
not even mentioned in GSAKMP or the policy token.

 >
> > Once the GSAKMP related issues I've brought up have been figured out and
> > have rough consensus, then I am likely to turn more of my attention to the
> > policy token. It is an interesting problem ;o)
>
> Yes it is. The truth of the situation is that a key management system is
> only as good at the security policy enforcement. In the end, keys only
> represent policy enforcement.
>
> I look forward to your comments on the GSAKMP PT and working on the MSEC PT
> with you.

I am confident we can work out a rough consensus to this and the remaining
topics/issues. I encourage others to participate too...

George

> Hugh

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

---

From: "Andrea Colegrove" <[email-masked]>
Date: Wed, 13 Aug 2003 14:32:17 -0400

George,
    I believe that changing the token payload to contain an identifier of
the token type will accomplish what we intended, in that multiple token
types may be supported, with the GSAKMP v1 token as the initial choice.

    Re:  Experimental.  I am the source of some misinformation here.  I had
looked at RFC 2026 a while back and recalled that there was an alternate
path, being the best practices path.  I mentioned this to Hugh and I am
afraid that I didn't communicate it well.  On review of 2026, I don't think
that a BCP is a good path for a token at all.

    I believe that we need to revise the token payload to allow
extensibility here so that as new token types become available, these may be
supported.

    The GSAKMP token will provide a means of initial operation, but will
probably not provide a generic enough standard in the long run.  As we all
agree, a nice TLV spec, perhaps ASN.1 DER, may be in order here.

    I believe however that GSAKMP should not be held up because of a lack of
a generic token.  The protocol will be independent of the data it carries.

    I apologize again for spreading misinformation.

--- Andrea

---

From: "hugh harney" <[email-masked]>
Date: Wed, 13 Aug 2003 15:31:17 -0400

George,

I agree with Andrea.

If we were to add a policy token identity field in the GSAKMP spec, then
several policy tokens could be supported. I believe the first policy token
identified could be very close to the current GSAKMP Policy Token (well the
as yet to be released version 2). All upgrades to the PT could be identified
seperatly.

I'll address your other issues as soon as I can.

hugh

---

From: Thomas Hardjono <[email-masked]>
Date: Thu, 14 Aug 2003 11:19:31 -0700

Just to add more juice to this discussion, we did have a GSPT document that 
expired. http://www.securemulticast.org/draft-ietf-msec-gspt-01.txt

I think a possible way forward could be:

(1) Make the GSPT draft the general document explaining the notion
     of a token, why, its uses, its relationship with KM-protocols
     and defining the base-profile of a token and possible extensions.

(2) Rename "GSAKMP Token Specification" to become more specific, say
     something like "GSAKMP Token for IPsec".

(3) Write/define other token-drafts for other KM-protocols (e.g. for GDOI).

One of the reasons GSPT expired was the lack of people-power.  Perhaps we 
could resurrect it.

(PS. George, would you be open to contributing? )

thomas
------