Subject: [MSEC] Resolving the DISCUSS on draft-ietf-msec-policy-token-sec-05.txt (Summary)

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 23 Jan 2006 13:53:50 -0800

Hi all,

There is an "Abstain" and a "DISCUSS" recorded as part of the IESG 
evaluation of the Policy Token spec.  Andrea, Uri, and Russ have 
worked diligently to come up with the following resolution.  Please 
look at the following link for the history of the document evaluation:

https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1841&filename=draft-ietf-msec-policy-token-sec

If you have any thoughts or objections to the new text, please post 
your comments ASAP to the list.

thanks and regards,
Lakshminath

>Please look for <Res></Res> (overall consensus so far) and <LD></LD> 
>(issues that haven't been covered yet, there is only one, on the 
>IANA comment) below.
>
>best regards,
>Lakshminath
>
>
>
>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.
>
><Res>
>The EXPORTS statement is to be removed so that any structure def can be
>exported.
>
></Res>
>
>
>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?
>
><Res>
>A Policy Token version indicator is to be added to the TokenID.
>
></Res>
>
><Res>
>Russ provided the following example that we might use:
>   TBSCertificate  ::=  SEQUENCE  {
>      version         [0]  Version DEFAULT v1,
>      ....
>
>   Version  ::=  INTEGER  {  v1(0), v2(1), v3(2)  }
>
>
></Res>
>
><Res>
>"Implementations encountering unknown protocol identifiers MUST handle
>this gracefully by providing indicators that an unknown protocol is among
>the sequence of permissible protocols.  If the unknown protocol is the only
>allowable protocol in the sequence, then the implementation cannot support
>that field and the member cannot join the group.
>It is a matter of local policy whether a join is permitted when
>an unknown protocol exists among other allowable, known protocols."
>
></Res>
>The above will be added to provide
>handling instructions when encountering unknown protocols.
>
>
><Res>
>Under the main token structure it will say that additional protocols
>SHOULD NOT be added unless the MSEC architecture changes.
>
></Res>
>
>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?
>
><Res>I understand the issue, but the token's purpose is to tie the 
>abstract MSEC
>architecture to a configurable system.  The MSEC architecture allows for any
>of these protocols for registration, de-registration, etc. and does not
>specify what the mandatory to implement protocols are.  To say that the
>appendix B and appendix C protocols are the mandatory-to-implement protocols
>would mean that the MSEC architecture now requires those protocols.  This is
>one case where I believe a mandatory to implement scheme would be a
>disservice to the community.
>
>Interoperability testing for the token, really becomes system
>interoperability testing vs. protocol interoperability testing.
></Res>
>
>
>4) IANA Comments:
>The IANA Considerations section requests that 13 object identifiers 
>be assigned.
>In which registry should these be assigned?  IANA needs clarification.
>
>
><Res>
>Statement to IANA section will essentially say that the spec is extended
>through specification.  Those specifying new objects will register them with
>IANA.  Those that change the structure of the PT must change the version
>indicator.
>
></Res>
>
><LD>
>The resolution does not address the question on "which registry" 
>should be used.  I think this requires a new registry, right?
></LD>

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

---

From: George Gross <[email-masked]>
Date: Mon, 23 Jan 2006 16:56:29 -0500 (EST)

Hi,

I support the proposed set of resolutions listed below. Adding the PT
version field incurrs a minor change in core PT implementation, but it
makes sense, and it is not a hardship to add this.

As for the core PT IANA registry, my first thought is that creating a
distinct new IANA registry seems like the best way forward. I had not
considered the "how to register at IANA" aspect of the PT design
lifecycle. the current and our future MSEC OID definitions do need a home.

I'm assuming that there isn't an IANA registry already in existence that
could be placed into this role? the GSAKMP one is not the right place for
this, since the core PT is key management protocol independent...

hth,
	George

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 24 Jan 2006 11:24:54 -0800

Hi all,

A small correction in my email below.  The responses to #1 and #2 are 
to be read together as responses to issues #1 and #2. (I posted the 
correction immediately to the response to Brian C, but not here)

Hi George,

Thanks for your notes.  Here is the latest from Sam on this:

<Sam>
So, the response to issue 1 does not actually have anything to do with
issue 1 at all.  However, I think the response to issue 2 also happens
to be a valid responsse to issue 1.

The down side of how MSEC is handling versioning is that they cannot
extend their structures without breaking old implementations.  In
order to extend the structure, they need to increase the version
number.  If they increase the version number and add fields, an
implementation that does not know about these new fields must reject
the encoding per 1997 ASN.1.

An alternate strategy they could have adopted would be to add
extensibility markers.  Under that strategy, they could add fields and
arms to sequences and choices.  Receivers unfamiliar with a new field
or arm would simply ignore that field or arm.

Another alternative would be to cite an old enough ASN.1 specification
before extensibility markers were introduced and claim that
implementations must accept unknown additions to sequencesand choices.
</Sam>

Any comments are welcome.

regards,
Lakshminath

---

From: George Gross <[email-masked]>
Date: Tue, 24 Jan 2006 15:47:27 -0500 (EST)

Hi Lakshminath,

Arguably, the issue of policy token version handling is somewhat related
to the broader MSEC problem of "composite groups". This problem is not
documented in the MSEC architecture RFC3740, but since that RFC's
publication it has become prominient as part of the "how do we transition
from MD5/SHA-1 to SHA-ng" issue. As an aside, I'll mention that I owe
Brian some verbage on this topic as part of the MSEC IPsec extensions
draft. He and I arrived at a compromise on this topic off list earlier
this month, plz stay tuned for the new draft.

In the context of handling policy token versions, a composite group is the
logical cryptographic group formed by the union of two sub-groups: those
endpoints that understand and implement core PT v1 and those endpoints
that understand and implement core PT v2 (and presumably v1 too). From an
operational point of view, it is impractical to flash cut a large-scale
group of endpoints from v1 to v2. Since there are usually fewer of them,
one could operationally manage that all GCKS would be upgraded to support
both v1 and v2 core PT. Consequently, an endpoint joining a composite
group must signal to the GCKS as part of its registration protocol
exchange which sub-group it will participate in. For example, the GSAKMP
section 7.1.2 defines this version processing. There is also an
explaination how to combine v1 and v2 information (including a PT payload)
in one GSAKMP message without confusing v1 endpoints. When admitting a v1
endpoint into the group, the GCKS would download a v1 policy token, and
direct the endpoint to receive v1 sub-group data SA transmissions.

So I do not share Sam's concerns about the version backward compatibility
problem. In fact, I would suggest that the GSAKMP co-authors have
considered this problem more carefully than some other IETF protocols, and
we do have a proactive solution specified in our current drafts.

With regard to using 1997 ASN.1 extensibility marker mechanisms, I admit I
am not an ASN.1 language lawyer ;o) My experience is with an ASN.1
compiler that handles the 1990 ASN.1 dialect. Perhaps the "fix" here is to
make the core PT draft's normative reference point at the ASN.1 1990
version rather than 1997? It is not clear to me what benefit ASN.1 1997
brings to the table, given the above version handling strategy does not
depend on its extensibility markers.

hope this clarifies...

br,
	George