Group Security Policy Token v1
draft-ietf-msec-policy-token-sec-06

[Ballot comment]
The extra words in the introduction in -06 sort-of take care of
the protocol problem (3) but I can foresee difficulties if
this ever comes up for consideration as Draft Standard.

I think the changes in the -06 version are at the absolute
minimum level to deal with the ASN.1 extensibility problems (1)
and (2). I'm sure Sam is correct that there may be future
scenarios where the ASN.1 parse fails in some implementations
attempting to join a group. However, my expertise in this area is
fairly limited, so I will switch to no-objection and wish the
implementors and users the best of luck.

[Ballot discuss]
Picking up Sam's points

1) Misuse of ASN.1.  The document cites the 1997 ASN.1, but has a
number of choices and structures that seem like they are intended to
be extended in the future.  Without extensibility markers, a
conforming implementation will reject a sequence or choice with
elements not permitted by the abstract syntax.

2) There is no extensibility or versioning strategy described in the
document.  How do we add fields?  What should recipients of a token do
if they do not understand part of it?


3) It's not clear that the GSAKMP document combined with this document
provides enough mandatory to implement features that any two
implementations of this specification will work together.  The GSAKMP
document specifies mandatory to implement mechanisms for GSAKMP.
However the policy token allows for a wide variety of combinations of
protocols.  For example, a policy token could specify one protocol for
registration, one protocol for rekey, and a completely different
protocol for de-registration.  If only one of these is GSAKMP, what
happens?  Where is it specified what combinations a GM, a GC/KS etc
must support in terms of policy token contents?

[Ballot comment]
I'm abstaining on this draft because I believe that the mechanism
described is fundamentally too complicated for reasonable
implementation.  I think this mechanism embodies an extension of a
design philosophy we tried with the first version of IPsec: very
extensible.  Implementation experience has caused us to back off from
that design philosophy significantly with RFC 3401 and surrounding
documents.  I believe that multicast security is more complicated and
thus requires more effort spent avoiding unnecessary complexity and
testing all the options not less.

The following are issues that would probably justify a discuss.  At
least at this point I'm not going to hold a discuss on these issues
because I think the document would still be a incorrect approach if
these issues are fixed and because I do not want to spend the time
fixing these issues.  Other ADs may wish to consider whether they wish
to file a discuss on these issues.

1) Misuse of ASN.1.  The document cites the 1997 ASN.1, but has a
number of choices and structures that seem like they are intended to
be extended in the future.  Without extensibility markers, a
conforming implementation will reject a sequence or choice with
elements not permitted by the abstract syntax.

2) There is no extensibility or versioning strategy described in the
document.  How do we add fields?  What should recipients of a token do
if they do not understand part of it?


3) It's not clear that the GSAKMP document combined with this document
provides enough mandatory to implement features that any two
implementations of this specification will work together.  The GSAKMP
document specifies mandatory to implement mechanisms for GSAKMP.
However the policy token allows for a wide variety of combinations of
protocols.  For example, a policy token could specify one protocol for
registration, one protocol for rekey, and a completely different
protocol for de-registration.  If only one of these is GSAKMP, what
happens?  Where is it specified what combinations a GM, a GC/KS etc
must support in terms of policy token contents?

However my concern with the document is deeper than these actionable
discuss issues.


It seems that there are too many options for this system to be
reasonably configured by operators or users.
Here are some questions to guide thought about where there might be
too many options.

Why do you need the ability to use completely different registration,
de-registration and rekey protocols?  Wouldn't it be sufficient to say
that you use GSAKMP (or some other protocol) for all the operations.
Possibly you would have a way to say that some operations are not
needed.

Why do you need to specify separate signing algorithms and hashes for
every operation?  Why would you want the ability to have a different
signature for parts of de-registration than for registration?  Why are
there so many different points at which a single trust anchor CA is
specified yet no mechanism is provided  to get the key corresponding
to the key identifier?  Why do you need different CA trust anchors at
every  point?  What's wrong with using a single trust infrastructure
for registration and de-registration?  Why does the policy token need
to be so generic; would we not be better off making it GSAKMP
specific?    Is the naming architecture and authorization architecture
the right balance of flexible and easy to use?