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

From: Andrea Colegrove <[email-masked]>
Date: Thu, 14 Aug 2003 13:58:51 -0400

George,

George Gross wrote:

>Hi Andrea,
>
>On Wed, 13 Aug 2003, Andrea Colegrove wrote:
>
>  
>
>>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.
>>    
>>
>
>So if I read between the electrons, you're saying whatever we got for a
>policy token today is what you want to standardize, rather than move it to
>Experimental? hmmm... see below.
>
>  
>
The space between the electrons didn't actually contain that much 
information.  Just as ISAKMP is independent of the certificates used in 
the protocol framework, so GSAKMP should be independent of the 
infrastructure support mechanisms.  The infrastructure is needed, but is 
not coupled with the protocols.  ISAKMP wasn't held up because of 
SDSI/SPKI progress.

>  
>
>  
>
>>    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.
>>    
>>
>
>Introducing a group policy token encoding along these lines (TLV encoded)
>would go a long way towards adding extensibility. I perceive that is
>mandatory given the token will be handling many flavors of policy and at
>least two protocols in the future. In other words, if the next rev of the
>Group Policy Token ID moved to this more flexible position, it would
>support GSAKMP's advancement to PS, and GSAKMP could advance to PS when
>this rev'd GPT advances. It would enable GDOI-v2 related extensibility
>too.
>
>Caveat: this statement assumes that the other issues that I've brought up
>wrt/ to the GSAKMP and the policy token have gotten to rough consensus.
>Also, I have not yet delved into the GPT as deeply as GSAKMP yet, I may
>yet discover nooks and crannies that have other issues.
>
>To date, there have been several GPT related changes brought up by me. If
>you are unable to change the existing GPT definition due to installed
>base, then it really should be "Experimental", and the generic GPT should
>be the only one that the rest of us have to implement.
>
> >
>
GPT and GSAKMP should be independent issues.

>  
>
>>    I believe however that GSAKMP should not be held up because of a lack of
>>a generic token.
>>    
>>
>
>My experiences in prior lives in other IETF protocol design exercises
>argues strongly against this approach. In the context of L2TP, some of the
>things I argued should go into L2TP v1 to support broadband (as opposed to
>dial-up) PPP did not make it, and L2TP v2 with those features did not
>publish until 4 years later. The good news was that in the interrim, you
>could get that capability by defining vendor-specific TLV between the LAC
>and LNS.
>  
>
Along similar lines of other working group experience:  The current 
token would be analagous to some of PPP's initial authentication 
mechanisms (CHAP and the like).  A more extensible token would be 
analagous to EAP.  EAP can now be used by both PPP and other protocols.

>So what ever we put into policy token V1 is what we are stuck with for
>years into the future. And while others on this list have said that GSAKMP
>and GDOI are "in separate markets" I do not buy that POV, as it is one
>Internet. We will face the pain of groups that straddle both GSAKMP and
>GDOI endpoints. I'd rather my GCKS has one policy token syntax, even if it
>has a mixture of TLV that are common, GSAKMP-specific, GDOI-specific, and
>vendor-specific.
>
Disagree.
Progress of the IETF working groups relies on being able to decompose 
problems into independently solvable pieces.  Otherwise, we have working 
groups that never satisfy their charters ... that seems to make AD's a 
little touchy.

>
>We agree that a TLV style encoding will be required, so I say it is _now_
>that we should introduce that capability. It is much better to re-vamp the
>definition now, than to have running code widely deployed with this known
>handicap of a fixed structure that is glued to GSAKMP v1.
>
Code base and protocol specification are different.  We shouldn't be 
worried about code bases here, but rather on standards and 
interoperability of implementations of those standards.

I think that the problem at hand is more that we need to consider as a 
working group of how to be able to decompose the group security 
management problems so that we are not hobbled by needing to advance 
lockstep through the process because of a lack of prior standardization 
of group mechanisms. It was very good of you to point out the normative 
problem, but it appears that the  intent of these requirements on 
references is to make sure that the reference is stable and does not 
change.  I do not see how an Experimental protocol violates that.

--- Andrea