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

Olga Kornievskaia <aglo@citi.umich.edu> Thu, 05 April 2007 21:52 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 1HZZt2-0002e2-EO; Thu, 05 Apr 2007 17:52:56 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZZt0-0002V5-Nj for spkm@ietf.org; Thu, 05 Apr 2007 17:52:54 -0400
Received: from citi.umich.edu ([141.211.133.111]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HZZsz-0004qI-Cz for spkm@ietf.org; Thu, 05 Apr 2007 17:52:54 -0400
Received: from [141.211.133.26] (yoga.citi.umich.edu [141.211.133.26]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "aglo", Issuer "CITI Production KCA" (verified OK)) by citi.umich.edu (Postfix) with ESMTP id DACAD392A1; Thu, 5 Apr 2007 17:52:52 -0400 (EDT)
Message-ID: <46156FB4.4070007@citi.umich.edu>
Date: Thu, 05 Apr 2007 17:52:52 -0400
From: Olga Kornievskaia <aglo@citi.umich.edu>
User-Agent: Thunderbird 1.5.0.10 (X11/20070301)
MIME-Version: 1.0
To: kitten@lists.ietf.org, spkm@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Cc:
Subject: [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.txt
X-BeenThere: spkm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

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
SPKM@ietf.org
https://www1.ietf.org/mailman/listinfo/spkm