Subject: [MSEC] GSAKMP issue 13: Rekey Event Payload "ID Type" field

From: George Gross <[email-masked]>
Date: Sat, 9 Aug 2003 08:28:55 -0400 (EDT)

4 of 4 e-mails resent

GSAKMP issue 13

Section and relevant text passage:

6.5 Rekey Event Payload

The "ID Type" field's definition.

Comment/issue description:

The "ID Type" field should be renamed "Rekey ID Type" so it is distinct from the
other fields with similar sounding names.

In table 11, when is "Group Recovery" specified versus "Maintenance"?

Suggested issue resolution:

s/ID Type/Rekey ID Type/

I could make a guess, but the text should elaborate on the definition of
each of the values in table 11.

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

---

From: "Hugh Harney" <[email-masked]>
Date: Tue, 12 Aug 2003 10:42:15 -0400

George,

Given the number of comments and detailed nature it will take a few days for
us to respond. We appreciate the detailed analysis you put into this effort
and we plan on addressing all your comments.

I will address your first comment now.

We struggled the decision to split the GSAKMP Policy Token into it's own
draft. We decided to do this for two reasons.

First, The token specificaiton can and will change as the GSAKMP is used to
support more and more applications. We wanted to allow the Policy Token RFC
to evolve at a different rate than the protocol spec.

Second, the current I-D GSAKMP Policy Token Spec will probably be aimed at
becoming an experimental RFC. The original GSAKMP implementations use it to
specify the security policy. However, in the future GSAKMP could use a
number of policy tokens or frameworks as they become more developed.
Specification of the Policy Token within the Protocol Spec could hinder
adaptation of GSAKMP to other security policy mechanisms.

Third, the GSAKMP Policy Token could be used by other protocols if there is
a similar need for a security policy definition. We wrote the GSAKMP
security policy token to contain branching fields that would allow other
implementors to use it.

---

From: George Gross <[email-masked]>
Date: Tue, 12 Aug 2003 09:11:34 -0400 (EDT)

Hi Hugh,

	our e-mails crossed paths! see inline below...

br,
	George

> and we plan on addressing all your comments.

You're welcome, I look forward to hearing your responses...

> adaptation of GSAKMP to other security policy mechanisms.

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?

> security policy token to contain branching fields that would allow other

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?

Having the policy token as a common structure across key management
protocols makes sense.

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.

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)

---

From: "hugh harney" <[email-masked]>
Date: Wed, 13 Aug 2003 11:05:58 -0400

George,

My comments in-line.

> that a new independent ID will become the standards track Policy Token

I think a generic MSEC security policy token should be developed. However, 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. 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.

> separate document from GSAKMP, but their inter-dependency for advancement

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.

> Having the policy token as a common structure across key management

Yes, it does. However, GSAKMP is ready to be a standard, based on the
current PT. I do not want to have to wait for all other potential users of
the PT to hack at the PT spec. 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. In the end, GSAKMP
only needs the policy engine to respond with a binary go or stop.

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

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.

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.

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

Hugh