Subject: RE: [MSEC] GSAKMP issue 01: GSAKMP and policy token should advanc e in sync to PS

From: "Hardjono, Thomas" <[email-masked]>
Date: Mon, 11 Aug 2003 09:02:40 -0700

If the base-profile is going to be shared across various key management
protocols, would it make sense to separate it (or include it into the Policy
Token draft)?

thomas
------

> -----Original Message-----
> From: Lakshminath Dondeti [mailto:[email-masked]] 
> Sent: Monday, August 11, 2003 11:41 AM
> To: George Gross
> Cc: [email-masked]
> Subject: Re: [MSEC] GSAKMP issue 01: GSAKMP and policy token 
> should advance in sync to PS
> 
> 
> My recollection is that base-profile will be in the GSAKMP document.  
> Thomas or Hugh might have a more definitive answer.
> 
> regards,
> Lakshminath
> 
> George Gross wrote:
> 
> >Hi Lakshminath,
> >
> >On Mon, 11 Aug 2003, Lakshminath Dondeti wrote:
> >
> >  
> >
> >>We have had a discussion on this at the meeting in Vienna.
> >>
> >> From the meeting notes:
> >>
> >> Thomas:  A possible way forward would be to define a "base-profile"
> >>    for the token containing fields common to the various 
> key management
> >>    protocols. Area-specific needs would then be satisfied by adding
> >>    additional fields ("extensions") to the Token.
> >>
> >>George,
> >>
> >>Would that be sufficient in your opinion?
> >>    
> >>
> >
> >It is a start in the right direction. however, some things 
> are missing 
> >from that statement. Like in which document do the "GSAKMP-specific 
> >extensions" get specified?
> >
> >Naturally, I'd like to see all the issues I've raised (and for that 
> >matter, anyone else on the list can chime in) wrt/ GSAKMP brought to 
> >closure, so we know exactly what changes to the GPT are 
> required before 
> >it advances to PS.
> >
> >Having just a base GPT document goto PS by itself is not enough for 
> >GSAKMP to advance to PS unless the GSAKMP spec includes its GPT 
> >extensions or it else explicitly states that it requires no 
> extensions 
> >to the base GPT.
> >
> > know this sounds finicky, but I'm trying to avoid surprizes...
> >
> > >
> >  
> >
> >>cheers,
> >>Lakshminath
> >>
> >>George Gross wrote:
> >>
> >>    
> >>
> >>>GSAKMP issue 01
> >>>
> >>>Section and relevant text passage:
> >>>
> >>>The Section 2 definition of a "policy token" refers to a 
> >>>non-normative reference [HCLM00].
> >>>
> >>>Comment/issue description:
> >>>
> >>>The GSAKMP protocol is strongly bound to the policy token 
> >>>specification. The specification currently only refers to 
> an Internet 
> >>>Draft work in progress. The spec should indicate a MUST and a 
> >>>reference to a normative reference (i.e. RFC). In other 
> words, GSAKMP 
> >>>and the group policy token must advance into the RFC 
> editors queue in 
> >>>unison.
> >>>
> >>>Suggested issue resolution:
> >>>
> >>>Section 3.2 should add a new section explaining the GSAKMP 
> dependency 
> >>>on the group policy token.
> >>>
> >>>
> >>>_______________________________________________
> >>>msec mailing list
> >>>[email-masked] 
> >>>http://www.pairlist.net/mailman/listinfo/msec
> >>>
> >>>
> >>>
> >>>      
> >>>
> >
> >
> >  
> >
> 
> 
> _______________________________________________
> msec mailing list
> [email-masked] http://www.pairlist.net/mailman/listinfo/msec
> 

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

---

From: George Gross <[email-masked]>
Date: Tue, 12 Aug 2003 08:46:21 -0400 (EDT)

Hi Thomas,

> protocols, would it make sense to separate it (or include it into the Policy

If the policy token is gonna be extensible across various key management
protocols and future flavors of group policy parameters then it will need
to move to a TLV header form of encoding.

As for the base profile, my first inclination is to do something analogous
in spirit as:

draft-ietf-ipsec-ikev2-algorithms-02.txt

in that the existing policy token spec that would enumerate the
MUST/SHOULD/MAY values for every policy token TLV parameter.  The base
profile would be the combination of MUSTs from that definition naturally.

Incidently, I think the set of MSEC MUST/SHOULD encryption and
authentication algorithms would do well to match IKE-v2, and also add
AES-CCM, AES-CTR.  The RC4 and RC2 algorithms got discussed on IPSEC list
awhile ago, and got dropped.

So I think I'd like to hear from Hugh et al what they think...

br,
	George