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

Martin Rex <Martin.Rex@sap.com> Wed, 18 April 2007 21:04 UTC

Return-path: <spkm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeHK3-0005BM-2s; Wed, 18 Apr 2007 17:04:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeHK2-0005Ah-Km; Wed, 18 Apr 2007 17:04:14 -0400
Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeHJx-0001ir-5V; Wed, 18 Apr 2007 17:04:14 -0400
Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id XAA19449; Wed, 18 Apr 2007 23:03:56 +0200 (MESZ)
From: Martin Rex <Martin.Rex@sap.com>
Message-Id: <200704182103.l3IL3tQb025387@fs4113.wdf.sap.corp>
Subject: Re: [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.txt
To: Nicolas.Williams@sun.com
Date: Wed, 18 Apr 2007 23:03:55 +0200
In-Reply-To: <20070418205355.GS4375@Sun.COM> from "Nicolas Williams" at Apr 18, 7 03:53:55 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-SAP: out
X-SAP: out
X-SAP: out
X-SAP: out
X-SAP: out
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Cc: kitten@lists.ietf.org, Martin.Rex@sap.com, spkm@ietf.org, aglo@citi.umich.edu
X-BeenThere: spkm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: martin.rex@sap.com
List-Id: Low Infrastructure Public Key GSS mechanism <spkm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/spkm>, <mailto:spkm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/spkm>
List-Post: <mailto:spkm@ietf.org>
List-Help: <mailto:spkm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/spkm>, <mailto:spkm-request@ietf.org?subject=subscribe>
Errors-To: spkm-bounces@ietf.org

Nicolas Williams wrote:
> 
> On Wed, Apr 18, 2007 at 10:46:41PM +0200, Martin Rex wrote:
> > 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 
> > > > 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.
> > 
> > NOPE, it is significantly different from rfc1964 and rfc4121.
> 
> Regardless, RFC2743 only requires it on the initial context token.

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

> 
> 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.

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.

> 
> 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 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

_______________________________________________
SPKM mailing list
SPKM@ietf.org
https://www1.ietf.org/mailman/listinfo/spkm