Subject: Re: [MSEC] GSAKMP issue 24: RTJ should include Key Download KEK algorithm, mode, key length

From: "Andrea Colegrove" <[email-masked]>
Date: Mon, 1 Sep 2003 12:06:01 -0400

George,

> Hi,
> I note with interest that you snipped out those portions of my
> e-mail that spoke to multi-vendor interoperability. IMHO, GSAKMP will not
> advance unless there is flexibility shown, modifying the specification to
> meet match such requirements. more below.
>
   I did snip some sections out of previous emails as it seemed
inconsiderate to the list to ask them to repeatedly download and parse long
messages.  I have snipped older or redundant portions of messages previous
to this one as well.

Multivendor interoperability is shown though implementation of a mandatory
"MUST" implement suite of algorithms, as is true of any security protocol.

> > The RTJ itself has security requirements on it.  A GCKS should not even
> > attempt to process something that is not of sufficient caliber.
>
> That assertion is just a particular group policy decision. Other policies
> would say: I accept X and Y but not Z. The model you are assuming does not
> reflect this reality: Service Providers will operate groups that are
> hetrogenous both in vendor implementation and protocol version. They
> also expect to have flexible configuration of group policy to allow
> multiple flavors of valid RTJ because the group is hetrogenous.
>

Perhaps I have not been stating this clearly:  Whatever the policy for RTJ
is, it must be specified.  This is true whether the policy is "accept Z
only" or "X and Y but not Z".  The protocol is not tied to what a particular
group's policy is.

> >  So even
> > before RTJ, the potential member must have some knowledge of the group.
If
> > we look at Tunnelled GSAKMP, we see add some negotiation capability
before
> > Key Download, but even so, the member still needs to know what the group
is
> > about:  address, application, etc.  This is done through web interfaces,
> > SAP, etc.
> >
> > Whether the key download is not interpretable by the potential member or
> > whether the GCKS NACKs the member is irrelevant from the perspective of
the
> > new member. The bottom line for the GCKS:  The policy of a group is not
> > negotiable
>
> again, this is being over restrictive and hardwiring a particular view of
> what is group policy. the reality is that groups formed from multiple
> vendors and multiple admin domains and multiple protocol versions force
> negotiation on a per endpoint basis. the group announcement could say: the
> GCKS accepts profile X or profile Y.  The group member says in the RTJ: I
> support profile X. That is a minimum form of negotiation that GSAKMP must
> support to straddle such hetrogenous endpoints.
>

The policy token would state acceptable mechanisms.

> I think this discussion illuminates a subtle but essential issue not
> previously recognized:
>
> There can be a secure multicast group deployment where the multicasted
> data originating from a speaker is encrypted/multicasted once, but it must
> be received by two different subgroups who support profile X and profile Y
> respectively. So long as the GCKS enforces that data SA parameters are
> common across both subgroups, it is feasible to operate a single group
> data SA even though the registration SA parameters vary between the
> subgroups. A very promient example of this is a group formed from both

The concept of equivalent, but heterogenous protection mechanisms of group
data generally requires cryptographic gateways that can interpret the data
in one and reencrypt.  These ideas have been around for a while, but are
complex.  If we think that source authentication is difficult in homogenous
multicast group, consider heterogenous ones!  Anyway, interesting problem,
but back to your example of same data SA, different registration:

> GSAKMP and GDOI endpoints. Here's a simple example:
>
> |GDOI_endpoint A w/ profile X  |<==GDOI=====>|GDOI/GSAKMP    |
>                                              |bi-lingual GCKS|
> |GSAKMP_endpoint B w/ profile X|<==GSAKMP===>|               |
>                                              |               |
> |GSAKMP_endpoint C w/ profile Y|<==GSAKMP===>|               |
>
> The above endpoints (A+B) and C may be in a different admin domain with a
> different group registration policy expressed in a profile. Yet the data
> SA for the group remains homogenous even though the registration SA is
> not.

Yes, a group should be allowed to use two different registration mechanisms
simultaneously.  Once again, it would be group policy that decides.  This is
different than the protocol specification.

An implementation of a protocol can support many more mechanisms than the
initial set -- ala a separate doc specifying a suite 2, a private suite
understood by the community, or by registering separate new algorithms
through IANA using the "future use" ranges.

I do agree that the group policy may allow multiple registration mechanisms.
This is a flexibility that should be considered when specifying the group
policy token -- I hope that you will champion this cause.

> >
> Yes, but the above information about the group member's choice has to be
> conveyed to the GCKS in the RTJ. It is not realistic to expect only one
> set of registration SA parameters across all endpoints that is dictated by
> the group announcement.
>
Yes, if multiple choices for RTJ are supported in the announcement, then the
candidate member must signal what algorithms are chosen.  For example,
signature choice is indicated through the signature type field.  (BTW, I
just noted a typo on the table names.  Table 15 should refer to ID types.)
Perhaps the situation may occur where multiple key download types are
available according to group policy?  Generally, though, key download is
related to rekey downloads, which must be uniform across a domain (if
allowing for crypto gateways).  Because of this, it is questionable whether
it would be useful to have a candidate member indicate which encryption
algorithm should be used.  Does the msec working group have particular views
on the ability for a group to use (and a candidate member to specify)
multiple key download/rekey SA types?  Does GDOI have a way for the
candidate to say what encryption algorithms in rekey it desires?  I am not
trying to be contentious here, only ask if the use of cryptographic gateways
(multiple broadcasts in different algorithms) should be assumed to be a
requirement.

The candidate can indicate what choices of mechanisms are used using payload
fields.  The candidate cannot negotiate a different set of algorithms,
however.

> >
> > > >     Knowledge of the existence of a group and its "address" is
obtained
> > in
> > > > some sort of group announcement.
> > >
> > > The "some sort of group announcement"  is an example of unspecified
> > > information that will cripple inter-operability. Every vendor who
> > > implements GSAKMP is gonna roll their own "group announcement"
mechanism?
> > >
> > Someone advertising a group will indicate what the group is about, where
it
> > is to be found (addresses, applications, etc.), what security management
> > (and parameter choices), etc.  Security management is only a part of the
> > group application problem.  See SIP, SAP, etc for more info here.
> >
> > >
>
> The above response still does not answer how does GSAKMP support the
> multiple vendor configuration:
>
> 1) a group announcement by vendor A who openly publishes their spec,
>
> 2) group member using GSAKMP from vendor B, that understands vendor A's
> group announcement,
>
> 3) and GCKS using GSAKMP from vendor C that doesn't implement vendor A's
> spec for group announcments.
>
> They should all be able to work together. The network operator should not
> have to deploy vendor C's group announcement mechanism, nor should they
> expect all group members to be from vendor C. They just need to be able to
> configure the GCKS so that its view of the group announcement matches what
> vendor A advertises even if the GCKS couldn't understand the bits on the
> wire of that vendor A advertisement's encoding. And the GCKS must be able
> to inter-operate with vendor B endpoints, and vendor A's, and vendor
> D's....
>
> Note that in such a group formed from multiple vendor implementations
> there could be a mixture of legitimate profiles announced by Vendor A's
> group announcement that the GCKS should accept. The set of profiles
> offered gets narrowed down to one choice by each group member, and sent in
> the RTJ. The GCKS needs to have a UI that allows the explicit
> configuration of multiple acceptable profiles. This way we can support
> large-scale and flexible GSAKMP deployments. If we are careful about how
> we do this, we can even allow GDOI and GSAKMP endpoints in the same group.

Yes, I think that in principle I agree if I am reading you correctly.  The
security portion of a group announcement should be a subset of the group
security policy token.  The security portion should also be a subset of the
larger general group announcement.  It is also generally accepted that group
announcements should be small.

A standardized generic announcement with security hooks sounds like very
interesting work -- some of which has already been done.  It affects a much
larger group of folks than the security ones.  It is not part of the GSAKMP
protocol, though.

The protocol should provide the framework for registration, maintenance
including rekey, and perhaps even optionally, the controversial
de-registration ;-).  Implementations by different vendors can distinguish
themselves by indicating the mechanisms (algorithms, PKI type, token type,
etc.) that they support.  If a vendor wishes to deploy a multi-protocol GCKS
(say GDOI and GSAKMP) -- then the differentiation between "products" becomes
even greater, and the user interface becomes even more complex.

From a systems perspective, I believe that we agree what standards work that
needs to be done.  It does, however, need to be done in a modular manner.
The GSAKMP protocol should not specify all these things.

--- Andrea

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

---

From: Hugh Harney <[email-masked]>
Date: Wed, 3 Sep 2003 12:50:47 -0400

George,

    WRT the policy choices for registration (keeping other issues 
separate for the time being),  we need to clarify two issues:
        1.  How does a candidate member determine what acceptable 
mechanisms to use?
        2.  How does a candidate member communicate what mechanisms were 
chosen when multiple ones are acceptable?

    The first issue leads us to an announcement about the group as part 
of multicast group set up. This agreement can be via other means than 
the network (e.g., a particular community uses an agreed upon set of 
algorithms, a web page has this info posted, or the parameters are sent 
over the wire (along with the multicast address) in something like SAP. 
The means this information is sent to the group in question is out of 
scope for this protocol.  What is in scope for this protocol is to 
define a data field that specifies how this data is communicated, which 
should tie this specification into the IANA process. As an algorithm is 
allocated an IANA number, that number should be used in specifying it 
to the group.

    For the second issue, if multiple key download/encryption types are 
indeed to be supported, we would then need to add a notification of the 
candidates choice of policy-approved key exchange type and encryption 
algorithm.  Once again, this should be a short payload using IANA 
numbers.

--- Hugh and Andrea

Hugh Harney							Sparta, Inc.
[email-masked]						7075 Samuel Morse Drive
(410) 872-1515 x203					Columbia, MD, 21046

---

From: Hugh Harney <[email-masked]>
Date: Thu, 4 Sep 2003 15:53:44 -0400

George,

comments in-line

On Thursday, Sep 4, 2003, at 13:17 US/Eastern, George Gross wrote:

> Hi Hugh & Andrea,
>
> On Wed, 3 Sep 2003, Hugh Harney wrote:
>
>> George,
>>
>> scope for this protocol.
> How you encode that info in *some* cases may be out of scope of GSAKMP,
> but the semantics that the policy token announcement specifies are very
> much part of GSAKMP processing and therefore part of the GSAKMP
> protocol specification.
>
> Let's take an example that makes this discussion more concrete. In the
> GSAKMP policy token today, there are a set of group membership
> authorization rules encoded in an X.509-centric DN pattern matching
> scheme. However, in the commercial world, it is common practice to use 
> a
> Network Access Identifier (NAI, RFC2486) as the handle by which a 
> roaming
> user and his mobile computing systems are authenticated/authorized.
>
> It stands to reason that the generic policy token expressing the
> authorized group membership may want to specify a NAI-centric group
> membership authorization list as an alternative to the X.509 DN
> pattern rules approach.
>
> The NAI may not be in the user's Subject field of his/her Public Key
> Certificate. For example, it might be in the subjectAltName field 
> instead.
> So when that user presents a RTJ with his/her signature to the GSAKMP
> GCKS, the GCKS must understand that for this user, the identity 
> asserted
> matches a NAI in the subjectAltName field rather than the subjectName
> field.
>
> By adding the new "registration profile identifier" AVP to the Request 
> To
> Join message, the GCKS will have the additional information it needs to
> know when it must look for and validate a NAI against the group 
> membership
> authorization rules. However, as illustrated by this example, the GCKS
> processing is clearly not independent of the policy token. 
> Consequently,
> this processing is part of the GSAKMP specification even though the 
> policy
> token/announcement originated from the Group Owner.
>
> BTW: the placement of NAI in altSubjectName field is meant to be an
> example, and may not match practice in a particular CA deployment.
>
> Still another example: you could imagine the use of an attribute
> certificate as described in RFC3281 as another alternative group
> membership authorization technique. This would allow dynamic group
> memberships rather than the fixed structure implied by a set of 
> published
> rules that might become out of date. Again, if you went in this 
> direction
> for registration, then the GCKS must be able to parse, validate, and
> finally accept an Attribute Certificate presented in the RTJ with what
> ever is the defined convention for interpreting the "group" attibute 
> and
> others. That convention is in the GSAKMP specification.
>
> ANother area for the generic policy token to specify information that
> impacts the GSAKMP GCKS processing is the list of trusted root CA that 
> are
> accepted for certificates from the various parties. Again, you can not
> escape the configuration in the policy token having to match the GCKS
> configuration for processing this information, even if the announcement
> does not present it in a standardized format/mechanism. The GSAKMP
> protocol specification must include this processing in its semantics.

The mode of distributing this data structure is out of scope for 
GSAKMP. It can be preloaded during software configuration or sent via 
an announcement, placed on a web site ......
>
>>  What is in scope for this protocol is to
> Okay, I'm fine with this approach, provided it also meets several other
> requirements that bear mentioning:
>
> 1. it should be encoded as a variable length group AVP, perhaps 
> allowing
> optional nested AVP to accomodate multiple parameters being selected by
> the candidate member.

It is a data field that will be specified in GSAKMP.  I'm not viewing 
this an an extension of the Diameter-AVP effort.

>
> 2. it should have the ability to specify vendor-specific suites 
> instead of
> IANA registered ones. In the Diameter-AVP, this is "V" flag capability.

Again I don't think this needs to be as flexible as you seem to think.

> 3. I would like to see this value be a direct clone of a 
> Diameter-encoded
> AVP(s) from the generic policy token. Of course, the announcement may 
> have
> transcribed it to another format altogether, but clearly we do not want
> every announcement format flavor in the RTJ, the policy choice should 
> be
> normalized into a well-known AVP encoding.

If the MSEC generic PT wants to adopt this field that is fine.

I don't think the decision has been made to make the MSEC PT conform to 
the Diameter standards. I think a strong argument can be made for ASN, 
just like the certificates.

hugh