[SPKM] RE: Comments on draft-zhu-pku2u-01.txt
"Liqiang(Larry) Zhu" <lzhu@windows.microsoft.com> Sat, 17 March 2007 02:45 UTC
Return-path: <spkm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 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: <CAAAEFE273EAD341A4B02AAA9CA6F733051CA978@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com>
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: <CAAAEFE273EAD341A4B02AAA9CA6F73304D44CE4@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> <45FB0398.3080406@citi.umich.edu>
From: "Liqiang(Larry) Zhu" <lzhu@windows.microsoft.com>
To: Olga Kornievskaia <aglo@citi.umich.edu>
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 <spkm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/spkm>, <mailto:spkm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/spkm>
List-Post: <mailto:spkm@ietf.org>
List-Help: <mailto:spkm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/spkm>, <mailto:spkm-request@ietf.org?subject=subscribe>
Errors-To: spkm-bounces@ietf.org
Olga Kornievskaia wrote: > 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. 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 > 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. > Since this is a GSS API mechanism what about QoP handling and channel > 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 > 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? > 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? > 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? 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] 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: "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
- [SPKM] FW: I-D ACTION:draft-zhu-pku2u-01.txt Liqiang(Larry) Zhu
- [SPKM] Re: Comments on draft-zhu-pku2u-01.txt Olga Kornievskaia
- [SPKM] RE: Comments on draft-zhu-pku2u-01.txt Jeffrey Hutzelman
- [SPKM] Re: Comments on draft-zhu-pku2u-01.txt Jeffrey Hutzelman
- [SPKM] RE: Comments on draft-zhu-pku2u-01.txt Liqiang(Larry) Zhu
- [SPKM] RE: Comments on draft-zhu-pku2u-01.txt Liqiang(Larry) Zhu
- [SPKM] Re: Comments on draft-zhu-pku2u-01.txt Nicolas Williams
- [SPKM] RE: Comments on draft-zhu-pku2u-01.txt Liqiang(Larry) Zhu
- [SPKM] RE: Comments on draft-zhu-pku2u-01.txt Jeffrey Hutzelman
- [SPKM] Re: Comments on draft-zhu-pku2u-01.txt Nicolas Williams
- [SPKM] Re: Comments on draft-zhu-pku2u-01.txt Jeffrey Hutzelman
- [SPKM] RE: Comments on draft-zhu-pku2u-01.txt Liqiang(Larry) Zhu
- [SPKM] RE: Comments on draft-zhu-pku2u-01.txt Jeffrey Hutzelman
- [SPKM] RE: Comments on draft-zhu-pku2u-01.txt Liqiang(Larry) Zhu
- [SPKM] Re: Comments on draft-zhu-pku2u-01.txt Martin Rex
- [SPKM] Re: Comments on draft-zhu-pku2u-01.txt Martin Rex
- Re: [SPKM] RE: Comments on draft-zhu-pku2u-01.txt Sam Hartman
- [SPKM] Re: Comments on draft-zhu-pku2u-01.txt Martin Rex
- [SPKM] Re: Comments on draft-zhu-pku2u-01.txt Martin Rex
- [SPKM] Re: Comments on draft-zhu-pku2u-01.txt Martin Rex
- Re: [SPKM] RE: Comments on draft-zhu-pku2u-01.txt Martin Rex
- [SPKM] Re: Comments on draft-zhu-pku2u-01.txt Olga Kornievskaia
- Re: [SPKM] Re: Comments on draft-zhu-pku2u-01.txt Olga Kornievskaia
- [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.txt Olga Kornievskaia
- [SPKM] RE: FW: I-D ACTION:draft-zhu-pku2u-01.txt Liqiang(Larry) Zhu
- [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.txt Olga Kornievskaia
- [SPKM] Re: Comments on draft-zhu-pku2u-01.txt Jeffrey Hutzelman
- Re: [SPKM] RE: Comments on draft-zhu-pku2u-01.txt Jeffrey Hutzelman
- [SPKM] Re: Comments on draft-zhu-pku2u-01.txt Jeffrey Hutzelman
- [SPKM] Re: Comments on draft-zhu-pku2u-01.txt Martin Rex
- [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.txt Olga Kornievskaia
- Re: [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.… Nicolas Williams
- RE: [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.… Liqiang(Larry) Zhu
- Re: [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.… Martin Rex
- Re: [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.… Nicolas Williams
- Re: [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.… Martin Rex
- Re: [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.… Nicolas Williams
- Re: [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.… Martin Rex
- Re: [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.… Nicolas Williams
- Re: [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.… Martin Rex
- Re: [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.… Nicolas Williams
- Re: [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.… Martin Rex