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

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.

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

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

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:aglo@citi.umich.edu] 
Sent: Thursday, April 05, 2007 2:53 PM
To: kitten@lists.ietf.org; spkm@ietf.org
Subject: [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.txt

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

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