Subject: [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.txt

From: Olga Kornievskaia <[email-masked]>
Date: Thu, 05 Apr 2007 17:52:52 -0400

Is PKU2U meant to be a GSS API mechanism or a stand alone security 
protocol? The abstract seems to imply that pku2u could be a stand alone 
protocol. However, the 1st sentence of the Section 5 says that pku2u 
"can only be used in conjunction with GSS-API".

In Section 5,

  The syntax of the initial context establishment token follows the
  initialContextToken syntax defined in Section 3.1 of [RFC2743].
  PKU2U is identified by the Objection Identifier (OID) id-kerberos-
  pku2u.

     id-kerberos-pku2u ::=
       { iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2)
         pku2u(7) }

  Subsequent context establishment tokens MUST NOT be encapsulated in
  this GSS-API generic token framing.

First, I hope that the 1st sentence refers to "tokens" not just the 1st 
(AS_REQ) token. As its written, it says that AS_REQ token is framed but 
the AS_REP token is not which doesn't make sense.

Second, what does the "subsequent context establishment tokens" refer 
to? AP_REP/AP_REQ or a something else (ie. , new pku2u sessions)? 
Furthermore, there shouldn't be any unframed tokens in GSS-API mechanism.

I propose to remove this sentence from the draft. What would be left is 
the description how to frame context establishment tokens 
(AS_REQ/AS_REP) and then the rest are treated as per-message token 
according to rfc4121.

_______________________________________________
SPKM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/spkm

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 5 Apr 2007 18:07:30 -0500

> "can only be used in conjunction with GSS-API".

GSS mechanisms can be stand-alone too, I suppose.  PKU2U has got to be
intended to be a standards-track GSS-API mechanism, else why are we
here?

> the AS_REP token is not which doesn't make sense.

No, it *does* make sense.  RFC2743 only requires the pseudo-ASN.1 DER
header on the initial context token.  It does not require it on any
other tokens at all.

RFC1964 went beyond this and required the use of that header on all of
the Kerberos V GSS mechanism's context and per-message tokens.  We all
recognize that there was little or no point to this, so when we were
working on RFC4121 we wanted to dispense with that header on all but the
initial context token (that one being required by RFC2743) and settled
for not having that header on per-message tokens but keeping it on all
context tokens (primarily because of packet inspection tools that are
used to them having that header, as I recall).

> to? AP_REP/AP_REQ or a something else (ie. , new pku2u sessions)? 

PKU2U's context token exchanges look like this:

I: <RFC2743 header> AS-REQ
A: AS-REP
I: AP-REQ
A: AP-REP

Here the first one is the "initial context establishment token" and the
subsequent three tokens are ""subsequent context establishment tokens."

> Furthermore, there shouldn't be any unframed tokens in GSS-API mechanism.

This is incorrect.

> (AS_REQ/AS_REP) and then the rest are treated as per-message token 

You might argue that if you'd like to build PKU2U as a stackable
mechanism that stacks on top of RFC4121 *then* having the RFC2743 header
on the AP-REQ/AP-REP tokens in the PKU2U spec would help keep your
implementation simple.  As a proponent of stackable mechanisms I tend to
agree, but because this stackable mechanism in particular would be
stackable only on top of RFC1964/RFC4121 it would be OK for the
implementation to know to remove the header on output/insert the header
on input.

[Note to skeptics: yes, such a stackable mechanism would need a special
interface by which it could turn acquire a CREDENTIAL HANDLE for the
Kerberos V mechanism using a Ticket, ticket session key and ancilliary
data.  In Solaris we have gss_acquire_cred_with_password(); we could
easily add gss_acquire_cred_with_ticket()...]

I feel loath to perpetuate the mistake made in RFC1964 of adding that
header that had been intended only for the initial context token to all
tokens.

Nico
--

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 6 Apr 2007 00:28:27 -0700

Olga Kornievskaia wrote:
> Is PKU2U meant to be a GSS API mechanism or a standalone security 
> protocol? The abstract seems to imply that pku2u could be a stand 
> alone protocol. However, the 1st sentence of the Section 5 says that 
> pku2u "can only be used in conjunction with GSS-API".

PKU2U as defined here requires the use of GSS-API. I do not know if you
have objections to this requirement.

> (AS_REQ) token. As its written, it says that AS_REQ token is framed 
> but the AS_REP token is not which doesn't make sense.

Your understanding is correct. Only the first message has the framing.
This is consistent with RFC4121 and RFC4178.

> Furthermore, there shouldn't be any unframed tokens in GSS-API
mechanism.

Only the first message has the token framing. This is how all other
GSS-API mechanisms work today.

--larry

-----Original Message-----
From: Olga Kornievskaia [mailto:[email-masked]] 
Sent: Thursday, April 05, 2007 2:53 PM
To: [email-masked]; [email-masked]
Subject: [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.txt

In Section 5,

     id-kerberos-pku2u ::=

Second, what does the "subsequent context establishment tokens" refer 
to? AP_REP/AP_REQ or a something else (ie. , new pku2u sessions)? 
Furthermore, there shouldn't be any unframed tokens in GSS-API
mechanism.

---

From: Martin Rex <[email-masked]>
Date: Wed, 18 Apr 2007 22:46:41 +0200 (MEST)

Liqiang wrote:
> 
> Olga Kornievskaia wrote:
> > First, I hope that the 1st sentence refers to "tokens" not just the 
> > 1st (AS_REQ) token. As its written, it says that AS_REQ token is framed 

NOPE, it is significantly different from rfc1964 and rfc4121.

rfc4121 only dropped the framing on the per-message tokens, it
still uses the same=full framing as rfc1964 for all of the context
level tokens:

quoting rfc4121:

   [RFC1964] describes the GSS-API mechanism for Kerberos Version 5.  It
   defines the format of context establishment, per-message and context
   deletion tokens, and uses algorithm identifiers for each cryptosystem
   in per-message and context deletion tokens.

   The approach taken in this document obviates the need for algorithm
   identifiers.  This is accomplished by using the same encryption
   algorithm, specified by the crypto profile [RFC3961] for the session
   key or subkey that is created during context negotiation, and its
*  required checksum algorithm.  Message layouts of the per-message
*  tokens are therefore revised to remove algorithm indicators and to
   add extra information to support the generic crypto framework
   [RFC3961].

I don't like the idea of dropping the generic framing on any of
the context level tokens.

> GSS-API mechanisms work today.

The GSS-API spec only requires the generic token framing on the initial
context token.  There is no requirement for any other (context level
and message protection tokens).

rfc4121 is actually the only mechanism that I know which does not
use the token, and it only does so for the message protection tokens.

rfc-1964 (Kerberos 5 gssapi mechanism) has been using the generic framing
on all tokens, as well as rfc-2025 (Simple Public Key GSS-API mechanisms).

Quoting rfc-2025 (SPKM):

   The above GSS-API framing shall be applied to all tokens emitted by
   the SPKM GSS-API mechanism, including SPKM-REP-TI (the response from
   the Target to the Initiator), SPKM-REP-IT (the response from the
   Initiator to the Target), SPKM-ERROR, context-deletion, and per-
   message tokens, not just to the initial token in a context
   establishment exchange.  While not required by RFC-1508, this enables
   implementations to perform enhanced error-checking.

and using this framing throughout is an extremely reasonable approach
(you may remember that I opposed that change in rfc4121... :)
section 6.1 of rfc2025:

6.1. SPKM_Parse_token call
  [...]

   If all tokens are framed as suggested in RFC-1508, Appendix B
   (specified both in the Kerberos V5 GSS mechanism [KRB5] and in this
   document), then any mechanism implementation should be able to return
   at least the mech_type parameter (the other parameters being NULL)
   for any uncorrupted input token.  If the mechanism implementation
   whose SPKM_Parse_token() function is being called does recognize the
   token, it can return token_type so that the application can
   subsequently call the correct GSS function. 

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 18 Apr 2007 15:53:55 -0500

> NOPE, it is significantly different from rfc1964 and rfc4121.

Regardless, RFC2743 only requires it on the initial context token.

We should probably consider whether we want to RECOMMEND, or even
REQUIRE that that header be added to all security context establishment
tokens, not just the initial one.

But until somebody tables that matter we should not consider
RFC1964/4121 as imposing such a requirement on other mechanism that use
different mechanism OIDs.

That said, there's this interesting question: PKU2U re-uses RFC4121 for
everything following PKU2U's first two security context tokens (which
are KDC messages between the initiator and the acceptor acting as a
pseudo-KDC), so, should those context tokens lifted from RFC4121 bear
this header?

I could go either way.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Wed, 18 Apr 2007 23:03:55 +0200 (MEST)

> Regardless, RFC2743 only requires it on the initial context token.

I know.  I did confirm this a few lines later.

> different mechanism OIDs.

Require, because it will amount to less code, less complexity and less
confusion.  The overhead is negligable.  I don't expect any implementation
of PKU2U to NOT provide rfc1964/rfc4121 functionality as well, despite
the seperate mechanism OID.

> pseudo-KDC), so, should those context tokens lifted from RFC4121 bear

I really want to see the generic framing on all context level tokens
(which is what you meant by header, I assume).

Could it be that you actually didn't want to ask about the framing,
but about the mechanism OID within the header (if it is present)?

I'd like to see the generic framing, and I'd like to see it with
the same mechanism OID as in the initial context token (which is
different from rfc1964/rfc2141).

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 18 Apr 2007 16:10:14 -0500

> the seperate mechanism OID.

I can't tell if RFC2478/4178 require that header on non-initial SPNEGO
context tokens, but our implementation does NOT put it on any SPNEGO
context token other than the initial one.  Did we miss this?

This requirement, if we wanted to make it, would have to apply only to
future Standards-Track mechs.

> (which is what you meant by header, I assume).

Yes, that's what I meant by 'header'.

> but about the mechanism OID within the header (if it is present)?

No.

> different from rfc1964/rfc2141).

Yes, if the generic header is on all context tokens then the same OID
has to be used for all those context tokens for any given security
context.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Thu, 19 Apr 2007 16:16:16 +0200 (MEST)

> future Standards-Track mechs.

That requirement *DID* exist in rfc-2478.  So there seems to be
a completely backwards incompatible change in rfc-4178.
At least rfc-4178 is very explicit what it wants in 4.2.

Rfc2478 was always meant to use the generic framing on all context
tokens (they're called "negotiation tokens").  It's true that this
is not explicitly spelled out, but at the time when rfc-2478 was
produced, both of the gss-api mechanism in the IETF/CAT discussion
(rfc-1964 Kerberos 5, rfc-2025 SPKM) was using the generic framing
on all of the tokens (context level AND per-message tokens), and
the little words about the issue in rfc-2478:

  3.2.1. Syntax

     This section specifies the syntax of the corresponding
     "innerContextToken" field for the first token and subsequent
     negotiation tokens. During the mechanism negociation, the
     "innerContextToken" field contains the ASN.1 structure
     "NegociationToken" given below, encoded using the DER encoding
     conventions.

talks about "innerContextToken" for the first **AND** subsequent
negotiation tokens, which implies that all negotiation (=context level)
tokens are built in the same fashion an all carry the generic framing.

I thought there was an interop of SPNEGO-implementations a while ago--
I would have expected this issue to become apparent if it was ambiguous,
provided that there are truely independent implementations of _the_spec_.

In TLS it regularly happens that there is an early adopter of a new
feature and all others follow the lead instead of the spec, and as
a result breaking the spec in various subtle ways (i.e. I just noticed
that SSLv3 and TLS v1.0 prohibit the use of an empty CAlist in the
CertificatRequest message from the server, TLS v1.1 secretly changes
this in a backwards incompatible fashion without the slightest warning
and OpenSSL seems to have violated the SSLv3 and TLSv1 specs from the
beginning).

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 19 Apr 2007 09:56:15 -0500

> tokens are built in the same fashion an all carry the generic framing.

I don't agree with that reading of the text.  Regardless, if there are
posts on the old CAT list about this saying that the generic framing is
expected on non-initial context tokens then I agree that RFC4178 made a
change.  But we can't all be reading mailing lists from years ago --
RFCs shouldn't miss such things, and RFC2478 was missing a lot of
details (e.g., what ASN.1 encoding to use).

> provided that there are truely independent implementations of _the_spec_.

There truly independent implementations of _RFC4178_ were tested.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Thu, 19 Apr 2007 17:52:23 +0200 (MEST)

[...]
> There truly independent implementations of _RFC4178_ were tested.

As I said, rfc-4178 is very explicit what it wants in section 4.2.
and this fact is highly appreciated.

I would have expected this backwards incompatible change to become
apparent when interop-testing backwards compatibility with exiting
(i.e. legacy) implementations of SPNEGO.  SPNEGO started out as SNEGO (without
the handshake protection and without the optimistic token), and
IIRC there (once) was a sample implementation of SNEGO by Bull
announced by Denis Pinkas:

  From: [email-masked] (Denis Pinkas)
  Message-Id: <[email-masked]>
  Subject: Simple GSS-API negotiation available
  To: [email-masked] (IETF CAT WG)
  Date: Tue, 27 Feb 1996 17:37:43 +0100 (NFT)

  An implementation of the Simple GSS-API negotiation mechanism
  (Internet-Draft draft-ietf-cat-snego-01.txt, 19 February 1996)
  is now available at the following URL :

      ftp://ftp.enst-bretagne.fr/pub/security/gssneg.tar.gz

  It uses SNACC 1.1 libraries for encoding and decoding of PDUs
  described in ASN.1. The SNACC compiler can be found at:

Unfortunately, that "reference" implementation appears to be
no longer available anywhere.

Anyway -- there seemed to be very few independent implementations
of rfc-2478 and only one implementation with a significant installed
base.  Personally, I never liked SPNEGO, and the claimed abiguities
in rfc-2748 seemed to cause a certain amount of interoperability
problems anyway, so I think it is OK if rfc-4178 prefers interoperability
with a significant installed base to interoperability with rfc-2478.

When a feature of a revised spec is significantly clarified over the
previous version of the spec, a backwards interoperability warning
should be added.  This is missing in rfc-4178 4.2.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 19 Apr 2007 11:08:05 -0500

> should be added.  This is missing in rfc-4178 4.2.

It is certainly not missing from where it belongs -- see RFC 4178,
Appendix C:

   ...
   The working group was not aware of any RFC 2478 implementations
   deployed on the Internet.  Even if there are such implementations, it
   is unlikely that they will inter-operate because of a critical flaw
   in the description of the encoding of the mechanism list in RFC 2478.

   With the approach taken in this specification, security is ensured
   between new implementations all the time while maintaining
   interoperability with the implementations deployed within the IETF
   community.  The working group believes that this justifies breaking
   compatibility with a correct implementation of RFC 2478.
   ...

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Thu, 19 Apr 2007 19:18:02 +0200 (MEST)

>    compatibility with a correct implementation of RFC 2478.

I disagree.

As I said, I want to see a "change warning" _exactly_ where a feature
or detail is (incompatibly) changed, i.e. section 4.2. not in an Appendix.

The particular change is not even mentioned in the text you quoted,
probably because it wasn't realized as a change by the authors
and by reviewers.

If a change/clarification is locally highlighted as such, it will
much more likely result in adequate thought and review about the
change/clarification.

-Martin