Subject: Re: [MSEC] MSEC WG Last Call: draft-ietf-msec-policy-token-sec-02.txt (closing June 10, 2005)

From: George Gross <[email-masked]>
Date: Mon, 6 Jun 2005 12:09:33 -0400 (EDT)

Hi,
	I have reviewed and compiled (using eSNACC v1.7) the core policy
token ASN.1 specified in this v02 draft's appendices.

	there were a few minor syntaxical corrections needed to get to a
clean compile, and I've worked off the list with Andrea wrt/ those. I'd
like to see these published in the next rev of the Internet Draft.

	Overall, I support the advancement of this core PT draft to
Proposed Standard.  The set of group security policies expressible by the
core PT is a reasonable starting point for growing application-specific
group security policy ASN.1 specs based on this spec.

	That said, there are several areas in the current draft that I
would like to hear the opinion of other MSEC members, especially those
with ASN.1 design experience in other IETF standards. since I am
relatively new to using ASN.1 as a designer, there is a certain amount of
wisdom through experience that would influence how one would encode group
policy for the following design problems:

1) The merits/drawbacks of encoding the "SecuritySuite" as an OID versus
an INTEGER.

2) The merits/drawbacks of introducing a GSAKMPIdType as an enumerated
list for the GSAKMPID object, with the enumeration's values matching those
declared the GSAKMP protocol spec Table 19.

3) Should the "KeyIdentifier" OID definition be imported from the
certificate extensions ASN spec rather than using the explicit definition
found in the draft's appendices?

4) The registration, de-registration, and rekey protocols are all
currently defined as being of type "GroupMngmtProtocol", which turns to be
"protocolInfo OCTET STRING". In effect, this is a textual convention that
requires the implementor to validate the OCTET STRING rather than rely on
ASN syntax checking. IMHO, I would have thought it would a more extensible
syntax to have defined a CHOICE for each of these protocols with an ANY
type as one of the choices. This resembles the construct used for a
GeneralName within the SubjectAltNames of a certificate.  For example, the
rekey protocol choice would be expressed as follows in this alternative
method:

------------------------------------------------------------
    -- RekeyProtocol

RekeyProtocol ::= CHOICE {
  other-rekey      [0] Other-Rekey,
  none             [1] NULL,
  gsakmp-rekey-v01 [2] GSAKMPv1RekeyInfo
}

Other-Rekey ::= SEQUENCE {
     rekey-proto-id   OBJECT IDENTIFIER,
     rekey-type       ANY DEFINED BY rekey-proto-id
}

what do people think of this alternative encoding using CHOICE in
combination with "ANY DEFINED BY"?

tia,
	George

On Thu, 19 May 2005, Lakshminath Dondeti wrote:

> Hi all,
>
> This is an MSEC WG last call for comments on
> http://www.ietf.org/internet-drafts/draft-ietf-msec-policy-token-sec-02.txt
> closing on
> June 10, 2005 AOE.
>
> Track:  Standards Track, Proposed Standard
>
> If you have questions or if you think the draft is not ready to move
> forward, please send your comments to the list.  If you think that it
> looks ready to be forwarded to the IESG, we want to hear from you also.
> If you don't care, we want to know that as well :-).
>
> Note that the Policy Token is generic and can be used with GDOI as well
> as other key management protocols in addition to GSAKMP.  So, please
> take some time to review this.
>
> We would also like to hear about any implementations of the policy token
> spec (Andrea, do you know of any implementations?).
>
> regards,
> Lakshminath
>
> Draft details:
> Title:   Group Policy Token V1 with Application to GSAKMP
> Authors: A. Colegrove and H. Harney
>
> Abstract:
>
> The Policy Token is a structure used to specify the security
>     policy and configurable parameters for a cryptographic group, such
>     as a secure multicast group.  This document specifies the structure
>     of such a token in order to securely bind system-level security to
>     protocols supporting the management of cryptographic groups.
>
> _______________________________________________
> msec mailing list
> [email-masked]
> http://six.pairlist.net/mailman/listinfo/msec
>

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

---

From: Andrea Colegrove <[email-masked]>
Date: Tue, 14 Jun 2005 09:31:42 -0400

Hi,
A couple of comments on your email are included below:

>like to see these published in the next rev of the Internet Draft.
Yes -- all minor changes are being incorporated. Thanks.

>1) The merits/drawbacks of encoding the "SecuritySuite" as an OID versus
Object identifiers provide a nice way of extending our "CHOICES" without 
requiring us to open up the spec. By only importing modules that we wish 
to use, we limit wrt size and local policy. I am eating humble pie here 
as I too used to argue vigorously for explicit definitions within the 
specs, but have come to see the headaches associated with constantly 
updating a full spec in favor writing a companion spec that extends a 
protocol via the OID mechanism.

>declared the GSAKMP protocol spec Table 19.
Each time a new GSAKMPIdType were to be added to GSAKMP, the token spec 
would also need to be opened up to add it to that spec if we were to use 
enumerated values. I prefer that we do not change this as it would 
become a never-ending coupling in the IETF.

>found in the draft's appendices?
KeyIdentifier is imported as follows:

IMPORTS
LifeDate
FROM PolicyToken {TBD}

KeyIdentifier
FROM PKIX1Implicit88 { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit(19) };

If it is inadvertantly redefined elsewhere, I haven't caught that, 
please point out where.

>rekey protocol choice would be expressed as follows in this alternative
For other than the options tagged [1] and [2], I do not see the benefit. 
The hybrid CHOICE/OID option doesn't seem very elegant.

As far as trying to do most protocol options as CHOICEs, that is not 
very extensible as we have the spec "re-opening" problem as discussed above.

I do believe that the spec should say that we need to limit (check 
receipt of) the OIDs processed to those acceptable to the implementation 
and that local policy should be able to configure these via "knobs".

BTW, we have tried to follow the RFC 3852 convention for this.

>EncapsulatedContentInfo ::= SEQUENCE {
>        eContentType ContentType,
>        eContent [0] EXPLICIT OCTET STRING OPTIONAL }
>
>      ContentType ::= OBJECT IDENTIFIER
>
If I have missed a nuance of CMS then we should definitely make changes. 
I don't believe, however, that we should make changes that make the 
draft less extensible in favor of slightly easier implementation.

Thanks for the comments and raising these discussion points.

--- Andrea

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 14 Jun 2005 14:31:12 -0400

Hi folks,

This last call closed on Friday.  However, there is an ongoing 
discussion between George Gross and the authors.  Ran and I invite you 
to chime in, so we can achieve consensus one way or another.

thanks and regards,
Lakshminath

Lakshminath Dondeti wrote:

> looks ready to be forwarded to the IESG, we want to hear from you 
> also.  If you don't care, we want to know that as well :-).
>
> Note that the Policy Token is generic and can be used with GDOI as 
> well as other key management protocols in addition to GSAKMP.  So, 
> please take some time to review this.
>
> We would also like to hear about any implementations of the policy 
> token spec (Andrea, do you know of any implementations?).
>
> regards,
> Lakshminath
>
> Draft details:

---

From: George Gross <[email-masked]>
Date: Wed, 15 Jun 2005 07:04:31 -0400 (EDT)

Hi Andrea,

we have different perceptions of the rate of change for the core PT
branchs. this leads to different conclusions about how to engineer the
ASN.1 extension mechanism/syntax.

In general, I observe that the rate of change for several of these core PT
objects that we're discussing is on the timescale of IETF standards
action. OTOH, I suspect the SecuritySuite would change more frequently
than that.

In other words, the core PT spec will have infrequent change, with years
of the usual standards review lifecycle between RFC revisions ;o)

more inline below...

> A couple of comments on your email are included below:
<snip>
> protocol via the OID mechanism.

For the "SecuritySuite" OID, my point of view is that its rate of change
is faster than IETF standards action due to two factors:

1) flux in cryptographic algorithm status (i.e. the demise of MD5 and the
cloud over SHA-1)

2) diversity in the multicast application-specific security policies,
which will ammend or replace the default GSAKMP SecuritySuite 1.

so help me understand, do you register a new security suite OID every time
you change one of the parameters with the security suite's profile? in
your view, when does one define a new SecuritySuite OID? what is the
process through which one acquires that OID, is it an IANA allocation
everytime?

Said another way, if SecuritySuite is meant to enumerate choices available
within a local registry of group crypto-suites implemented by an
Enterprise's multicast applications, then does it make sense to use OID or
INTEGER?

> become a never-ending coupling in the IETF.

The set of GSAKMPIdType that have been defined in Table 19 are one for one
matched to those in widespread use by the rest of the Internet security
community (i.e. PKIX,IKE). So adding a new GSAKMPIdType is not very
probable from what I can see, and would add new types at a slow rate
governed by standards action.

Please explain why you see lots of new GSAKMPIdType identifiers on the
future horizon (and private use does not require IETF standards action).

> If it is inadvertantly redefined elsewhere, I haven't caught that,

Okay, I do not have a ASN.1 module named "PKIX1Implicit88" in my SNACC
compiler's distribution. So I can only infer that the module I imported is
equivalent to the "PKIXImplicit88" module, but has a different name.

> Thanks for the comments and raising these discussion points.

hmmm... when I read your criteria stated wrt/ SecuritySuite, we should be
using CHOICES and object identifiers for the registration protocol, rekey
protocol, and de-registration protocol. We are not often adding changes
here, e.g. when in our lifetime do you expect to publish GSAKMP v2
registration protocol in the IETF? even the foreseeable future universe of
IETF standardized rekey protocols does not present a large number of
CHOICES.

As I expressed above, I do not foresee a high rate of expansion in the set
of group key management protocols defined by the IETF. Most of the
forseeable change is due to defining new GSAKMP versions on a timescale of
years. so the extensibility overhead of "open'ing the spec" is not
onerous.

Of course, OCTET STRING syntax can be made to work. My main problem with
using OCTET STRING in this context is that historically OCTET STRING with
textual conventions have been where vendor-specific undocumented data
structures can creep in (or bugs in a vendor's encoding of the standard).
So the core PT spec must state a procedure saying how one error checks
each octet in the OCTET STRING for standards compliance, and how to
gracefully skip things you don't understand. if this procedure is
underspecified then we could stumble into inter-op problems.

br,
	George