[SPKM] RE: Comments on draft-zhu-pku2u-01.txt

Jeffrey Hutzelman <jhutz@cmu.edu> Sat, 17 March 2007 07:05 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 1HSSyg-0003PF-Pp; Sat, 17 Mar 2007 03:05:22 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSSyf-0003OF-ID for spkm@ietf.org; Sat, 17 Mar 2007 03:05:21 -0400
Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HSSye-00084X-7A for spkm@ietf.org; Sat, 17 Mar 2007 03:05:21 -0400
Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa26374; 17 Mar 2007 3:04 EDT
Date: Sat, 17 Mar 2007 03:04:39 -0400
From: Jeffrey Hutzelman <jhutz@cmu.edu>
X-X-Sender: <jhutz@minbar.fac.cs.cmu.edu>
To: "Liqiang(Larry) Zhu" <lzhu@windows.microsoft.com>
In-Reply-To: <CAAAEFE273EAD341A4B02AAA9CA6F733051CA996@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com>
Message-ID: <Pine.LNX.4.33L.0703170259260.1982-100000@minbar.fac.cs.cmu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Cc: kitten@lists.ietf.org, andros@citi.umich.edu, Olga Kornievskaia <aglo@citi.umich.edu>, Michael.Eisler@netapp.com, spkm@ietf.org
Subject: [SPKM] RE: Comments on 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

On Fri, 16 Mar 2007, Liqiang(Larry) Zhu wrote:

> 6. User to User when applied by server policy
>
>    In the case that the client application doesn't know that a service
>    requires user-to-user authentication, and requests and receives a
>    conventional KRB_AP_REP, the client will send the KRB_AP_REP
>    request, and the server will respond with a KRB_ERROR token as
>    described in RFC1964, with a msg-type of
>    KRB_AP_ERR_USER_TO_USER_REQUIRED (0x45). The server may optionally
>    pass the TGT in the data field of this error message. In response to
>    this error, the initiator sets flags and returns a
>    GSS_C_CONTINUE_NEEDED so that the next round uses the mechanism
>    described in section 4.

While this is a token carrying a KRB_ERROR, it's not an "error token" in
the sense that we're talking about.  In the context of Olga's and my
comments, an "error token" is one which causes the peer to abort context
establishment and return an error status to its caller.  Such a token
should never be returned with GSS_S_CONTINUE_NEEDED, because no reply is
expected.

-- Jeff


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