From spkm-bounces@ietf.org Fri Mar 16 16:55:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSJSa-0001Qz-Q7; Fri, 16 Mar 2007 16:55:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSJSZ-0001Qb-Fs for spkm@ietf.org; Fri, 16 Mar 2007 16:55:35 -0400 Received: from citi.umich.edu ([141.211.133.111]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSJPk-0004pi-Vj for spkm@ietf.org; Fri, 16 Mar 2007 16:52:42 -0400 Received: from [141.211.133.26] (yoga.citi.umich.edu [141.211.133.26]) (using TLSv1 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 7B38439278; Fri, 16 Mar 2007 16:52:40 -0400 (EDT) Message-ID: <45FB0398.3080406@citi.umich.edu> Date: Fri, 16 Mar 2007 16:52:40 -0400 From: Olga Kornievskaia User-Agent: Thunderbird 1.5.0.10 (X11/20070301) MIME-Version: 1.0 To: "Liqiang(Larry) Zhu" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: Michael.Eisler@netapp.com, andros@citi.umich.edu, kitten@lists.ietf.org, 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org Section 3 If initially the initiator has a service ticket to the acceptor, the initiator, acting as the client in the parlance of [RFC4120], performs the client-server authentication exchange according to [RFC4121] and Section 3.2 of [RFC4120], with the acceptor acting as the server. Why state this? In the motivation section, it has been stated that: "there is no trusted third party in such environments." While it is stated that "consequently the Kerberos protocol as defined in [RFC4120] and [RFC4556] is inadequate to provide security services ", this document's writing heavily depends on it and PKU2U is basically rfc4556 where the server is not a KDC. If all goes well, processing the KRB_AS_REQ message will result in the creation of a ticket for the initiator to present to the acceptor and the response is a KRB_AS_REP message generated according to Section 3.1.3 of [RFC4120]. Isn't there a missing reference to the Section 3.2.3 of RFC4556. Unlike KDC and principal, acceptor and initiator don't share any secrets. PKINIT's PA_PK_AS_REP is needed here for the initiator to make use of the ticket created by the acceptor. In all cases, GSS_Accept_security_context() returns GSS_S_CONTINUE_NEEDED status [RFC2743] and the output token is a KRB_AS_REP message if a ticket was created or a KRB_ERROR message if there was an error while processing the request or the local policy prevented a ticket from being issued. If the acceptor returns GSS_S_CONTINUE_NEEDED in the case of an error, what happens when the initiator after processing the error token decides to stop, will the server just hang there in the continue needed state? Is having a MUST for PKINIT's EKUs too restrictive? Since this is a GSS API mechanism what about QoP handling and channel bindings? Token ids are defined for KRB_AS_REQ and KRB_AS_REP but not for KRB_ERROR? This draft does not support non-Kerberos environments. By that I mean, a Kerberos domain must exist and users of PKU2U must have Kerberos principal names. Name type NT-X500-PRINCIPAL which is rfc2253 string representation of the distinguished name does not produce a canonical name. What happens when the initiator rejects the AS-REP tokens sent by the acceptor (ie., fails to verify acceptor's certificate)? Does it generate an error token? Perhaps last paragraph of Section 6 can have a more detailed explanation that doesn't require the user to go search for a different draft to find our that AP_REQ should carry TYPED_DATA of type TD_IAKERB_FINISHED. I'm sure i'm missing something but why is there a need to tie AS_REQ/REP to AP_REQ/REP no such ties exist in original Kerberos message flow? Naming needs work. Comments made about naming in SPKM3 apply here. Liqiang(Larry) Zhu wrote: > Here is the updated PKU2U. Please review it and see if it has addressed > all concerns. > > Thanks, > > --Larry > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Tuesday, February 27, 2007 3:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-zhu-pku2u-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Public Key Cryptography Based User-to-User > Authentication - (PKU2U) > Author(s) : L. Zhu, et al. > Filename : draft-zhu-pku2u-01.txt > Pages : 10 > Date : 2007-2-27 > > This document defines the public key cryptography based user-to-user > authentication protocol - PKU2U. This mechanism provides security > services in peer to peer networking environments without requiring a > trusted third party. Furthermore, the binding of PKU2U for the > Generic Security Service Application Program Interface (GSS-API) per > RFC2743 is defined based on RFC4121. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-zhu-pku2u-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-zhu-pku2u-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-zhu-pku2u-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Fri Mar 16 17:33:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSK3U-000196-45; Fri, 16 Mar 2007 17:33:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSK3S-00018t-BM; Fri, 16 Mar 2007 17:33:42 -0400 Received: from currant.srv.cs.cmu.edu ([128.2.194.193]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSK3Q-0001yi-2Q; Fri, 16 Mar 2007 17:33:42 -0400 Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by currant.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id l2GLXaNt003239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Mar 2007 17:33:37 -0400 (EDT) Date: Fri, 16 Mar 2007 17:33:35 -0400 From: Jeffrey Hutzelman To: Olga Kornievskaia , "Liqiang(Larry) Zhu" Message-ID: <729D2796944018A823D6E75A@sirius.fac.cs.cmu.edu> In-Reply-To: <45FB0398.3080406@citi.umich.edu> References: <45FB0398.3080406@citi.umich.edu> Originator-Info: login-token=Mulberry:013R2YmUeFDQ0paBAaEJvICHSPz8RkURFKksb+E50=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: kitten@lists.ietf.org, andros@citi.umich.edu, Michael.Eisler@netapp.com, spkm@ietf.org, Jeffrey Hutzelman 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org On Friday, March 16, 2007 04:52:40 PM -0400 Olga Kornievskaia wrote: > In all cases, GSS_Accept_security_context() returns > GSS_S_CONTINUE_NEEDED status [RFC2743] and the output token is a > KRB_AS_REP message if a ticket was created or a KRB_ERROR message if > there was an error while processing the request or the local policy > prevented a ticket from being issued. > > If the acceptor returns GSS_S_CONTINUE_NEEDED in the case of an error, > what happens when the initiator after processing the error token decides > to stop, will the server just hang there in the continue needed state? This is a good point. GSS_S_CONTINUE_NEEDED indicates that it will be necessary to make the call again with another token provided by the peer. When GSS_Init_sec_context or GSS_Accept_sec_context emits an error token, it should also return an appropriate error status, not GSS_S_CONTINUE_NEEDED. > Token ids are defined for KRB_AS_REQ and KRB_AS_REP but not for KRB_ERROR? The token ID for KRB_ERROR is defined in RFC 4121. > Perhaps last paragraph of Section 6 can have a more detailed explanation > that doesn't require the user to go search for a different draft to find > our that AP_REQ should carry TYPED_DATA of type TD_IAKERB_FINISHED. I'm > sure i'm missing something but why is there a need to tie AS_REQ/REP to > AP_REQ/REP no such ties exist in original Kerberos message flow? I'm not entirely sure what you're talking about here. The AS exchange is tied to a later AP exchange via the session key; this is true whether the AS exchange results in a TGT or directly in some other service ticket. However, this does not protect the integrity of the plaintext portion of the AS exchange, and in particular of PA-DATA contained in the AS-REQ, and this is generally considered to be a shortcoming of the current AS exchange. While this is likely to be fixed in the next update to the Kerberos protocol spec (see draft-ietf-krb-wg-rfc1510ter), it is also possible for a higher layer to perform an after-the-fact integrity check of the entire AS exchange, as IAKERB does. Whether this is necessary or a good idea is, of course, up for discussion. -- Jeff _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Fri Mar 16 22:01:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSOER-0004YV-Ct; Fri, 16 Mar 2007 22:01:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSOEP-0004YG-JQ for spkm@ietf.org; Fri, 16 Mar 2007 22:01:17 -0400 Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSOEJ-0002h6-7l for spkm@ietf.org; Fri, 16 Mar 2007 22:01:17 -0400 Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Fri, 16 Mar 2007 19:01:10 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) with Microsoft SMTP Server id 8.0.685.25; Fri, 16 Mar 2007 19:01:10 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3953); Fri, 16 Mar 2007 19:01:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Mar 2007 19:01:09 -0700 Message-ID: In-Reply-To: <729D2796944018A823D6E75A@sirius.fac.cs.cmu.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-zhu-pku2u-01.txt Thread-Index: AcdoEtQO7SIGAeLrSMWmArQGOGajUAAJP2ZA References: <45FB0398.3080406@citi.umich.edu> <729D2796944018A823D6E75A@sirius.fac.cs.cmu.edu> From: "Liqiang(Larry) Zhu" To: Jeffrey Hutzelman , Olga Kornievskaia X-OriginalArrivalTime: 17 Mar 2007 02:01:09.0740 (UTC) FILETIME=[21C58AC0:01C76838] X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: Michael.Eisler@netapp.com, kitten@lists.ietf.org, spkm@ietf.org, andros@citi.umich.edu 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org Jeff wrote: > This is a good point. GSS_S_CONTINUE_NEEDED indicates that it will be > necessary to make the call again with another token provided by the peer.=20 > When GSS_Init_sec_context or GSS_Accept_sec_context emits an error token,=20 > it should also return an appropriate error status, not=20 > GSS_S_CONTINUE_NEEDED. This is not necessary accurate. In the User2User protocol, http://www.watersprings.org/pub/id/draft-swift-win2k-krb-user2user-03.tx t, the server can return a KRB_ERROR with the GSS_S_CONTINUE_NEEDED status. =20 -----Original Message----- From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu]=20 Sent: Friday, March 16, 2007 2:34 PM To: Olga Kornievskaia; Liqiang(Larry) Zhu Cc: Michael.Eisler@netapp.com; andros@citi.umich.edu; kitten@lists.ietf.org; spkm@ietf.org; Nicolas Williams; Jeffrey Hutzelman Subject: Re: Comments on draft-zhu-pku2u-01.txt On Friday, March 16, 2007 04:52:40 PM -0400 Olga Kornievskaia=20 wrote: > In all cases, GSS_Accept_security_context() returns > GSS_S_CONTINUE_NEEDED status [RFC2743] and the output token is a > KRB_AS_REP message if a ticket was created or a KRB_ERROR message if > there was an error while processing the request or the local policy > prevented a ticket from being issued. > > If the acceptor returns GSS_S_CONTINUE_NEEDED in the case of an error, > what happens when the initiator after processing the error token decides > to stop, will the server just hang there in the continue needed state? This is a good point. GSS_S_CONTINUE_NEEDED indicates that it will be=20 necessary to make the call again with another token provided by the peer.=20 When GSS_Init_sec_context or GSS_Accept_sec_context emits an error token,=20 it should also return an appropriate error status, not=20 GSS_S_CONTINUE_NEEDED. > Token ids are defined for KRB_AS_REQ and KRB_AS_REP but not for KRB_ERROR? The token ID for KRB_ERROR is defined in RFC 4121. > Perhaps last paragraph of Section 6 can have a more detailed explanation > that doesn't require the user to go search for a different draft to find > our that AP_REQ should carry TYPED_DATA of type TD_IAKERB_FINISHED. I'm > sure i'm missing something but why is there a need to tie AS_REQ/REP to > AP_REQ/REP no such ties exist in original Kerberos message flow? I'm not entirely sure what you're talking about here. The AS exchange is=20 tied to a later AP exchange via the session key; this is true whether the=20 AS exchange results in a TGT or directly in some other service ticket.=20 However, this does not protect the integrity of the plaintext portion of the AS exchange, and in particular of PA-DATA contained in the AS-REQ, and=20 this is generally considered to be a shortcoming of the current AS=20 exchange. While this is likely to be fixed in the next update to the=20 Kerberos protocol spec (see draft-ietf-krb-wg-rfc1510ter), it is also=20 possible for a higher layer to perform an after-the-fact integrity check of=20 the entire AS exchange, as IAKERB does. Whether this is necessary or a=20 good idea is, of course, up for discussion. -- Jeff _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Fri Mar 16 22:45:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSOus-0007xV-9x; Fri, 16 Mar 2007 22:45:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSOuq-0007xJ-Pm for spkm@ietf.org; Fri, 16 Mar 2007 22:45:08 -0400 Received: from mailc.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSOup-0007lp-6E for spkm@ietf.org; Fri, 16 Mar 2007 22:45:08 -0400 Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.685.24; Fri, 16 Mar 2007 19:45:06 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) with Microsoft SMTP Server id 8.0.685.25; Fri, 16 Mar 2007 19:45:06 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3953); Fri, 16 Mar 2007 19:45:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Mar 2007 19:45:05 -0700 Message-ID: In-Reply-To: <45FB0398.3080406@citi.umich.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-zhu-pku2u-01.txt Thread-Index: AcdoDSFprb0POxqgQbCYxfYgNbK/WwAKwdRg References: <45FB0398.3080406@citi.umich.edu> From: "Liqiang(Larry) Zhu" To: Olga Kornievskaia X-OriginalArrivalTime: 17 Mar 2007 02:45:05.0968 (UTC) FILETIME=[45160300:01C7683E] X-Spam-Score: 0.0 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Cc: Michael.Eisler@netapp.com, andros@citi.umich.edu, kitten@lists.ietf.org, 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org Olga Kornievskaia wrote: > Why state this? In the motivation section, it has been stated that:=20 > "there is no trusted third party in such environments." While it is=20 > stated that "consequently the Kerberos protocol as defined in [RFC4120]=20 > and [RFC4556] is inadequate to provide security services ", this=20 > document's writing heavily depends on it and PKU2U is basically rfc4556=20 > where the server is not a KDC. This is designed for fast session resumption. When the initiator already obtained a service ticket in prior sessions, it can just use that cached ticket right away. > Isn't there a missing reference to the Section 3.2.3 of RFC4556. Unlike=20 > KDC and principal, acceptor and initiator don't share any secrets.=20 > PKINIT's PA_PK_AS_REP is needed here for the initiator to make use of=20 > the ticket created by the acceptor. RFC4556 updates RFC4120, unless there is something here specific to RFC4556, I do not see the need here. > Since this is a GSS API mechanism what about QoP handling and channel=20 > bindings? These are handled in the same way as described in RFC4121. > This draft does not support non-Kerberos environments. By that I mean, a=20 > Kerberos domain must exist and users of PKU2U must have Kerberos=20 > principal names. How was this deduced? What is a Kerberos domain? And it should not be needed. what environments are not supported? Can you expand on this?=20 > Name type NT-X500-PRINCIPAL which is rfc2253 string representation of=20 > the distinguished name does not produce a canonical name. PKU2U requires little endian order: The Distinguished Name contained in the PKU2U Kerberos principal name MUST begin with the most specific attribute and continue with progressively broader attrbiutes. With this constraint, is there a case where this does not produce a canonical name? > What happens when the initiator rejects the AS-REP tokens sent by the=20 > acceptor (ie., fails to verify acceptor's certificate)? Does it=20 > generate an error token? You can get an error token as in http://www.watersprings.org/pub/id/draft-swift-win2k-krb-user2user-03.tx t. but typically the acceptor returns an error and aborts. > Naming needs work. Comments made about naming in SPKM3 apply here. Can you point me to the comments, it would help. Thanks for the review. --larry -----Original Message----- From: Olga Kornievskaia [mailto:aglo@citi.umich.edu]=20 Sent: Friday, March 16, 2007 1:53 PM To: Liqiang(Larry) Zhu Cc: spkm@ietf.org; kitten@lists.ietf.org; Nicolas Williams; Michael.Eisler@netapp.com; andros@citi.umich.edu Subject: Re: Comments on draft-zhu-pku2u-01.txt Section 3 If initially the initiator has a service ticket to the acceptor, the initiator, acting as the client in the parlance of [RFC4120], performs the client-server authentication exchange according to [RFC4121] and Section 3.2 of [RFC4120], with the acceptor acting as the server. Why state this? In the motivation section, it has been stated that:=20 "there is no trusted third party in such environments." While it is=20 stated that "consequently the Kerberos protocol as defined in [RFC4120]=20 and [RFC4556] is inadequate to provide security services ", this=20 document's writing heavily depends on it and PKU2U is basically rfc4556=20 where the server is not a KDC. If all goes well, processing the KRB_AS_REQ message will result in the creation of a ticket for the initiator to present to the acceptor and the response is a KRB_AS_REP message generated according to Section 3.1.3 of [RFC4120]. Isn't there a missing reference to the Section 3.2.3 of RFC4556. Unlike=20 KDC and principal, acceptor and initiator don't share any secrets.=20 PKINIT's PA_PK_AS_REP is needed here for the initiator to make use of=20 the ticket created by the acceptor. In all cases, GSS_Accept_security_context() returns GSS_S_CONTINUE_NEEDED status [RFC2743] and the output token is a KRB_AS_REP message if a ticket was created or a KRB_ERROR message if there was an error while processing the request or the local policy prevented a ticket from being issued. If the acceptor returns GSS_S_CONTINUE_NEEDED in the case of an error,=20 what happens when the initiator after processing the error token decides to stop, will the server just hang there in the continue needed state? Is having a MUST for PKINIT's EKUs too restrictive? Since this is a GSS API mechanism what about QoP handling and channel=20 bindings? Token ids are defined for KRB_AS_REQ and KRB_AS_REP but not for KRB_ERROR? This draft does not support non-Kerberos environments. By that I mean, a Kerberos domain must exist and users of PKU2U must have Kerberos=20 principal names. Name type NT-X500-PRINCIPAL which is rfc2253 string representation of=20 the distinguished name does not produce a canonical name. What happens when the initiator rejects the AS-REP tokens sent by the=20 acceptor (ie., fails to verify acceptor's certificate)? Does it=20 generate an error token? Perhaps last paragraph of Section 6 can have a more detailed explanation that doesn't require the user to go search for a different draft to find our that AP_REQ should carry TYPED_DATA of type TD_IAKERB_FINISHED. I'm sure i'm missing something but why is there a need to tie AS_REQ/REP to=20 AP_REQ/REP no such ties exist in original Kerberos message flow? Naming needs work. Comments made about naming in SPKM3 apply here. Liqiang(Larry) Zhu wrote: > Here is the updated PKU2U. Please review it and see if it has addressed > all concerns. > > Thanks, > > --Larry > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Tuesday, February 27, 2007 3:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-zhu-pku2u-01.txt=20 > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Public Key Cryptography Based User-to-User > Authentication - (PKU2U) > Author(s) : L. Zhu, et al. > Filename : draft-zhu-pku2u-01.txt > Pages : 10 > Date : 2007-2-27 > =09 > This document defines the public key cryptography based user-to-user > authentication protocol - PKU2U. This mechanism provides security > services in peer to peer networking environments without requiring a > trusted third party. Furthermore, the binding of PKU2U for the > Generic Security Service Application Program Interface (GSS-API) per > RFC2743 is defined based on RFC4121. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-zhu-pku2u-01.txt > > To remove yourself from the I-D Announcement list, send a message to=20 > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message.=20 > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the=20 > username "anonymous" and a password of your e-mail address. After=20 > logging in, type "cd internet-drafts" and then=20 > "get draft-zhu-pku2u-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html=20 > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-zhu-pku2u-01.txt". > =09 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > =20 > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > =20 _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Fri Mar 16 23:27:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSPZu-0004Av-5T; Fri, 16 Mar 2007 23:27:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSPZs-0004Ab-PA for spkm@ietf.org; Fri, 16 Mar 2007 23:27:32 -0400 Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSPZm-0004t8-9M for spkm@ietf.org; Fri, 16 Mar 2007 23:27:32 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l2H3RPF4021929 for ; Sat, 17 Mar 2007 03:27:25 GMT Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l2H3ROAm008750 for ; Fri, 16 Mar 2007 21:27:25 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l2H3QjiM022705; Fri, 16 Mar 2007 22:26:45 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l2H3QhmY022704; Fri, 16 Mar 2007 22:26:43 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 16 Mar 2007 22:26:43 -0500 From: Nicolas Williams To: "Liqiang(Larry) Zhu" Message-ID: <20070317032642.GH22445@Sun.COM> Mail-Followup-To: "Liqiang(Larry) Zhu" , Jeffrey Hutzelman , Olga Kornievskaia , Michael.Eisler@netapp.com, andros@citi.umich.edu, kitten@lists.ietf.org, spkm@ietf.org References: <45FB0398.3080406@citi.umich.edu> <729D2796944018A823D6E75A@sirius.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: kitten@lists.ietf.org, andros@citi.umich.edu, Olga Kornievskaia , Michael.Eisler@netapp.com, spkm@ietf.org, Jeffrey Hutzelman 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org On Fri, Mar 16, 2007 at 07:01:09PM -0700, Liqiang(Larry) Zhu wrote: > Jeff wrote: > > This is a good point. GSS_S_CONTINUE_NEEDED indicates that it will be > > > necessary to make the call again with another token provided by the > peer. > > When GSS_Init_sec_context or GSS_Accept_sec_context emits an error > token, > > it should also return an appropriate error status, not > > GSS_S_CONTINUE_NEEDED. > > This is not necessary accurate. In the User2User protocol, > http://www.watersprings.org/pub/id/draft-swift-win2k-krb-user2user-03.tx > t, > the server can return a KRB_ERROR with the GSS_S_CONTINUE_NEEDED status. Where does GSS_S_CONTINUE_NEEDED appear in the KRB-ERROR?? Normally status codes like GSS_S_CONTINUE_NEEDED are not sent in a mechanism token -- they are implied. _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Sat Mar 17 01:37:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSRbi-0002T3-5C; Sat, 17 Mar 2007 01:37:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSRbg-0002Sj-R2 for spkm@ietf.org; Sat, 17 Mar 2007 01:37:32 -0400 Received: from smtp.microsoft.com ([131.107.115.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSRba-0004jX-FN for spkm@ietf.org; Sat, 17 Mar 2007 01:37:32 -0400 Received: from tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Fri, 16 Mar 2007 22:37:25 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) with Microsoft SMTP Server id 8.0.685.25; Fri, 16 Mar 2007 22:37:25 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3953); Fri, 16 Mar 2007 22:37:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Mar 2007 22:37:24 -0700 Message-ID: In-Reply-To: <20070317032642.GH22445@Sun.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-zhu-pku2u-01.txt Thread-Index: AcdoRDFxJciq5hMNTlqAV+V126leHAAEc/rQ References: <45FB0398.3080406@citi.umich.edu> <729D2796944018A823D6E75A@sirius.fac.cs.cmu.edu> <20070317032642.GH22445@Sun.COM> From: "Liqiang(Larry) Zhu" To: Nicolas Williams X-OriginalArrivalTime: 17 Mar 2007 05:37:25.0494 (UTC) FILETIME=[57EC7960:01C76856] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: kitten@lists.ietf.org, andros@citi.umich.edu, Olga Kornievskaia , Michael.Eisler@netapp.com, spkm@ietf.org, Jeffrey Hutzelman 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org Nicolas.Williams wrote: > Where does GSS_S_CONTINUE_NEEDED appear in the KRB-ERROR?? Normally > status codes like GSS_S_CONTINUE_NEEDED are not sent in a mechanism > token -- they are implied. See section 6 of the user2user ID http://www.watersprings.org/pub/id/draft-swift-win2k-krb-user2user-03.tx t =20 6. User to User when applied by server policy=20 =20 In the case that the client application doesn't know that a service=20 requires user-to-user authentication, and requests and receives a=20 conventional KRB_AP_REP, the client will send the KRB_AP_REP=20 request, and the server will respond with a KRB_ERROR token as=20 described in RFC1964, with a msg-type of=20 KRB_AP_ERR_USER_TO_USER_REQUIRED (0x45). The server may optionally=20 pass the TGT in the data field of this error message. In response to=20 this error, the initiator sets flags and returns a=20 GSS_C_CONTINUE_NEEDED so that the next round uses the mechanism=20 described in section 4. -----Original Message----- From: Nicolas Williams [mailto:Nicolas.Williams@sun.com]=20 Sent: Friday, March 16, 2007 8:27 PM To: Liqiang(Larry) Zhu Cc: Jeffrey Hutzelman; Olga Kornievskaia; Michael.Eisler@netapp.com; andros@citi.umich.edu; kitten@lists.ietf.org; spkm@ietf.org Subject: Re: Comments on draft-zhu-pku2u-01.txt On Fri, Mar 16, 2007 at 07:01:09PM -0700, Liqiang(Larry) Zhu wrote: > Jeff wrote: > > This is a good point. GSS_S_CONTINUE_NEEDED indicates that it will be >=20 > > necessary to make the call again with another token provided by the > peer.=20 > > When GSS_Init_sec_context or GSS_Accept_sec_context emits an error > token,=20 > > it should also return an appropriate error status, not=20 > > GSS_S_CONTINUE_NEEDED. >=20 > This is not necessary accurate. In the User2User protocol, > http://www.watersprings.org/pub/id/draft-swift-win2k-krb-user2user-03.tx > t, > the server can return a KRB_ERROR with the GSS_S_CONTINUE_NEEDED status. Where does GSS_S_CONTINUE_NEEDED appear in the KRB-ERROR?? Normally status codes like GSS_S_CONTINUE_NEEDED are not sent in a mechanism token -- they are implied. _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Sat Mar 17 03:05:26 2007 Return-path: 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 (EDT) From: Jeffrey Hutzelman X-X-Sender: To: "Liqiang(Larry) Zhu" In-Reply-To: Message-ID: 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 , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From spkm-bounces@ietf.org Sun Mar 18 08:21:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSuNw-0001h8-DB; Sun, 18 Mar 2007 08:21:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSuNv-0001gy-Fl for spkm@ietf.org; Sun, 18 Mar 2007 08:21:15 -0400 Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSuNr-0001ug-35 for spkm@ietf.org; Sun, 18 Mar 2007 08:21:15 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2ICLA37024575 for ; Sun, 18 Mar 2007 12:21:10 GMT Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l2ICL9pd000207 for ; Sun, 18 Mar 2007 06:21:10 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l2ICKTU6023283; Sun, 18 Mar 2007 07:20:29 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l2ICKRxU023282; Sun, 18 Mar 2007 07:20:27 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Sun, 18 Mar 2007 07:20:27 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Message-ID: <20070318122026.GJ22445@Sun.COM> Mail-Followup-To: Jeffrey Hutzelman , "Liqiang(Larry) Zhu" , Olga Kornievskaia , Michael.Eisler@netapp.com, andros@citi.umich.edu, kitten@lists.ietf.org, spkm@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: kitten@lists.ietf.org, andros@citi.umich.edu, Olga Kornievskaia , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org On Sat, Mar 17, 2007 at 03:04:39AM -0400, Jeffrey Hutzelman wrote: > 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. The quoted text does not call this an error token. _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Sun Mar 18 19:24:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT4jW-0003rM-2y; Sun, 18 Mar 2007 19:24:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT4jT-0003r8-Kq for spkm@ietf.org; Sun, 18 Mar 2007 19:24:11 -0400 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HT4jS-0006XK-Ce for spkm@ietf.org; Sun, 18 Mar 2007 19:24:11 -0400 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa11472; 18 Mar 2007 19:23 EDT Date: Sun, 18 Mar 2007 19:23:50 -0400 (EDT) From: Jeffrey Hutzelman X-X-Sender: To: Nicolas Williams In-Reply-To: <20070318122026.GJ22445@Sun.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: kitten@lists.ietf.org, andros@citi.umich.edu, Olga Kornievskaia , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org On Sun, 18 Mar 2007, Nicolas Williams wrote: > On Sat, Mar 17, 2007 at 03:04:39AM -0400, Jeffrey Hutzelman wrote: > > 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. > > The quoted text does not call this an error token. No, it doesn't, but check the current thread. The current PKU2U document indicates that "In all cases, GSS_Accept_security_context returns GSS_S_CONTINUE_NEEDED... a KRB_ERROR if there was an error...". Olga's reading and mine is that this in some cases requires returning GSS_S_CONTINUE_NEEDED with an output token that is an "error token" as I define it above; that is, one which the initiator is expected to handle by aborting the context establishment (Olga didn't use the phrase "error token", but I did). Larry quoted the text from section 6 of the Kerberos U2U as a counterexample to my argument that when an error token is emitted, it should always come with a real error code, not GSS_S_CONTINUE_NEEDED. But the quoted text is not actually a counterexample, because although the token described containes a KRB-ERROR, it is not an "error token"; it is intended to trigger the U2U mechanism, which will result in another context token. The case described on page 5 of PKU2U-01 describes a token produced when "there was an error while processing the request or the local policy prevented a ticket from being issued." These are situations in which context establishment cannot continue, and the error token is intended to cause GSS_Init_sec_context to return an appropriate failure code. Since no further tokens are expected, the correct result code is something other than GSS_S_CONTINUE_NEEDED. More generally, a mechanism should return GSS_S_CONTINUE_NEEDED in exactly those cases where the peer is expected to send another token, and no others. -- Jeff _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Sun Mar 18 19:43:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT520-000475-JZ; Sun, 18 Mar 2007 19:43:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT51z-00045Z-OV for spkm@ietf.org; Sun, 18 Mar 2007 19:43:19 -0400 Received: from mailc.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HT51w-0000QI-AX for spkm@ietf.org; Sun, 18 Mar 2007 19:43:19 -0400 Received: from tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.685.24; Sun, 18 Mar 2007 16:43:13 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) with Microsoft SMTP Server id 8.0.685.25; Sun, 18 Mar 2007 16:43:13 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3953); Sun, 18 Mar 2007 16:43:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 18 Mar 2007 16:43:06 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-zhu-pku2u-01.txt Thread-Index: AcdptI8U7IB3T71PTW+fKe4ZaC+ALgAAKfqg References: <20070318122026.GJ22445@Sun.COM> From: "Liqiang(Larry) Zhu" To: Jeffrey Hutzelman , Nicolas Williams X-OriginalArrivalTime: 18 Mar 2007 23:43:13.0780 (UTC) FILETIME=[31BDC340:01C769B7] X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: spkm@ietf.org, Michael.Eisler@netapp.com, Olga Kornievskaia , kitten@lists.ietf.org, andros@citi.umich.edu 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org The intention of the text in -01 is that if a KRB-ERROR message should be generated according to rfc4120, then GSS_S_CONTINUE_NEEDED MUST be returned.=20 Based on the discussion here, the draft should acknowledge cases where there is an error that is not a KDC error per RFC4120, say for example the acceptor runs out of memory. =20 Jeffrey Hutzelman wrote: > More generally, a mechanism should return GSS_S_CONTINUE_NEEDED in exactly > those cases where the peer is expected to send another token, and no > others. Would it be preferable to return a GSS_S_CONTINUE_NEEDED and a KRB_ERROR in cases where the client is not expected to send another token, for example in the case of a policy error? The error message contains useful information for trouble-shooting. =09 I would not recommend returning an error token when the returned status is NOT GSS_S_CONTINUE_NEEDED, in that cases, most apps would simply throw that away. --larry -----Original Message----- From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu]=20 Sent: Sunday, March 18, 2007 4:24 PM To: Nicolas Williams Cc: Liqiang(Larry) Zhu; Olga Kornievskaia; Michael.Eisler@netapp.com; andros@citi.umich.edu; kitten@lists.ietf.org; spkm@ietf.org Subject: Re: Comments on draft-zhu-pku2u-01.txt On Sun, 18 Mar 2007, Nicolas Williams wrote: > On Sat, Mar 17, 2007 at 03:04:39AM -0400, Jeffrey Hutzelman wrote: > > 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. > > The quoted text does not call this an error token. No, it doesn't, but check the current thread. The current PKU2U document indicates that "In all cases, GSS_Accept_security_context returns GSS_S_CONTINUE_NEEDED... a KRB_ERROR if there was an error...". Olga's reading and mine is that this in some cases requires reinturning GSS_S_CONTINUE_NEEDED with an output token that is an "error token" as I define it above; that is, one which the initiator is expected to handle by aborting the context establishment (Olga didn't use the phrase "error token", but I did). Larry quoted the text from section 6 of the Kerberos U2U as a counterexample to my argument that when an error token is emitted, it should always come with a real error code, not GSS_S_CONTINUE_NEEDED. But the quoted text is not actually a counterexample, because although the token described containes a KRB-ERROR, it is not an "error token"; it is intended to trigger the U2U mechanism, which will result in another context token. The case described on page 5 of PKU2U-01 describes a token produced when "there was an error while processing the request or the local policy prevented a ticket from being issued." These are situations in which context establishment cannot continue, and the error token is intended to cause GSS_Init_sec_context to return an appropriate failure code. Since no further tokens are expected, the correct result code is something other than GSS_S_CONTINUE_NEEDED. More generally, a mechanism should return GSS_S_CONTINUE_NEEDED in exactly those cases where the peer is expected to send another token, and no others. -- Jeff _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Sun Mar 18 19:44:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT53F-0005Cs-6D; Sun, 18 Mar 2007 19:44:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT53E-0005B8-8r for spkm@ietf.org; Sun, 18 Mar 2007 19:44:36 -0400 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HT53D-0000WI-2b for spkm@ietf.org; Sun, 18 Mar 2007 19:44:36 -0400 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa11486; 18 Mar 2007 19:44 EDT Date: Sun, 18 Mar 2007 19:44:29 -0400 (EDT) From: Jeffrey Hutzelman X-X-Sender: To: "Liqiang(Larry) Zhu" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: kitten@lists.ietf.org, andros@citi.umich.edu, Olga Kornievskaia , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org On Sun, 18 Mar 2007, Liqiang(Larry) Zhu wrote: > The intention of the text in -01 is that if a KRB-ERROR message should > be generated according to rfc4120, then GSS_S_CONTINUE_NEEDED MUST be > returned. Why? How does the initiator handle these tokens? If it does so in any way other than by producing a new token, then the acceptor should not be returning GSS_S_CONTINUE_NEEDED. _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Sun Mar 18 19:50:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT59B-0006eo-L6; Sun, 18 Mar 2007 19:50:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT59A-0006cE-Ob for spkm@ietf.org; Sun, 18 Mar 2007 19:50:44 -0400 Received: from mailc.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HT599-0000ri-Do for spkm@ietf.org; Sun, 18 Mar 2007 19:50:44 -0400 Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.685.24; Sun, 18 Mar 2007 16:50:42 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) with Microsoft SMTP Server id 8.0.685.25; Sun, 18 Mar 2007 16:50:33 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3953); Sun, 18 Mar 2007 16:50:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 18 Mar 2007 16:50:30 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-zhu-pku2u-01.txt Thread-Index: Acdpt2b2vPNGIoTkT72djyquVIaH9wAACNow References: From: "Liqiang(Larry) Zhu" To: Jeffrey Hutzelman X-OriginalArrivalTime: 18 Mar 2007 23:50:34.0205 (UTC) FILETIME=[384148D0:01C769B8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: spkm@ietf.org, andros@citi.umich.edu, kitten@lists.ietf.org, Michael.Eisler@netapp.com 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org Jeffrey Hutzelman wrote: > Why? How does the initiator handle these tokens? If it does so in any > way other than by producing a new token, then the acceptor should not be > returning GSS_S_CONTINUE_NEEDED. The deployment experience shows that if the client (instead of the acceptor or the KDC) can log the error information, the cost of trouble shooting is significantly lower. If the acceptor returns a KRB_ERROR message with a status that is anything but GSS_S_CONTINUE_NEEDED, there is no guarantee and it is in fact very unlikely that the trouble-shooting information can make it to the client side in order to get logged. --larry -----Original Message----- From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu]=20 Sent: Sunday, March 18, 2007 4:44 PM To: Liqiang(Larry) Zhu Cc: kitten@lists.ietf.org; Nicolas Williams; andros@citi.umich.edu; Michael.Eisler@netapp.com; spkm@ietf.org Subject: RE: Comments on draft-zhu-pku2u-01.txt On Sun, 18 Mar 2007, Liqiang(Larry) Zhu wrote: > The intention of the text in -01 is that if a KRB-ERROR message should > be generated according to rfc4120, then GSS_S_CONTINUE_NEEDED MUST be > returned. Why? How does the initiator handle these tokens? If it does so in any way other than by producing a new token, then the acceptor should not be returning GSS_S_CONTINUE_NEEDED. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Sun Mar 18 19:59:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT5HM-0004wx-AU; Sun, 18 Mar 2007 19:59:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT5HL-0004ui-Kq for spkm@ietf.org; Sun, 18 Mar 2007 19:59:11 -0400 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HT5HK-0001mw-EO for spkm@ietf.org; Sun, 18 Mar 2007 19:59:11 -0400 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa11507; 18 Mar 2007 19:58 EDT Date: Sun, 18 Mar 2007 19:58:50 -0400 (EDT) From: Jeffrey Hutzelman X-X-Sender: To: "Liqiang(Larry) Zhu" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: spkm@ietf.org, andros@citi.umich.edu, kitten@lists.ietf.org, Michael.Eisler@netapp.com 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org On Sun, 18 Mar 2007, Liqiang(Larry) Zhu wrote: > Jeffrey Hutzelman wrote: > > Why? How does the initiator handle these tokens? If it does so in > any > > way other than by producing a new token, then the acceptor should not > be > > returning GSS_S_CONTINUE_NEEDED. > > The deployment experience shows that if the client (instead of the > acceptor or the KDC) can log the error information, the cost of trouble > shooting is significantly lower. > > If the acceptor returns a KRB_ERROR message with a status that is > anything but GSS_S_CONTINUE_NEEDED, there is no guarantee and it is in > fact very unlikely that the trouble-shooting information can make it to > the client side in order to get logged. No; you are confused. GSS_S_CONTINUE_NEEDED does not mean "there is a token to send to the peer". It means "another token is expected from the peer". Any token produced by GSS_Accept_sec_context should be sent to the peer regardless of the returned status code. Behaving otherwise violates the abstraction and will break application protocols which expect the GSS-API to behave as specified, regardless of which mechanism is being used. _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Mon Mar 19 11:26:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTJkb-0002sh-NT; Mon, 19 Mar 2007 11:26:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTJka-0002sY-4K; Mon, 19 Mar 2007 11:26:20 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTJkM-0003lO-Lj; Mon, 19 Mar 2007 11:26:20 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id RAA12622; Mon, 19 Mar 2007 17:25:34 +0200 (MESZ) From: Martin Rex Message-Id: <200703191525.QAA04217@uw1048.wdf.sap.corp> To: lzhu@windows.microsoft.com (Liqiang) Date: Mon, 19 Mar 2007 16:25:34 +0100 (MET) In-Reply-To: from "Liqiang" at Mar 16, 7 07:01:09 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-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: kitten@lists.ietf.org, andros@citi.umich.edu, aglo@citi.umich.edu, Michael.Eisler@netapp.com, spkm@ietf.org, jhutz@cmu.edu Subject: [SPKM] Re: Comments on draft-zhu-pku2u-01.txt 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org Liqiang wrote: > > Jeff wrote: > > This is a good point. GSS_S_CONTINUE_NEEDED indicates that it will be > > necessary to make the call again with another token provided by the peer. > > When GSS_Init_sec_context or GSS_Accept_sec_context emits an error token, > > it should also return an appropriate error status, not > > GSS_S_CONTINUE_NEEDED. > > This is not necessary accurate. In the User2User protocol, > http://www.watersprings.org/pub/id/draft-swift-win2k-krb-user2user-03.txt, > the server can return a KRB_ERROR with the GSS_S_CONTINUE_NEEDED status. Returning a KRB_ERROR token along with GSS_S_CONTINUE_NEEDED minor_status from gss_accept_sec_context() is defintely *NOT* allowed by rfc-1964. There seems to be text describing a backward incompatible change in rfc-4121 last paragraph of section 4.1, (top of page 5) which allows such misbehaviour for the specific case of an unknown token ID: If an unknown token identifier (TOK_ID) is received in the initial context establishment token, the receiver MUST return GSS_S_CONTINUE_NEEDED major status, and the returned output token MUST contain a KRB_ERROR message with the error code KRB_AP_ERR_MSG_TYPE [RFC4120]. But since the spec is entirely silent about how the client can continue to produce a successful security context establishment from that point on, it is sufficiently incomplete to be unusuable. SSPI has been returning KRB_ERROR tokens along with CONTINUE_NEEDED status from the beginning, in an undocumented/unspecified fashion, non-interoperable with rfc-1964 based Kerberos implementations. -Martin _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Mon Mar 19 11:41:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTJzQ-0005A7-A8; Mon, 19 Mar 2007 11:41:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTJzP-00059y-77; Mon, 19 Mar 2007 11:41:39 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTJz4-0006H4-Tt; Mon, 19 Mar 2007 11:41:39 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id RAA16274; Mon, 19 Mar 2007 17:38:31 +0200 (MESZ) From: Martin Rex Message-Id: <200703191538.QAA04559@uw1048.wdf.sap.corp> To: lzhu@windows.microsoft.com (Liqiang) Date: Mon, 19 Mar 2007 16:38:04 +0100 (MET) In-Reply-To: from "Liqiang" at Mar 16, 7 07:01:09 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-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: kitten@lists.ietf.org, andros@citi.umich.edu, aglo@citi.umich.edu, Michael.Eisler@netapp.com, spkm@ietf.org, jhutz@cmu.edu Subject: [SPKM] Re: Comments on draft-zhu-pku2u-01.txt 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org Liqiang wrote: > > This is not necessary accurate. In the User2User protocol, > http://www.watersprings.org/pub/id/draft-swift-win2k-krb-user2user-03.txt, > the server can return a KRB_ERROR with the GSS_S_CONTINUE_NEEDED status. IIRC, the user2user implementation shipped by Microsoft uses a mechanism OID different from rfc-1964/rfc-4121. Technically, the "context establishment handshake" is opaque to the application. It is conceivable to define a context establishment handshake that negotiates (optional) features in multiple steps, and the names of intermediate tokens are just an implementation detail. However, the spec of a mechanism ought to be sufficiently clear that everyone can implement optional multi-step negotiations reliably in an interoperable fashion. Retrofitting KRB_ERROR + CONTINUE_NEEDED for rfc-1964 and successors should NOT break implementations based on the original specs, which likely do not support this. -Martin _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Mon Mar 19 12:13:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTKUO-0006ND-Rd; Mon, 19 Mar 2007 12:13:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTKUO-0006N3-Fc for spkm@ietf.org; Mon, 19 Mar 2007 12:13:40 -0400 Received: from dhcp-1226.ietf68.org ([130.129.18.38] helo=carter-zimmerman.mit.edu) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTKUN-0002Fy-2q for spkm@ietf.org; Mon, 19 Mar 2007 12:13:40 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id EF41BE031C; Mon, 19 Mar 2007 12:13:22 -0400 (EDT) From: Sam Hartman To: Jeffrey Hutzelman Subject: Re: [SPKM] RE: Comments on draft-zhu-pku2u-01.txt References: Date: Mon, 19 Mar 2007 12:13:22 -0400 In-Reply-To: (Jeffrey Hutzelman's message of "Sun, 18 Mar 2007 19:58:50 -0400 (EDT)") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Michael.Eisler@netapp.com, kitten@lists.ietf.org, spkm@ietf.org, andros@citi.umich.edu X-BeenThere: spkm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org >>>>> "Jeffrey" == Jeffrey Hutzelman writes: Jeffrey> On Sun, 18 Mar 2007, Liqiang(Larry) Zhu wrote: >> Jeffrey Hutzelman wrote: > Why? How does the initiator handle >> these tokens? If it does so in any > way other than by >> producing a new token, then the acceptor should not be > >> returning GSS_S_CONTINUE_NEEDED. >> >> The deployment experience shows that if the client (instead of >> the acceptor or the KDC) can log the error information, the >> cost of trouble shooting is significantly lower. >> >> If the acceptor returns a KRB_ERROR message with a status that >> is anything but GSS_S_CONTINUE_NEEDED, there is no guarantee >> and it is in fact very unlikely that the trouble-shooting >> information can make it to the client side in order to get >> logged. Jeffrey> No; you are confused. GSS_S_CONTINUE_NEEDED does not Jeffrey> mean "there is a token to send to the peer". It means Jeffrey> "another token is expected from the peer". Any token Jeffrey> produced by GSS_Accept_sec_context should be sent to the Jeffrey> peer regardless of the returned status code. Jeffrey> Behaving otherwise violates the abstraction and will Jeffrey> break application protocols which expect the GSS-API to Jeffrey> behave as specified, regardless of which mechanism is Jeffrey> being used. I strongly agree with Jeff here. _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Mon Mar 19 12:24:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTKeR-0000Vf-6U; Mon, 19 Mar 2007 12:24:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTKeP-0000VO-V9; Mon, 19 Mar 2007 12:24:01 -0400 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTKeJ-0004Vy-Gq; Mon, 19 Mar 2007 12:24:01 -0400 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id SAA12805; Mon, 19 Mar 2007 18:23:43 +0200 (MESZ) From: Martin Rex Message-Id: <200703191623.RAA05635@uw1048.wdf.sap.corp> To: lzhu@windows.microsoft.com (Liqiang) Date: Mon, 19 Mar 2007 17:23:26 +0100 (MET) In-Reply-To: from "Liqiang" at Mar 16, 7 10:37:24 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-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: kitten@lists.ietf.org, andros@citi.umich.edu, Michael.Eisler@netapp.com, spkm@ietf.org, jhutz@cmu.edu Subject: [SPKM] Re: Comments on draft-zhu-pku2u-01.txt 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org Liqiang wrote: > > Nicolas.Williams wrote: > > Where does GSS_S_CONTINUE_NEEDED appear in the KRB-ERROR?? Normally > > status codes like GSS_S_CONTINUE_NEEDED are not sent in a mechanism > > token -- they are implied. > > See section 6 of the user2user ID > http://www.watersprings.org/pub/id/draft-swift-win2k-krb-user2user-03.txt > > > 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 Is it me or should this read KRB_AP_REQ? > 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. This "server policy" confuses me. There are potentially 3 issues with AP_REQ/AP_REP exchanges that I can think of: 1) "weak" server key (i.e. server does not have a strong random key) 2) server lacks (or doesn't want to use) replay cache 3) replay caches are not shared across hosts, so a distributed services using a single principal (a single key) instead of the original hostbased services of the original Kerberos 5 design become vulnerable to cross-host replay Protection for (1) would require the KDC to not even issue service tickets, so that the client can not even send a KRB_AP_REQ. Having a Application send a KRB_ERROR upon receiving an rfc-1964 AP_REQ will result in fatal termination of the security context establishment for every conforming implementation of rfc-1964. So this suggestion seems to create an interoperability problem, and the CONTINUE_NEEDED status is an inappropriate return status for gss_accept_sec_context() for a mechanism using the rfc-1964 mechanism OID. -Martin _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Mon Mar 19 12:29:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTKjh-0002gi-Go; Mon, 19 Mar 2007 12:29:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTKjg-0002gN-C3; Mon, 19 Mar 2007 12:29:28 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTKje-0005el-Tg; Mon, 19 Mar 2007 12:29:28 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id SAA00156; Mon, 19 Mar 2007 18:29:18 +0200 (MESZ) From: Martin Rex Message-Id: <200703191629.RAA05702@uw1048.wdf.sap.corp> To: jhutz@cmu.edu (Jeffrey Hutzelman) Date: Mon, 19 Mar 2007 17:29:08 +0100 (MET) In-Reply-To: from "Jeffrey Hutzelman" at Mar 18, 7 07:58:50 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-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: kitten@lists.ietf.org, andros@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 Reply-To: martin.rex@sap.com List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org Jeffrey Hutzelman wrote: > > On Sun, 18 Mar 2007, Liqiang(Larry) Zhu wrote: > > Jeffrey Hutzelman wrote: > > > Why? How does the initiator handle these tokens? If it does so in any > > > way other than by producing a new token, then the acceptor should not be > > > returning GSS_S_CONTINUE_NEEDED. > > > > The deployment experience shows that if the client (instead of the > > acceptor or the KDC) can log the error information, the cost of trouble > > shooting is significantly lower. > > > > If the acceptor returns a KRB_ERROR message with a status that is > > anything but GSS_S_CONTINUE_NEEDED, there is no guarantee and it is in > > fact very unlikely that the trouble-shooting information can make it to > > the client side in order to get logged. > > No; you are confused. GSS_S_CONTINUE_NEEDED does not mean "there is a > token to send to the peer". It means "another token is expected from the > peer". Any token produced by GSS_Accept_sec_context should be sent to the > peer regardless of the returned status code. Actually, that is not completely accurate. An application that obtains a context token along with a fatal routine error from one of the context establishment calls (gss_accept_sec_context or gss_init_sec_context) is *NOT* required to send this to the peer. It may do so, but it may also shutdown the communication channel. I expect that a lot of applications will not actually send such a token (ours doesn't). > > Behaving otherwise violates the abstraction and will break application > protocols which expect the GSS-API to behave as specified, regardless of > which mechanism is being used. Returning CONTINUE_NEEDED status when the mechanism spec does *NOT* define a clear method how to continue the context establishment handshake to successful completion is broken on my scorecard. -Martin _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Mon Mar 19 13:11:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTLOb-0002Hk-2p; Mon, 19 Mar 2007 13:11:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTLOZ-0002Gh-1o; Mon, 19 Mar 2007 13:11:43 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTLO6-0004hP-4U; Mon, 19 Mar 2007 13:11:43 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id TAA09477; Mon, 19 Mar 2007 19:11:05 +0200 (MESZ) From: Martin Rex Message-Id: <200703191710.SAA06804@uw1048.wdf.sap.corp> To: jhutz@cmu.edu (Jeffrey Hutzelman) Date: Mon, 19 Mar 2007 18:10:54 +0100 (MET) In-Reply-To: from "Jeffrey Hutzelman" at Mar 18, 7 07:23:50 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: de4f315c9369b71d7dd5909b42224370 Cc: kitten@lists.ietf.org, andros@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 Reply-To: martin.rex@sap.com List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org Jeffrey Hutzelman wrote: > > More generally, a mechanism should return GSS_S_CONTINUE_NEEDED in exactly > those cases where the peer is expected to send another token, and no > others. I fully agree. Engineering-wise it is a pretty bad idea to cause (server) applications to keep unnecessary state around (a proto security context that will never get established) and remain tied up in the security context establishment loop of the GSS-API security context establishment exchange unless there is a real possibility that the handshake on this security context will be continued and lead to a successful completion. -Martin _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Mon Mar 19 13:32:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTLix-0005RH-Si; Mon, 19 Mar 2007 13:32:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTLix-0005Qo-0M; Mon, 19 Mar 2007 13:32:47 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTLiS-0000B1-9f; Mon, 19 Mar 2007 13:32:46 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id TAA16256; Mon, 19 Mar 2007 19:31:57 +0200 (MESZ) From: Martin Rex Message-Id: <200703191731.SAA07246@uw1048.wdf.sap.corp> Subject: Re: [SPKM] RE: Comments on draft-zhu-pku2u-01.txt To: lzhu@windows.microsoft.com (Liqiang) Date: Mon, 19 Mar 2007 18:31:51 +0100 (MET) In-Reply-To: from "Liqiang" at Mar 18, 7 04:50:30 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-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: andros@citi.umich.edu, Michael.Eisler@netapp.com, kitten@lists.ietf.org, spkm@ietf.org, jhutz@cmu.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org Liqiang wrote: > > Jeffrey Hutzelman wrote: > > Why? How does the initiator handle these tokens? If it does so in any > > way other than by producing a new token, then the acceptor should not be > > returning GSS_S_CONTINUE_NEEDED. > > The deployment experience shows that if the client (instead of the > acceptor or the KDC) can log the error information, the cost of trouble > shooting is significantly lower. I do not agree. (OT: You might want to convince the MSIE/schannel maintainers, currently you need a debugger to figure our the SSL alert received by MSIE, MSIE itself presents just a useless "it may everything including sunspots" error messages, and its been doing this for 10 years). > > If the acceptor returns a KRB_ERROR message with a status that is > anything but GSS_S_CONTINUE_NEEDED, there is no guarantee and it is in > fact very unlikely that the trouble-shooting information can make it to > the client side in order to get logged. IMHO, that is more of an application problem than a Kerberos problem. With your approach, the error and all details will completely hidden from the Server and Server admins. I consider it a real problem when the error is NOT locally reported where it occurs. Whether and how much a client can do for trouble-shooting may be application specific! When helpdesk is called, the only information that is reliably available/accessible is that logged centrally on backends/servers. E.g. when my application notices a "wrong target name in request" type of error, it aborts the security context establishment and returns an error message at the "application level" conveying this error along with the name that the server uses for acquiring his own credentials. (since some gssapi mechanisms are poor at determining this error, my application framing protocol sends the target name along with the initial context establishment token and when gss_accept_sec_context() fails with an error it compares the accompanying target name with its own server name in order to decide whether it sends a "wrong target name" application level error message back to the client. -Martin > -----Original Message----- > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] > Sent: Sunday, March 18, 2007 4:44 PM > To: Liqiang(Larry) Zhu > Cc: kitten@lists.ietf.org; Nicolas Williams; andros@citi.umich.edu; > Michael.Eisler@netapp.com; spkm@ietf.org > Subject: RE: Comments on draft-zhu-pku2u-01.txt > > On Sun, 18 Mar 2007, Liqiang(Larry) Zhu wrote: > > > The intention of the text in -01 is that if a KRB-ERROR message should > > be generated according to rfc4120, then GSS_S_CONTINUE_NEEDED MUST be > > returned. > > > Why? How does the initiator handle these tokens? If it does so in any > way other than by producing a new token, then the acceptor should not be > returning GSS_S_CONTINUE_NEEDED. > > > > _______________________________________________ > Kitten mailing list > Kitten@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/kitten > > _______________________________________________ > 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 From spkm-bounces@ietf.org Mon Mar 19 14:22:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTMVQ-0004qq-Lo; Mon, 19 Mar 2007 14:22:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTMVP-0004pK-QZ for spkm@ietf.org; Mon, 19 Mar 2007 14:22:51 -0400 Received: from citi.umich.edu ([141.211.133.111]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTMUv-0007sQ-OX for spkm@ietf.org; Mon, 19 Mar 2007 14:22:51 -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 DD8DF396AE; Mon, 19 Mar 2007 14:22:20 -0400 (EDT) Message-ID: <45FED4DC.103@citi.umich.edu> Date: Mon, 19 Mar 2007 14:22:20 -0400 From: Olga Kornievskaia User-Agent: Thunderbird 1.5.0.10 (X11/20070301) MIME-Version: 1.0 To: "Liqiang(Larry) Zhu" References: <45FB0398.3080406@citi.umich.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: Michael.Eisler@netapp.com, andros@citi.umich.edu, kitten@lists.ietf.org, 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org Liqiang(Larry) Zhu wrote: > This is designed for fast session resumption. When the initiator already > obtained a service ticket in prior sessions, it can just use that cached > ticket right away. > Ok. However, I think that it makes more sense to explain the initial step first (ie., when no security context has been established between the parties), then explain the case of reusing previously acquired credentials. >> Isn't there a missing reference to the Section 3.2.3 of RFC4556. Unlike KDC and principal, acceptor and initiator don't share any secrets. PKINIT's PA_PK_AS_REP is needed here for the initiator to make use of the ticket created by the acceptor. > RFC4556 updates RFC4120, unless there is something here specific to > RFC4556, I do not see the need here. > The doc states that: The initiator always includes the PA_PK_AS_REQ pre-authentication data computed according to Section 3.2.1 of [RFC4556]. I might be wrong but I believe that the reply message contains PA_PK_AS_REP pre-auth data as pre Section 3.2.2 of rfc4556. If not, ignore my comment. Otherwise, I think clarifying that the reply is not simply AS_REP is important. >> This draft does not support non-Kerberos environments. By that I mean, a Kerberos domain must exist and users of PKU2U must have Kerberos principal names. >> > How was this deduced? What is a Kerberos domain? And it should not be > needed. what environments are not supported? Can you expand on this? Naming of PKU2U participants is defined in terms on Kerberos name forms. Like SPKM3, PKU2U does not assume that the initiator knows the acceptor's certificate (at least there is nothing in the spec that says otherwise). Thus, the initiator needs to create/invent a name for the acceptor and include it in the AS_REQ. The document assume that the name would be in a Kerberos form. At this point, the likelihood that the initiator can create a correct KRB_NT_500_PRINCIPAL name that would eventually be matched to the DN in the acceptor's certificate is low. Thus, the other option is to create a typical Kerberos name "principal_name/instance@realm". The set of "principal_name/instance" names in a given "realm" constitutes a Kerberos domain. Such names must have been established and existed prior the initiator and acceptor's communication. Now that I think about it, I have a question as to how would identification verification work when the certificate say don't have a SAN with principal_name in them? How would you match the "name/instance@realm" name to a DN? >> Name type NT-X500-PRINCIPAL which is rfc2253 string representation of >> the distinguished name does not produce a canonical name. > PKU2U requires little endian order: > > The Distinguished Name contained in the > PKU2U Kerberos principal name MUST begin with the most specific > attribute and continue with progressively broader attrbiutes. > > With this constraint, is there a case where this does not produce a > canonical name? > One example is multi-valued RDNs. I might be wrong but wasn't there a problem (in practice) of having different "string" names for RDN OIDs (or different implementations not knowing a mapping from an oid to a string name of an RDN, thus leading to different string representations). >> Naming needs work. Comments made about naming in SPKM3 apply here. > Can you point me to the comments, it would help. I just realized that the discussion I was referring to occurred prior to the creation of the spkm mailing list. Thus, it was a private discussion that included comments from Nico Williams and Martin Rex. _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Mon Mar 19 16:10:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTOBT-0004HP-5e; Mon, 19 Mar 2007 16:10:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTOBR-0004H9-Og for spkm@ietf.org; Mon, 19 Mar 2007 16:10:21 -0400 Received: from citi.umich.edu ([141.211.133.111]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTOAw-0000g0-R7 for spkm@ietf.org; Mon, 19 Mar 2007 16:10:21 -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 5C44239707; Mon, 19 Mar 2007 16:09:50 -0400 (EDT) Message-ID: <45FEEE0D.1010602@citi.umich.edu> Date: Mon, 19 Mar 2007 16:09:49 -0400 From: Olga Kornievskaia User-Agent: Thunderbird 1.5.0.10 (X11/20070301) MIME-Version: 1.0 To: martin.rex@sap.com Subject: Re: [SPKM] Re: Comments on draft-zhu-pku2u-01.txt References: <200703191629.RAA05702@uw1048.wdf.sap.corp> In-Reply-To: <200703191629.RAA05702@uw1048.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: spkm@ietf.org, andros@citi.umich.edu, kitten@lists.ietf.org, Michael.Eisler@netapp.com, Jeffrey Hutzelman X-BeenThere: spkm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org Martin Rex wrote: > Jeffrey Hutzelman wrote: > >> On Sun, 18 Mar 2007, Liqiang(Larry) Zhu wrote: >> >>> Jeffrey Hutzelman wrote: >>> >>>> Why? How does the initiator handle these tokens? If it does so in any >>>> way other than by producing a new token, then the acceptor should not be >>>> returning GSS_S_CONTINUE_NEEDED. >>>> >>> The deployment experience shows that if the client (instead of the >>> acceptor or the KDC) can log the error information, the cost of trouble >>> shooting is significantly lower. >>> >>> If the acceptor returns a KRB_ERROR message with a status that is >>> anything but GSS_S_CONTINUE_NEEDED, there is no guarantee and it is in >>> fact very unlikely that the trouble-shooting information can make it to >>> the client side in order to get logged. >>> >> No; you are confused. GSS_S_CONTINUE_NEEDED does not mean "there is a >> token to send to the peer". It means "another token is expected from the >> peer". Any token produced by GSS_Accept_sec_context should be sent to the >> peer regardless of the returned status code. >> > > Actually, that is not completely accurate. > > An application that obtains a context token along with a fatal routine > error from one of the context establishment calls (gss_accept_sec_context > or gss_init_sec_context) is *NOT* required to send this to the peer. > It may do so, but it may also shutdown the communication channel. > I expect that a lot of applications will not actually send such a token > (ours doesn't). > I agree with Jeff that GSS_S_CONTINUE implies another token is coming. I also agree with Martin and disagree with Jeff on the issue of handling an output token when gss_accept_sec_context() fails. What I would like to highlight is the fact that the current draft requires serious clarifications when it comes to handling error cases! GSS API guarantees that an output will be sent if the GSS_S_CONTINUE is returned. Thus if you want to convey error details (KRB-ERROR) to your peer, then you should return GSS_S_CONTINUE. However this brings me back to my original point that the server is left hanging (ie, keeping state). As others pointed out, using up resources on the server is not desirable. As I was looking at error tokens in GSS API in general (and also related to SPKM3), I was scratching my head trying to figure out how can one make use of error tokens as in any GSS mechanism they seem to present the problem we are discussing right now. I came to the conclusion that error tokens can't be used and we just have to do with error status codes. Therefore, I think this spec should be changed to say that on failure an error code should be returned instead of the GSS_S_CONTINUE. I'm not sure whether or not saying the following is beneficial: that KRB-ERROR token could be returned as well but it is up to the GSS application to decide whether such output token is sent to the peer. >> Behaving otherwise violates the abstraction and will break application >> protocols which expect the GSS-API to behave as specified, regardless of >> which mechanism is being used. >> > Returning CONTINUE_NEEDED status when the mechanism spec does *NOT* > define a clear method how to continue the context establishment > handshake to successful completion is broken on my scorecard. > Agreed! _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Mon Mar 19 16:45:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTOjT-0007dL-J4; Mon, 19 Mar 2007 16:45:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTOjS-0007Wu-Ba for spkm@ietf.org; Mon, 19 Mar 2007 16:45:30 -0400 Received: from citi.umich.edu ([141.211.133.111]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTOjR-00052S-02 for spkm@ietf.org; Mon, 19 Mar 2007 16:45:30 -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 694A33958F; Mon, 19 Mar 2007 16:45:28 -0400 (EDT) Message-ID: <45FEF668.3060209@citi.umich.edu> Date: Mon, 19 Mar 2007 16:45:28 -0400 From: Olga Kornievskaia User-Agent: Thunderbird 1.5.0.10 (X11/20070301) MIME-Version: 1.0 To: "Liqiang(Larry) Zhu" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: Michael.Eisler@netapp.com, andros@citi.umich.edu, kitten@lists.ietf.org, spkm@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org If we had GSS TSL (or SPKM3), a security context can be established between an anonymous client and a server with a certificate. If that possible with PKU2U? Liqiang(Larry) Zhu wrote: > Here is the updated PKU2U. Please review it and see if it has addressed > all concerns. > > Thanks, > > --Larry > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Tuesday, February 27, 2007 3:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-zhu-pku2u-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Public Key Cryptography Based User-to-User > Authentication - (PKU2U) > Author(s) : L. Zhu, et al. > Filename : draft-zhu-pku2u-01.txt > Pages : 10 > Date : 2007-2-27 > > This document defines the public key cryptography based user-to-user > authentication protocol - PKU2U. This mechanism provides security > services in peer to peer networking environments without requiring a > trusted third party. Furthermore, the binding of PKU2U for the > Generic Security Service Application Program Interface (GSS-API) per > RFC2743 is defined based on RFC4121. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-zhu-pku2u-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-zhu-pku2u-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-zhu-pku2u-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Mon Mar 19 17:11:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTP8h-00062o-3a; Mon, 19 Mar 2007 17:11:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTP8f-00061U-F0 for spkm@ietf.org; Mon, 19 Mar 2007 17:11:33 -0400 Received: from smtp.microsoft.com ([131.107.115.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTP8W-0000i6-2M for spkm@ietf.org; Mon, 19 Mar 2007 17:11:33 -0400 Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Mon, 19 Mar 2007 14:11:23 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) with Microsoft SMTP Server id 8.0.685.25; Mon, 19 Mar 2007 14:11:23 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3953); Mon, 19 Mar 2007 14:11:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Mar 2007 14:10:59 -0700 Message-ID: In-Reply-To: <45FEF668.3060209@citi.umich.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: I-D ACTION:draft-zhu-pku2u-01.txt Thread-Index: AcdqZ5V+lzLZWAgATOqcRQcwAgdEAAAA1gOw References: <45FEF668.3060209@citi.umich.edu> From: "Liqiang(Larry) Zhu" To: Olga Kornievskaia X-OriginalArrivalTime: 19 Mar 2007 21:11:22.0964 (UTC) FILETIME=[25AF5140:01C76A6B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: Michael.Eisler@netapp.com, kitten@lists.ietf.org, spkm@ietf.org, andros@citi.umich.edu 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org Yes, this is a supported mode, the client/initiator is anonymous and the acceptor has a certificate. -----Original Message----- From: Olga Kornievskaia [mailto:aglo@citi.umich.edu]=20 Sent: Monday, March 19, 2007 1:45 PM To: Liqiang(Larry) Zhu Cc: Michael.Eisler@netapp.com; andros@citi.umich.edu; kitten@lists.ietf.org; spkm@ietf.org; Nicolas Williams Subject: Re: FW: I-D ACTION:draft-zhu-pku2u-01.txt If we had GSS TSL (or SPKM3), a security context can be established=20 between an anonymous client and a server with a certificate. If that=20 possible with PKU2U? Liqiang(Larry) Zhu wrote: > Here is the updated PKU2U. Please review it and see if it has addressed > all concerns. > > Thanks, > > --Larry > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Tuesday, February 27, 2007 3:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-zhu-pku2u-01.txt=20 > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Public Key Cryptography Based User-to-User > Authentication - (PKU2U) > Author(s) : L. Zhu, et al. > Filename : draft-zhu-pku2u-01.txt > Pages : 10 > Date : 2007-2-27 > =09 > This document defines the public key cryptography based user-to-user > authentication protocol - PKU2U. This mechanism provides security > services in peer to peer networking environments without requiring a > trusted third party. Furthermore, the binding of PKU2U for the > Generic Security Service Application Program Interface (GSS-API) per > RFC2743 is defined based on RFC4121. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-zhu-pku2u-01.txt > > To remove yourself from the I-D Announcement list, send a message to=20 > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message.=20 > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the=20 > username "anonymous" and a password of your e-mail address. After=20 > logging in, type "cd internet-drafts" and then=20 > "get draft-zhu-pku2u-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html=20 > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-zhu-pku2u-01.txt". > =09 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > =20 > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > =20 _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Mon Mar 19 18:15:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTQ8U-0002pt-Oe; Mon, 19 Mar 2007 18:15:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTQ8T-0002pe-G6 for spkm@ietf.org; Mon, 19 Mar 2007 18:15:25 -0400 Received: from citi.umich.edu ([141.211.133.111]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTQ8S-000265-2z for spkm@ietf.org; Mon, 19 Mar 2007 18:15:25 -0400 Received: from [141.211.133.26] (yoga.citi.umich.edu [141.211.133.26]) (using TLSv1 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 76E8C39574; Mon, 19 Mar 2007 18:15:23 -0400 (EDT) Message-ID: <45FF0B7B.6010703@citi.umich.edu> Date: Mon, 19 Mar 2007 18:15:23 -0400 From: Olga Kornievskaia User-Agent: Thunderbird 1.5.0.10 (X11/20070301) MIME-Version: 1.0 To: "Liqiang(Larry) Zhu" References: <45FEF668.3060209@citi.umich.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: Michael.Eisler@netapp.com, kitten@lists.ietf.org, spkm@ietf.org, andros@citi.umich.edu 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org Do you plan to extend the current document and include the details of this case? Liqiang(Larry) Zhu wrote: > Yes, this is a supported mode, the client/initiator is anonymous and the > acceptor has a certificate. > > -----Original Message----- > From: Olga Kornievskaia [mailto:aglo@citi.umich.edu] > Sent: Monday, March 19, 2007 1:45 PM > To: Liqiang(Larry) Zhu > Cc: Michael.Eisler@netapp.com; andros@citi.umich.edu; > kitten@lists.ietf.org; spkm@ietf.org; Nicolas Williams > Subject: Re: FW: I-D ACTION:draft-zhu-pku2u-01.txt > > > If we had GSS TSL (or SPKM3), a security context can be established > between an anonymous client and a server with a certificate. If that > possible with PKU2U? > > Liqiang(Larry) Zhu wrote: > >> Here is the updated PKU2U. Please review it and see if it has >> > addressed > >> all concerns. >> >> Thanks, >> >> --Larry >> >> -----Original Message----- >> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >> Sent: Tuesday, February 27, 2007 3:50 PM >> To: i-d-announce@ietf.org >> Subject: I-D ACTION:draft-zhu-pku2u-01.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Public Key Cryptography Based User-to-User >> Authentication - (PKU2U) >> Author(s) : L. Zhu, et al. >> Filename : draft-zhu-pku2u-01.txt >> Pages : 10 >> Date : 2007-2-27 >> >> This document defines the public key cryptography based user-to-user >> authentication protocol - PKU2U. This mechanism provides security >> services in peer to peer networking environments without requiring >> > a > >> trusted third party. Furthermore, the binding of PKU2U for the >> Generic Security Service Application Program Interface (GSS-API) >> > per > >> RFC2743 is defined based on RFC4121. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-zhu-pku2u-01.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in the body of >> > > >> the message. >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >> > > >> to change your subscription settings. >> >> Internet-Drafts are also available by anonymous FTP. Login with the >> username "anonymous" and a password of your e-mail address. After >> logging in, type "cd internet-drafts" and then >> "get draft-zhu-pku2u-01.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-zhu-pku2u-01.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail >> readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> >> > ------------------------------------------------------------------------ > >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www1.ietf.org/mailman/listinfo/i-d-announce >> >> > > _______________________________________________ > Kitten mailing list > Kitten@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/kitten > > _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Tue Mar 20 09:33:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTeSw-0002RI-TN; Tue, 20 Mar 2007 09:33:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTeSv-0002Ml-4Y for spkm@ietf.org; Tue, 20 Mar 2007 09:33:29 -0400 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HTeSc-0001nE-J7 for spkm@ietf.org; Tue, 20 Mar 2007 09:33:29 -0400 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa16160; 20 Mar 2007 7:32 EDT Date: Tue, 20 Mar 2007 07:32:39 -0400 (EDT) From: Jeffrey Hutzelman X-X-Sender: To: Martin Rex In-Reply-To: <200703191629.RAA05702@uw1048.wdf.sap.corp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: kitten@lists.ietf.org, andros@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org On Mon, 19 Mar 2007, Martin Rex wrote: > An application that obtains a context token along with a fatal routine > error from one of the context establishment calls (gss_accept_sec_context > or gss_init_sec_context) is *NOT* required to send this to the peer. > It may do so, but it may also shutdown the communication channel. > I expect that a lot of applications will not actually send such a token > (ours doesn't). Well, that depends on the specification of the application - some application protocols are as you describe, and some dictate one choice or the other. But the key point here is that CONTINUE_NEEDED means that a token is expected from the peer, and should not be returned otherwise. > Returning CONTINUE_NEEDED status when the mechanism spec does *NOT* > define a clear method how to continue the context establishment > handshake to successful completion is broken on my scorecard. Agree. _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Tue Mar 20 09:33:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTeTH-00030N-DC; Tue, 20 Mar 2007 09:33:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTeTG-0002yB-Nm for spkm@ietf.org; Tue, 20 Mar 2007 09:33:50 -0400 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HTeSv-0001nE-5t for spkm@ietf.org; Tue, 20 Mar 2007 09:33:50 -0400 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa16164; 20 Mar 2007 7:37 EDT Date: Tue, 20 Mar 2007 07:37:57 -0400 (EDT) From: Jeffrey Hutzelman X-X-Sender: To: Martin Rex Subject: Re: [SPKM] RE: Comments on draft-zhu-pku2u-01.txt In-Reply-To: <200703191731.SAA07246@uw1048.wdf.sap.corp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Michael.Eisler@netapp.com, kitten@lists.ietf.org, spkm@ietf.org, andros@citi.umich.edu X-BeenThere: spkm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org On Mon, 19 Mar 2007, Martin Rex wrote: > Whether and how much a client can do for trouble-shooting may > be application specific! When helpdesk is called, the only > information that is reliably available/accessible is that > logged centrally on backends/servers. That is true only if the helpdesk is associated with the people operating the servers, rather than the people supporting the user. OFten these are not the same organization, and the only information available is that recorded on the client. If one of my users reports a problem talking to some remote site, I can, if necessary, examine error logs, attach a debugger to their client, and/or observe the traffic on the wire. Actually getting error data from the server can be essential to making this work. That said, applications should be designed to correctly carry error tokens without requiring that they be returned with GSS_S_CONTINUE_NEEDED, because no mechanism should be doing that. -- Jeff _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Mon Mar 26 14:18:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVtlq-00011q-K9; Mon, 26 Mar 2007 14:18:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVtlp-00011b-8y; Mon, 26 Mar 2007 14:18:17 -0400 Received: from currant.srv.cs.cmu.edu ([128.2.194.193]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVtlo-0003z0-0H; Mon, 26 Mar 2007 14:18:17 -0400 Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by currant.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id l2QIICxk009150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Mar 2007 14:18:13 -0400 (EDT) Date: Mon, 26 Mar 2007 14:18:12 -0400 From: Jeffrey Hutzelman To: martin.rex@sap.com, Liqiang Message-ID: <40487DBDE3B881E9262059DA@sirius.fac.cs.cmu.edu> In-Reply-To: <200703191525.QAA04217@uw1048.wdf.sap.corp> References: <200703191525.QAA04217@uw1048.wdf.sap.corp> Originator-Info: login-token=Mulberry:01xXZc7C/e0WARwdRt+PSMW1zokxdMqtUy64pR+/Y=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: kitten@lists.ietf.org, andros@citi.umich.edu, Michael.Eisler@netapp.com, spkm@ietf.org, Jeffrey Hutzelman 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org On Monday, March 19, 2007 04:25:34 PM +0100 Martin Rex wrote: > There seems to be text describing a backward incompatible change in > rfc-4121 last paragraph of section 4.1, (top of page 5) which > allows such misbehaviour for the specific case of an unknown token ID: > > If an unknown token identifier (TOK_ID) is received in the initial > context establishment token, the receiver MUST return > GSS_S_CONTINUE_NEEDED major status, and the returned output token > MUST contain a KRB_ERROR message with the error code > KRB_AP_ERR_MSG_TYPE [RFC4120]. That looks to me like an error in RFC4121. Clearly the status in this case should not be GSS_S_CONTINUE_NEEDED. > SSPI has been returning KRB_ERROR tokens along with CONTINUE_NEEDED > status from the beginning, in an undocumented/unspecified fashion, > non-interoperable with rfc-1964 based Kerberos implementations. Oh, it interoperates, because initiators respond to the KRB-ERROR by returning an error, so the application gives up and never sends a token back. The problem is that returning GSS_S_CONTINUE_NEEDED in this case is likely to confuse a GSS-API application on the acceptor side, because it expects to receive another token from the client. OTOH, since you're describing the behavior of SSPI, not GSS-API, and CONTINUE_NEEDED is an API construct, this situation is perfectly fine -- SSPI can establish different (even broken) semantics for its applications, and an API translation module such as the one you maintain will have to deal. I'd assume you would do this by "knowing" when the mechanism is Kerberos, peeking inside the token, and turning GSS_S_CONTINUE_NEEDED into something else if the token is a KRB-ERROR token. Ugly, but perhaps necessary. -- Jeff _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Mon Mar 26 18:44:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVxvW-0006rM-5a; Mon, 26 Mar 2007 18:44:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVxvU-0006rE-BR; Mon, 26 Mar 2007 18:44:32 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVxvS-0004QA-Tr; Mon, 26 Mar 2007 18:44:32 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id AAA12475; Tue, 27 Mar 2007 00:44:25 +0200 (MESZ) From: Martin Rex Message-Id: <200703262244.AAA15435@uw1048.wdf.sap.corp> To: jhutz@cmu.edu (Jeffrey Hutzelman) Date: Tue, 27 Mar 2007 00:44:24 +0200 (MET DST) In-Reply-To: <40487DBDE3B881E9262059DA@sirius.fac.cs.cmu.edu> from "Jeffrey Hutzelman" at Mar 26, 7 02:18:12 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-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: kitten@lists.ietf.org, andros@citi.umich.edu, Michael.Eisler@netapp.com, spkm@ietf.org, jhutz@cmu.edu Subject: [SPKM] Re: Comments on draft-zhu-pku2u-01.txt 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org Jeffrey Hutzelman wrote: > > On Monday, March 19, 2007 04:25:34 PM +0100 Martin Rex > wrote: > > > There seems to be text describing a backward incompatible change in > > rfc-4121 last paragraph of section 4.1, (top of page 5) which > > allows such misbehaviour for the specific case of an unknown token ID: > > > > If an unknown token identifier (TOK_ID) is received in the initial > > context establishment token, the receiver MUST return > > GSS_S_CONTINUE_NEEDED major status, and the returned output token > > MUST contain a KRB_ERROR message with the error code > > KRB_AP_ERR_MSG_TYPE [RFC4120]. > > That looks to me like an error in RFC4121. Clearly the status in this case > should not be GSS_S_CONTINUE_NEEDED. In principle, such an extension would be OK, provided that the spec was sufficiently clear to provide a fallback continuation of the security context handshake. Compliant gss-api mechanisms are not normally sending context tokens with an unknown TOK_ID, so this change should --in theory-- not break existing conforming implementations. I don't remember that such a change was ever discussed, and I consider it significantly underspecified and hidden. > > > SSPI has been returning KRB_ERROR tokens along with CONTINUE_NEEDED > > status from the beginning, in an undocumented/unspecified fashion, > > non-interoperable with rfc-1964 based Kerberos implementations. > > Oh, it interoperates, because initiators respond to the KRB-ERROR by > returning an error, so the application gives up and never sends a token > back. I know that the KRB_ERROR token is part of rfc1964 and understood by rfc1964 peers, but that is not what I meant. The interoperability that I was refering to was not the indication of an error, but the attempt of recovery that Microsoft has built into their Kerberos SSP and for which the CONTINUE_NEEDED is necessary. Microsoft's Kerberos SSP will perform a second attempt to establish the security context on the same security context handle with another token exchange--and on this feature the other Kerberos 5 implementations will likely not interoperate (because it is not standardized anywhere). > The problem is that returning GSS_S_CONTINUE_NEEDED in this case is > likely to confuse a GSS-API application on the acceptor side, because it > expects to receive another token from the client. OTOH, since you're > describing the behavior of SSPI, not GSS-API, and CONTINUE_NEEDED is an API > construct, this situation is perfectly fine -- SSPI can establish different > (even broken) semantics for its applications, They can and they do use semantics for SSPI that differ from GSS-API, but that makes them non-conforming to rfc-1964/rfc-4121. (they still use the same wire-format, but the GSS-API standard includes API semantics, not just mechanism wire-format. > An API translation module > such as the one you maintain will have to deal. I'd assume you would do > this by "knowing" when the mechanism is Kerberos, peeking inside the token, > and turning GSS_S_CONTINUE_NEEDED into something else if the token is a > KRB-ERROR token. Ugly, but perhaps necessary. Yup, that's what it will have to do. My wrapper is currently limited to rfc-1964 Kerberos, so it aborts on user2user context establishment tokens and aborts with an error when AcceptSecurityContext returns CONTINUE_NEEDED (because rfc-1964 is limited to 1- and 2-token context establishment handshakes). Another interoperability problem with Microsoft Kerberos is the security context lifetime limit required by rfc-1964. When Microsoft tried to activate that in Windows 2000 beta3 hell broke loose because none of their applications could handle expiring security contexts. So they deliberately ignore it. My gssapi wrapper adds this back in, so that you have consistent behaviour within the entire Kerberos5 infrastructure. -Martin _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm