From mailman-bounces@ietf.org Sat Jan 1 05:15:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05326 for ; Sat, 1 Jan 2005 05:15:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CkgUM-0006NI-IJ for kitten-archive@ietf.org; Sat, 01 Jan 2005 05:28:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ckg4C-0001Zt-S8 for kitten-archive@ietf.org; Sat, 01 Jan 2005 05:01:00 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: lists.ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: kitten-archive@ietf.org X-No-Archive: yes Message-ID: Date: Sat, 01 Jan 2005 05:00:18 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your lists.ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@lists.ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@lists.ietf.org. Thanks! Passwords for kitten-archive@ietf.org: List Password // URL ---- -------- kitten@lists.ietf.org boikur https://www1.ietf.org/mailman/options/kitten/kitten-archive%40ietf.org From kitten-bounces@ietf.org Mon Jan 3 12:47:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18166; Mon, 3 Jan 2005 12:47:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClWUV-0001YK-MS; Mon, 03 Jan 2005 12:59:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClWC7-0000SA-VG; Mon, 03 Jan 2005 12:40:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClW7p-0006ek-7q for kitten@megatron.ietf.org; Mon, 03 Jan 2005 12:36:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16926 for ; Mon, 3 Jan 2005 12:36:10 -0500 (EST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClWK1-0001D3-Cl for kitten@ietf.org; Mon, 03 Jan 2005 12:48:49 -0500 Received: from jurassic.eng.sun.com ([129.146.81.144]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j03HaBiI003081; Mon, 3 Jan 2005 09:36:11 -0800 (PST) Received: from [192.9.61.32] (punchin-wyllys.SFBay.Sun.COM [192.9.61.32]) by jurassic.eng.sun.com (8.13.2+Sun/8.13.2) with ESMTP id j03Ha9hS503687; Mon, 3 Jan 2005 09:36:10 -0800 (PST) Message-ID: <41D98289.10909@sun.com> Date: Mon, 03 Jan 2005 12:36:09 -0500 From: Wyllys Ingersoll User-Agent: Mozilla Thunderbird 1.0 (X11/20041207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ken Raeburn 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: e8c5db863102a3ada84e0cd52a81a79e Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: spnego-bis comments X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Content-Transfer-Encoding: 7bit Ken Raeburn wrote: > Minor: Page 7 first line, "...and it is OPTIONAL to emit a context > level negotiation token", sounds awkward to me (maybe "OPTIONAL > whether to emit" or "emitting...is OPTIONAL"?). Given the aggressive > work by the RFC Editor these days, it will probably get reworded into > active voice, along with a whole bunch of other stuff. Better to do > it first, than give them more work. How about: "In the case of an unsuccessful negotiation, a reject state is returned and emitting a context level negotiation token is OPTIONAL." > > Minor: Page 8, item (c), "...this mechanism token MUST be deposited to > the selected mechanism". The word "deposited" seems odd here, how > about "passed"? Item (d) likewise. And maybe "emit"->"returned" for > outputs of GSS-API functions. I agree, "deposited" is an awkward term here. Also, "emitted" could be changed to "generated" or "returned". > > Minor: Item (d) "until the GSS_S_COMPLETE is returned", drop "the" or > make it "the GSS_S_COMPLETE status" or something. Agreed. > > Section 3.2 "The basic form of the procedure ... is summarized as > follows". Okay, where's the non-basic, non-summary, fully-detailed > description? If this is the fully detailed description, it should > tell me what the target should do if the initial proposed mechanism is > acceptable, but an error happens processing the included token. Near > as I can tell, (c) says I should return GSS_S_COMPLETE and not send a > reply. If the error happens later, then it's clearer what I should > do. I think item 3.2 (IV) should be changed to indicate what to do when no gss_accept_sec_context returns an error state when processing optimistic tokens. Currently, it appears to describe only what to do upon success and ignores the situation where the optimistic token causes an error in mech-specific processing. How about: ... (IV) Otherwise, no additional negotiation tokens are needed from the initiator to establish the context. If no further negotiation is needed and no optimistic mechanism token was included, then GSS_Accept_Sec_Context() should return GSS_S_COMPLETE to the caller and generate a negotiation token with an "accept_complete" state. If an optimistic mechanism token was included and an error occurs processing this token, then the negotiation token result state should be "reject" and GSS_Accept_Sec_Context() should return the corresponding GSSAPI error code to the caller. If the processing of the optimistic token resulted in a GSS_S_CONTINUE_NEEDED state, then the negotiation state should be "accept_incomplete" , the resulting mech token should be generated and included in the output negotiation response token, and GSS_S_CONTINUE_NEEDED should be returned by GSS_Accept_Sec_Context(). If the optimistic token was processed successfully, the negotiation state should be "accept_completed", any resulting mech token should be generated and included in the output negotiation response token, and GSS_S_COMPLETE should be returned by GSS_Accept_Sec_Context(). ... > > Section 3.2 (d) seems to ignore the possibility that the target didn't > like the proposed mechanism and returned a list of different ones. > And what it if returned only ones which weren't supported by the > initiator? I don't think the acceptor can select mechanisms that are not part of the initiators original list. Perhaps I am misunderstanding your question... > Section 4.2.1: > > reqFlags [1] ContextFlags OPTIONAL, > -- maintained from RFC 2478 for backward compatibility, > -- RECOMMENDED to be left out > > reqFlags > > This field, if present, contains the service options that are > requested to establish the context. The context flags SHOULD > be filled in from the req_flags parameter of > > Which is it? Included (and ignored), or omitted? I think it must be included (and ignored) to maintain backwards compat. > > > Section 5, second paragraph: > > as described later in this section, is OPTIONAL. A mechanism is the > acceptor's most preferred mechanism if there is no other mechanism > which, had it been present in the mechanism list, the acceptor would > have preferred over the accepted mechanism. > > "The most preferred mechanism" implies uniqueness. The rest of the > description does not seem to support that. In fact, if my policy is > "use the first mech listed", then isn't that first mech always going > to qualify (assuming I support it at all)? Or is the intent that this > other mech would always be used if it's in the list, regardless of > position or other mechanisms? (In which case, "use the first mech > listed" has no "most preferred mech" at all.) The first mech presented by the initiator is intended to be the initiators most preferred choice. The acceptor may have a different preferred mech (based on local policy). For example: Initiator sends { B, C } Acceptor prefers { A, B, C } The acceptor sees that initiator wants to use B (most preferred) or C. Acceptor's policy states that A would have been best. A MIC must be used in this situation because someone may have tampered with the list and removed "A", so the acceptor must make sure that the initiator really meant "B,C" and not "A,B,C". The Acceptor's rule is: Use the initiators most preferred mech, unless I have a different preference that was not the same as the intiator's, in which case a MIC exchange must occur to make sure that the exchange was not tampered with. > > When is NegTokenInit.mechListMIC used? Section 3 seems to indicate > that the MIC tokens aren't exchanged until *after* GSS_S_COMPLETE has > been returned on both sides by the agreed-upon mechanism, and aren't > we sure to be using NegTokenResp at that point? (In Section 5 it > appears that it's possible to use mechListMIC in NegTokenInit.) > I think that NegTokenInit is always sent by the initiator. So, if the acceptor returns one of the states that requests a MIC exchange, then the initiator will send another NegTokenInit message with a mechListMIC. > MIC requirements: > > influence the acceptor's choice of mechanism. As discussed in > Section 5, if there are mechanisms that if present in the initiator's > list of mechanisms might be preferred by the acceptor to the > initiator's preferred mechanism, the acceptor MUST demand the MIC > token exchange. As a consequence, acceptors MUST demand the MIC > token exchange if they support negotiation of attributes not > available in the initiator's preferred mechanism regardless of > whether the initiator actually requested these attributes. > > ... (I'm not sure I follow "as a consequence", but I haven't thought > about it enough, or caught up on the mail) but section 5 says: "As a consequence" can probably be edited out of the text without impacting the meaning. > > If the mechanism selected by the negotiation does not support > integrity protection, then no mechlistMIC token is used. > > ... so what if the acceptor supports this attribute negotiation but > they agree on a mechanism without integrity protection? In this case there cannot be a MIC exchange. -Wyllys _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Mon Jan 3 13:54:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25991; Mon, 3 Jan 2005 13:54:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClXXP-0003U3-4i; Mon, 03 Jan 2005 14:06:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClXEe-0000vV-K5; Mon, 03 Jan 2005 13:47:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClX9W-0007FP-PE for kitten@megatron.ietf.org; Mon, 03 Jan 2005 13:42:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24741 for ; Mon, 3 Jan 2005 13:42:01 -0500 (EST) Received: from carter-zimmerman.mit.edu ([18.18.3.197] helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClXLh-00037T-Sk for kitten@ietf.org; Mon, 03 Jan 2005 13:54:40 -0500 Received: by cz.mit.edu (Postfix, from userid 8042) id 9D78DE0063; Mon, 3 Jan 2005 13:43:00 -0500 (EST) To: Wyllys Ingersoll References: <41D98289.10909@sun.com> From: Sam Hartman Date: Mon, 03 Jan 2005 13:43:00 -0500 In-Reply-To: <41D98289.10909@sun.com> (Wyllys Ingersoll's message of "Mon, 03 Jan 2005 12:36:09 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: kitten@ietf.org Subject: Re: spnego-bis comments X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 >>>>> "Wyllys" == Wyllys Ingersoll writes: Wyllys> How about: ... (IV) Otherwise, no additional negotiation Wyllys> tokens are needed from the initiator to establish the Wyllys> context. If no further negotiation is needed and no Wyllys> optimistic mechanism token was included, then Wyllys> GSS_Accept_Sec_Context() should return GSS_S_COMPLETE to Wyllys> the caller and generate a negotiation token with an Wyllys> "accept_complete" state. Wyllys> If the optimistic token was processed successfully, the Wyllys> negotiation state should be "accept_completed", any Wyllys> resulting mech token should be generated and included in Wyllys> the output negotiation response token, and GSS_S_COMPLETE Wyllys> should be returned by GSS_Accept_Sec_Context(). ... Aren't there cases wher you need a MIC even though you have an optimistic token? In these cases accept_complete is the wrong response. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Mon Jan 3 14:02:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27306; Mon, 3 Jan 2005 14:02:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClXfk-0003nI-0A; Mon, 03 Jan 2005 14:15:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClXSR-0006VF-Hd; Mon, 03 Jan 2005 14:01:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClXMb-0003nJ-Ro for kitten@megatron.ietf.org; Mon, 03 Jan 2005 13:55:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26165 for ; Mon, 3 Jan 2005 13:55:32 -0500 (EST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClXYl-0003Wc-Iy for kitten@ietf.org; Mon, 03 Jan 2005 14:08:11 -0500 Received: from jurassic.eng.sun.com ([129.146.89.31]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j03ItSiI000362; Mon, 3 Jan 2005 10:55:28 -0800 (PST) Received: from [192.9.61.32] (punchin-wyllys.SFBay.Sun.COM [192.9.61.32]) by jurassic.eng.sun.com (8.13.2+Sun/8.13.2) with ESMTP id j03ItQ7U542297; Mon, 3 Jan 2005 10:55:27 -0800 (PST) Message-ID: <41D9951E.5090402@sun.com> Date: Mon, 03 Jan 2005 13:55:26 -0500 From: Wyllys Ingersoll User-Agent: Mozilla Thunderbird 1.0 (X11/20041207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Hartman References: <41D98289.10909@sun.com> 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: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: spnego-bis comments X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Sam Hartman wrote: > Wyllys> If the optimistic token was processed successfully, the > Wyllys> negotiation state should be "accept_completed", any > Wyllys> resulting mech token should be generated and included in > Wyllys> the output negotiation response token, and GSS_S_COMPLETE > Wyllys> should be returned by GSS_Accept_Sec_Context(). ... > >Aren't there cases wher you need a MIC even though you have an >optimistic token? In these cases accept_complete is the wrong >response. > > You are correct. This is sort of covered by the statement in 3.2(e): (e) MIC tokens are then either skipped or exchanged according to Section 5. However, to make this clearer, perhaps (IV) should be further amended: ... If the optimistic token was processed successfully, any resulting mech token should be included in the output negotiation response token. The final status of the GSS_Accept_Sec_Context() function and the returned state in the negotiation response token will be computed according to the rules outlined in section 5. ... -Wyllys _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Mon Jan 3 17:03:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26146; Mon, 3 Jan 2005 17:03:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClaUi-0003pg-Cg; Mon, 03 Jan 2005 17:16:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cla2Z-0000fN-Mh; Mon, 03 Jan 2005 16:47:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClZMM-0000Zn-4G for kitten@megatron.ietf.org; Mon, 03 Jan 2005 16:03:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10815 for ; Mon, 3 Jan 2005 16:03:24 -0500 (EST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClZYY-0007JR-47 for kitten@ietf.org; Mon, 03 Jan 2005 16:16:04 -0500 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j03L3MiI008034 for ; Mon, 3 Jan 2005 13:03:22 -0800 (PST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j03L3KJf020876 for ; Mon, 3 Jan 2005 14:03:20 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id j03L2Dot248902; Mon, 3 Jan 2005 15:02:13 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id j03L2CWK248901; Mon, 3 Jan 2005 15:02:12 -0600 (CST) Date: Mon, 3 Jan 2005 15:02:12 -0600 From: Nicolas Williams To: Wyllys Ingersoll Message-ID: <20050103210212.GJ184117@binky.central.sun.com> Mail-Followup-To: Wyllys Ingersoll , Ken Raeburn , kitten@ietf.org References: <41D98289.10909@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41D98289.10909@sun.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: kitten@ietf.org, Ken Raeburn Subject: Re: spnego-bis comments X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f On Mon, Jan 03, 2005 at 12:36:09PM -0500, Wyllys Ingersoll wrote: > Ken Raeburn wrote: > >Section 3.2 (d) seems to ignore the possibility that the target didn't > >like the proposed mechanism and returned a list of different ones. > >And what it if returned only ones which weren't supported by the > >initiator? > > > I don't think the acceptor can select mechanisms that are not part > of the initiators original list. Perhaps I am misunderstanding your > question... Right. The initiator can trivially detect that UNLESS a situation such as brought up by Bill Sommerfeld in his thought experiment exists. > >Section 4.2.1: > > > > reqFlags [1] ContextFlags OPTIONAL, > > -- maintained from RFC 2478 for backward compatibility, > > -- RECOMMENDED to be left out > > > > reqFlags > > > > This field, if present, contains the service options that are > > requested to establish the context. The context flags SHOULD > > be filled in from the req_flags parameter of > > > >Which is it? Included (and ignored), or omitted? > > I think it must be included (and ignored) to maintain backwards > compat. I disagree. It SHOULD NOT be present in the token, and acceptors MUST ignore it. It's ok to leave it out since it's been OPTIONAL all along. And acceptors ignore it nowadays anyways -- what else can they do with it? After all, GSS_Accept_sec_context() does not have a flags input parameter. > > > > > >Section 5, second paragraph: > > > > as described later in this section, is OPTIONAL. A mechanism is the > > acceptor's most preferred mechanism if there is no other mechanism > > which, had it been present in the mechanism list, the acceptor would > > have preferred over the accepted mechanism. > > > >"The most preferred mechanism" implies uniqueness. The rest of the > >description does not seem to support that. In fact, if my policy is > >"use the first mech listed", then isn't that first mech always going > >to qualify (assuming I support it at all)? Or is the intent that this > >other mech would always be used if it's in the list, regardless of > >position or other mechanisms? (In which case, "use the first mech > >listed" has no "most preferred mech" at all.) To me the intent is clear that: a) the mechList is a list of OIDS ordered by initiator preference, from most preferred to least preferred, and b) that the acceptor may or may not have a preference policy of its own, which may be expressed through an abstraction more complex than a list, such that for some initiator's mechLists the acceptor will insist on a mechListMIC exchange. > >When is NegTokenInit.mechListMIC used? Section 3 seems to indicate > >that the MIC tokens aren't exchanged until *after* GSS_S_COMPLETE has > >been returned on both sides by the agreed-upon mechanism, and aren't > >we sure to be using NegTokenResp at that point? (In Section 5 it > >appears that it's possible to use mechListMIC in NegTokenInit.) > > > I think that NegTokenInit is always sent by the initiator. So, if the > acceptor returns one of the states that requests a MIC exchange, then the > initiator will send another NegTokenInit message with a mechListMIC. NegTokenInit is to be used only for the first SPNEGO token, NegTokenResp is to be used for all other tokens. As to Ken's question, I'm not sure, but I think the initiator can use it in optimistic mech token cases where no further mech tokens are expected (i.e., one-mech-token exchanges, like krb5 w/o mutual auth) to request that the acceptor respond with with a negTokenResp containing a mechListMIC. Larry? > > If the mechanism selected by the negotiation does not support > > integrity protection, then no mechlistMIC token is used. > > > >... so what if the acceptor supports this attribute negotiation but > >they agree on a mechanism without integrity protection? This doesn't make sense. Integrity protection and other such context attributes aren't actually negotiated by SPNEGO, NegTokenInit.ContextFlags notwithstanding (see above). > In this case there cannot be a MIC exchange. Right, and there is enough security considerations on this anyways. And, and as has been pointed out, generally speaking negotiation of any security mechanisms that do not support integrity protection means that the negotiation cannot be secure against downgrade attacks. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Mon Jan 3 17:10:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27256; Mon, 3 Jan 2005 17:10:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Clab8-00048w-Nh; Mon, 03 Jan 2005 17:22:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cla4f-0003mF-5L; Mon, 03 Jan 2005 16:49:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClZZs-0005Oi-66 for kitten@megatron.ietf.org; Mon, 03 Jan 2005 16:17:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14453 for ; Mon, 3 Jan 2005 16:17:22 -0500 (EST) Received: from cathode-dark-space.mit.edu ([18.18.1.96]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClZm5-00006w-I5 for kitten@ietf.org; Mon, 03 Jan 2005 16:30:02 -0500 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9) id j03LHJmT000792; Mon, 3 Jan 2005 16:17:19 -0500 (EST) To: "Liqiang\(Larry\) Zhu" References: From: Tom Yu Date: Mon, 03 Jan 2005 16:17:19 -0500 In-Reply-To: (Liqiang Zhu's message of "Fri, 31 Dec 2004 04:26:12 -0800") Message-ID: Lines: 19 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: kitten@ietf.org, hartmans-ietf@mit.edu Subject: Re: SPNEGO-bis comments/questions X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 >>>>> "lzhu" == Liqiang\(Larry\) Zhu writes: lzhu> 1) The ContextFlags will be decorated with the size constrain. lzhu> ContextFlags ::= BIT STRING (SIZE (32)) { lzhu> delegFlag (0), lzhu> mutualFlag (1), lzhu> replayFlag (2), lzhu> sequenceFlag (3), lzhu> anonFlag (4), lzhu> confFlag (5), lzhu> integFlag (6) lzhu> } Please recall that applying a size constraint to BIT STRING with named bits requires that a DER encoder truncate trailing zero bits. This caused interoperability problems for Kerberos. ---Tom _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Mon Jan 3 17:27:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29196; Mon, 3 Jan 2005 17:27:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Clas7-0004fR-9e; Mon, 03 Jan 2005 17:40:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClaVr-0008T7-Vj; Mon, 03 Jan 2005 17:17:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClaDz-0003Qj-PF for kitten@megatron.ietf.org; Mon, 03 Jan 2005 16:58:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25098 for ; Mon, 3 Jan 2005 16:58:49 -0500 (EST) Received: from carter-zimmerman.mit.edu ([18.18.3.197] helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClaQD-0003XU-HI for kitten@ietf.org; Mon, 03 Jan 2005 17:11:30 -0500 Received: by cz.mit.edu (Postfix, from userid 8042) id 6F515E0063; Mon, 3 Jan 2005 16:59:50 -0500 (EST) To: Tom Yu References: From: Sam Hartman Date: Mon, 03 Jan 2005 16:59:50 -0500 In-Reply-To: (Tom Yu's message of "Mon, 03 Jan 2005 16:17:19 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: kitten@ietf.org, "Liqiang\(Larry\) Zhu" Subject: Re: SPNEGO-bis comments/questions X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c >>>>> "Tom" == Tom Yu writes: Tom> Please recall that applying a size constraint to BIT STRING Tom> with named bits requires that a DER encoder truncate trailing Tom> zero bits. This caused interoperability problems for Tom> Kerberos. doesn't DER already imply this? --Sam _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Mon Jan 3 17:31:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29802; Mon, 3 Jan 2005 17:31:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClavU-0004nj-No; Mon, 03 Jan 2005 17:43:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Clabd-0003Dv-Sc; Mon, 03 Jan 2005 17:23:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClaPX-0005H8-FC for kitten@megatron.ietf.org; Mon, 03 Jan 2005 17:10:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27342 for ; Mon, 3 Jan 2005 17:10:45 -0500 (EST) Received: from cathode-dark-space.mit.edu ([18.18.1.96]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Clabl-0004AR-Do for kitten@ietf.org; Mon, 03 Jan 2005 17:23:26 -0500 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9) id j03MAjso003456; Mon, 3 Jan 2005 17:10:45 -0500 (EST) To: Sam Hartman References: From: Tom Yu Date: Mon, 03 Jan 2005 17:10:45 -0500 In-Reply-To: (Sam Hartman's message of "Mon, 03 Jan 2005 16:59:50 -0500") Message-ID: Lines: 14 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: kitten@ietf.org, "Liqiang\(Larry\) Zhu" Subject: Re: SPNEGO-bis comments/questions X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 >>>>> "Sam" == Sam Hartman writes: >>>>> "Tom" == Tom Yu writes: Tom> Please recall that applying a size constraint to BIT STRING Tom> with named bits requires that a DER encoder truncate trailing Tom> zero bits. This caused interoperability problems for Tom> Kerberos. Sam> doesn't DER already imply this? Oops, yeah, it already does require the truncation, but the size constraint doesn't change the truncation. ---Tom _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Mon Jan 3 17:31:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29865; Mon, 3 Jan 2005 17:31:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Clavb-0004oY-DG; Mon, 03 Jan 2005 17:43:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Claew-0005C3-He; Mon, 03 Jan 2005 17:26:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClaSM-0006Fv-OF for kitten@megatron.ietf.org; Mon, 03 Jan 2005 17:13:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27573 for ; Mon, 3 Jan 2005 17:13:40 -0500 (EST) Received: from carter-zimmerman.mit.edu ([18.18.3.197] helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Claea-0004Dv-P4 for kitten@ietf.org; Mon, 03 Jan 2005 17:26:21 -0500 Received: by cz.mit.edu (Postfix, from userid 8042) id 48F43E0063; Mon, 3 Jan 2005 17:14:42 -0500 (EST) To: Wyllys Ingersoll References: <41D98289.10909@sun.com> <20050103210212.GJ184117@binky.central.sun.com> From: Sam Hartman Date: Mon, 03 Jan 2005 17:14:42 -0500 In-Reply-To: <20050103210212.GJ184117@binky.central.sun.com> (Nicolas Williams's message of "Mon, 3 Jan 2005 15:02:12 -0600") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: kitten@ietf.org Subject: Re: spnego-bis comments X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab >>>>> "Nicolas" == Nicolas Williams writes: >> > If the mechanism selected by the negotiation does not support >> > integrity protection, then no mechlistMIC token is used. >> > >> >... so what if the acceptor supports this attribute >> negotiation but >they agree on a mechanism without integrity >> protection? Nicolas> This doesn't make sense. Integrity protection and other Nicolas> such context attributes aren't actually negotiated by Nicolas> SPNEGO, NegTokenInit.ContextFlags notwithstanding (see Nicolas> above). Sure it can once we define an OID for integrity. However the question has already been answered. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Mon Jan 3 17:49:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01305; Mon, 3 Jan 2005 17:49:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClbCr-0005Cq-Ml; Mon, 03 Jan 2005 18:01:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Clak7-0000fQ-5D; Mon, 03 Jan 2005 17:32:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Clai3-0007eI-5Y for kitten@megatron.ietf.org; Mon, 03 Jan 2005 17:29:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29436 for ; Mon, 3 Jan 2005 17:29:52 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClauG-0004id-7C for kitten@ietf.org; Mon, 03 Jan 2005 17:42:34 -0500 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j03MTpVu005080 for ; Mon, 3 Jan 2005 15:29:52 -0700 (MST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j03MTpjW022556 for ; Mon, 3 Jan 2005 15:29:51 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id j03MSiWB249140; Mon, 3 Jan 2005 16:28:44 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id j03MSefV249139; Mon, 3 Jan 2005 16:28:40 -0600 (CST) Date: Mon, 3 Jan 2005 16:28:40 -0600 From: Nicolas Williams To: Sam Hartman Message-ID: <20050103222840.GL184117@binky.central.sun.com> Mail-Followup-To: Sam Hartman , Tom Yu , kitten@ietf.org, "Liqiang(Larry) Zhu" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: kitten@ietf.org, "Liqiang\(Larry\) Zhu" Subject: Re: SPNEGO-bis comments/questions X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 On Mon, Jan 03, 2005 at 04:59:50PM -0500, Sam Hartman wrote: > >>>>> "Tom" == Tom Yu writes: > > Tom> Please recall that applying a size constraint to BIT STRING > Tom> with named bits requires that a DER encoder truncate trailing > Tom> zero bits. This caused interoperability problems for > Tom> Kerberos. > > doesn't DER already imply this? Yes, but it's a good warning/reminder to have. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Mon Jan 3 17:49:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01353; Mon, 3 Jan 2005 17:49:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClbDg-0005DV-I1; Mon, 03 Jan 2005 18:02:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClalJ-00015u-N8; Mon, 03 Jan 2005 17:33:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Claig-00086Q-3P for kitten@megatron.ietf.org; Mon, 03 Jan 2005 17:30:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29579 for ; Mon, 3 Jan 2005 17:30:31 -0500 (EST) Received: from smtpsrv11.isis.unc.edu ([152.2.1.242] helo=smtp.unc.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Clauu-0004kc-U6 for kitten@ietf.org; Mon, 03 Jan 2005 17:43:13 -0500 Received: from [152.2.246.1] (hillary.oit.unc.edu [152.2.246.1]) by smtp.unc.edu (8.12.9/8.12.9) with ESMTP id j03MUE5V014788; Mon, 3 Jan 2005 17:30:14 -0500 (EST) Message-ID: <41D9C77C.8000307@unc.edu> Date: Mon, 03 Jan 2005 17:30:20 -0500 From: Simon Spero User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: X-Spam-Score: 0.5 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: kitten@ietf.org, "Liqiang\(Larry\) Zhu" Subject: Re: SPNEGO-bis comments/questions X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1781417265==" Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 This is a multi-part message in MIME format. --===============1781417265== Content-Type: multipart/alternative; boundary="------------010608050400080908070100" This is a multi-part message in MIME format. --------------010608050400080908070100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by smtp.unc.edu id j03MUE5V014788 Content-Transfer-Encoding: quoted-printable Sam Hartman wrote: > Tom> Please recall that applying a size constraint to BIT STRING > Tom> with named bits requires that a DER encoder truncate trailing > Tom> zero bits. This caused interoperability problems for > Tom> Kerberos. > >doesn't DER already imply this? > =20 > It's a little confusing, but in this case it's not too bad. X.690 requires all unused bits in the final octet to be set to zero 11.2.1 Each unused bit in the final octet of the encoding of a bit string value shall be set to zero. ITU X.690 =A7 11.2.1 It also requires trailing zero's to be stripped before transmission iff=20 the abstract type has a named bit list defined 11.2.2 Where ITU-T Rec. X.680 | ISO/IEC 8824-1, 21.7, applies, the bitstring shall have all trailing 0 bits removed before it is encoded..=20 X.690 =A711.2.2 If there are no bits set, then DER/CER generate an encoding with length=20 1 and value 0. NOTE 2 - If a bitstring value has no 1 bits, then an encoder shall encode the value with a length of 1 and an initial octet set to 0. X.690 =A7 11.2.2 at Note 2 The effect of the size constraint is only visible to the decoding=20 application; the decoder is supposed to append trailing zero bits to=20 the decoded value to make it fit the size constraint. NOTE 1 - In the case where a size constraint has been applied, the abstract value delivered by a decoder to the application will be one of those satisfying the size constraint and differing from the transmitted value only in the number of trailing 0 bits. X.690 =A7 11.2.2 at Note 1 Simon --------------010608050400080908070100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sam Hartman wrote:
    Tom> Please recall that applying a size constraint to BIT STRING
    Tom> with named bits requires that a DER encoder truncate trailing
    Tom> zero bits.  This caused interoperability problems for
    Tom> Kerberos.

doesn't DER already imply this?
It's a little confusing, but in this case it's not too bad.

X.690 requires all  unused bits in the final octet to be set to zero
11.2.1 Each unused bit in the final octet of the encoding of a bit string value shall be set to zero.
ITU X.690 § 11.2.1
It also requires trailing zero's to be stripped before transmission iff the abstract type has a named bit list defined
11.2.2 Where ITU-T Rec. X.680 | ISO/IEC 8824-1, 21.7, applies, the bitstring shall have all trailing 0 bits removed
before it is encoded.. 
X.690 §11.2.2
If  there are no bits set, then DER/CER generate an encoding with length 1 and value 0.
NOTE 2 – If a bitstring value has no 1 bits, then an encoder shall encode the value with a length of 1 and an initial octet set to 0.
X.690 § 11.2.2 at Note 2
The effect of the size constraint is only visible to the decoding application;  the decoder is supposed to append trailing zero bits to the decoded value to make it fit the size constraint.
NOTE 1 – In the case where a size constraint has been applied, the abstract value delivered by a decoder to the application will be
one of those satisfying the size constraint and differing from the transmitted value only in the number of trailing 0 bits.
X.690 § 11.2.2 at Note 1

Simon





--------------010608050400080908070100-- --===============1781417265== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============1781417265==-- From kitten-bounces@ietf.org Mon Jan 3 19:58:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11677; Mon, 3 Jan 2005 19:58:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CldDm-00081w-PO; Mon, 03 Jan 2005 20:10:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Clcx9-0005Nm-1q; Mon, 03 Jan 2005 19:53:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClcrW-00038o-5R for kitten@megatron.ietf.org; Mon, 03 Jan 2005 19:47:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10387 for ; Mon, 3 Jan 2005 19:47:46 -0500 (EST) Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cld3c-0007hj-DW for kitten@ietf.org; Mon, 03 Jan 2005 20:00:30 -0500 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id BAA08939; Tue, 4 Jan 2005 01:46:57 +0100 (MEZ) From: Martin Rex Message-Id: <200501040046.BAA04277@uw1048.wdf.sap.corp> To: Nicolas.Williams@Sun.COM (Nicolas Williams) Date: Tue, 4 Jan 2005 01:46:49 +0100 (MET) In-Reply-To: <20050103210212.GJ184117@binky.central.sun.com> from "Nicolas Williams" at Jan 3, 5 03:02: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-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org, Wyllys.Ingersoll@Sun.COM, raeburn@MIT.EDU Subject: Re: spnego-bis comments X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 8bit Nicolas Williams wrote: > > > >Section 4.2.1: > > > > > > reqFlags [1] ContextFlags OPTIONAL, > > > -- maintained from RFC 2478 for backward compatibility, > > > -- RECOMMENDED to be left out > > > > > > reqFlags > > > > > > This field, if present, contains the service options that are > > > requested to establish the context. The context flags SHOULD > > > be filled in from the req_flags parameter of > > > > > >Which is it? Included (and ignored), or omitted? > > > > I think it must be included (and ignored) to maintain backwards > > compat. > > I disagree. It SHOULD NOT be present in the token, and acceptors MUST > ignore it. > > It's ok to leave it out since it's been OPTIONAL all along. And > acceptors ignore it nowadays anyways -- what else can they do with it? > After all, GSS_Accept_sec_context() does not have a flags input > parameter. The purpose of the flags field was for the application to indicate which features (integrity,confidentiality,mutual auth) it expects from a security context so that it can be considered by the accepting SPNEGO when selecting the mechanism. If the accepting SPNEGO ignores such indicators and selects a mechanism that does not offer one of the features requested by the initiating application, that might result in a communication failure, since the initiating application may delete a security context that does not offer certain security features. In most cases the effect of the acceptor ignoring these flags will not be noticable. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Mon Jan 3 20:09:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12500; Mon, 3 Jan 2005 20:09:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CldOY-0008En-QD; Mon, 03 Jan 2005 20:22:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cld2t-000832-Bf; Mon, 03 Jan 2005 19:59:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Clcy4-0005i9-AG for kitten@megatron.ietf.org; Mon, 03 Jan 2005 19:54:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11300 for ; Mon, 3 Jan 2005 19:54:35 -0500 (EST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CldAH-0007vR-Gj for kitten@ietf.org; Mon, 03 Jan 2005 20:07:17 -0500 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j040sViI008748 for ; Mon, 3 Jan 2005 16:54:31 -0800 (PST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j040sVJf021200 for ; Mon, 3 Jan 2005 17:54:31 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id j040rO76249457; Mon, 3 Jan 2005 18:53:24 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id j040rNMT249456; Mon, 3 Jan 2005 18:53:23 -0600 (CST) Date: Mon, 3 Jan 2005 18:53:23 -0600 From: Nicolas Williams To: Martin Rex Message-ID: <20050104005322.GM184117@binky.central.sun.com> Mail-Followup-To: Martin Rex , Wyllys.Ingersoll@Sun.COM, kitten@ietf.org, raeburn@MIT.EDU References: <20050103210212.GJ184117@binky.central.sun.com> <200501040046.BAA04277@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200501040046.BAA04277@uw1048.wdf.sap.corp> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: kitten@ietf.org, Wyllys.Ingersoll@Sun.COM, raeburn@MIT.EDU Subject: Re: spnego-bis comments X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 On Tue, Jan 04, 2005 at 01:46:49AM +0100, Martin Rex wrote: > The purpose of the flags field was for the application to indicate which > features (integrity,confidentiality,mutual auth) it expects from a > security context so that it can be considered by the accepting SPNEGO > when selecting the mechanism. > > If the accepting SPNEGO ignores such indicators and selects a mechanism > that does not offer one of the features requested by the initiating > application, that might result in a communication failure, since > the initiating application may delete a security context that > does not offer certain security features. Sure, BUT, a) the context flags are not integrity protected (they could be if we replaced the concept with flag OIDs), so MITMs and transmission errors could always force such failures, and b) SPNEGO acceptors have to hardcode knowledge of what mechanisms support what features, c) a given mechanism should support, or not, a given feature represented in the context flags consistently. I know that this is not always true. For example, Solaris' krb5 mechanism used to have a variant for export purposes which did not support confidentiality protection -- but this is quite heavy handed and easily leads to interop problems, and how would SPNEGO know, particularly in a multi-mechanism, non-monolithic GSS implementation? (I've given an answer to the latter here, quite recently.) > In most cases the effect of the acceptor ignoring these flags will > not be noticable. Correct. Do you know of any implementations where a SPNEGO acceptor does not ignore the context flags field? Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Jan 4 01:25:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29713; Tue, 4 Jan 2005 01:25:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CliKe-0005b4-DF; Tue, 04 Jan 2005 01:38:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cli6h-0001A2-4N; Tue, 04 Jan 2005 01:23:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cli5L-0000SY-FL for kitten@megatron.ietf.org; Tue, 04 Jan 2005 01:22:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29581 for ; Tue, 4 Jan 2005 01:22:26 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CliHe-0005Vp-60 for kitten@ietf.org; Tue, 04 Jan 2005 01:35:10 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 3 Jan 2005 22:21:54 -0800 Received: from red-hub-01.redmond.corp.microsoft.com ([157.54.7.71]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 3 Jan 2005 22:21:53 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1264); Mon, 3 Jan 2005 22:21:54 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Mon, 3 Jan 2005 22:21:54 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 3 Jan 2005 22:21:53 -0800 Message-ID: Thread-Topic: Review: of draft-ietf-kitten-2478bis-03.txt Thread-Index: AcTj3wVGv6Bm5EnpRwaKYVEoMnNLNwOLpDrQ From: "Liqiang\(Larry\) Zhu" To: "Bill Sommerfeld" , X-OriginalArrivalTime: 04 Jan 2005 06:21:54.0297 (UTC) FILETIME=[AF5BFE90:01C4F225] X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Content-Transfer-Encoding: quoted-printable Cc: Russ Housley , Sam Hartman Subject: RE: Review: of draft-ietf-kitten-2478bis-03.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Content-Transfer-Encoding: quoted-printable Bill Sommerfeld wrote: > 1) ... > The safety, or lack there of, of making the mechlistMIC optional appears to depend in part on all of the acceptable=20 > mechanisms sharing a > property: they will never mistake a token for another mechanism as if it were intended for them. this property needs to=20 > be explicitly spelled out in the spec. I disagree. The security of SPNEGO-bis does not depend on whether the optimistic token is used or not. It is interesting to find out the implication that a mech token can be accepted by two different mechs, but I am not sure either this can be a security issue for SPNEGO-bis or SPNEGO-bis is not able handle it correctly with the current protocol. About the thought experiment, this is not strictly necessary in that: 1) the proof of the security is not difficult (it can be done using exhaustive enumerations of different sub-cases) and 2) the description in section 5 can be easily mapped to thought experiments you are looking for. Nico responded to 2, 3) and 4). I agree with him, therefore no change will be made for those comments. 5) > This is very ambiguous as it's not clear whether it is forbidding termination in this case or merely allowing >=20 > continuation. The normative description is in section 5. > If the receiver detects an alteration, but the alteration had no > material impact on the negotiation, the receiver MAY opt to continue > the session. This is incorrect: no attempt is made to detect alterations when it is safe to omit the meclistMIC tokens and if an alteration is detected, the current protocol requires the negotiation to fail. This sentence is more of an observation therefore I can remove it from security considerations. =20 > 6) appendix C example: > IMHO you should also pick an example mechanism, key, etc., and include the computed MIC. This section is not meant to provide test-vectors; rather Wyllys' example is used to illustrate what is the encoding of a specific ASN.1 type. I believe the point is clearly illustrated, and providing exact values will in fact hurt the presentation. -- larry -----Original Message----- From: kitten-bounces@lists.ietf.org [mailto:kitten-bounces@lists.ietf.org] On Behalf Of Bill Sommerfeld Sent: Thursday, December 16, 2004 6:14 PM To: kitten@ietf.org Cc: Sam Hartman; Russ Housley Subject: Review: of draft-ietf-kitten-2478bis-03.txt Sam Hartman asked me to look at the 2478bis-03 draft. I should first say that it's been a long time since i've looked at anything GSSAPI related at this level of detail. My review is largely confined to higher level details; I'll leave it to someone else to determine if the bits-on-the-wire encodings match reality. 1) safety of omitting mechlistMIC: The safety, or lack there of, of making the mechlistMIC optional appears to depend in part on all of the acceptable mechanisms sharing a property: they will never mistake a token for another mechanism as if it were intended for them. this property needs to be explicitly spelled out in the spec. The safety of omitting the mechlistMIC when the first choice is picked depends on mechanisms reliably rejecting tokens not intended for them; this property needs to be documented. A thought experiment:=20 Consider a pair (or larger sized sets) of mechanisms with different semantics but identical syntax, which share a common underlying credential mechanism. here's a slightly twisted example: a server-authentication-only variant of kerberos where mutual authenticaton is done as usual but where the identity presented to the target application is anonymous/"nobody". assume the client is juggling multiple kerberos identities, and would present one with the server-auth-only mech and a different one to the regular kerberos mechanism. It seems like it would be possible in this case for a MITM to mess up the negotiation unless the mechanism OID is cryptographically linked to the exchange. 2) excessive optimistic negotiation flexibility. Excessive numbers of options and configuration knobs present a real cost to implementors and users. whether or not to send an optimistic token should perhaps be a property of the mechanism, either in the mechanism spec (for new mechanisms) or in a separate spec. 3) a potential race condition (page 6: client "MUST NOT" include mechs it doesn't't have creds for in the list of acceptable mechanisms). Credentials could be administratively deleted between the first message and the response. when the server responds accepting an option no longer open to the client, the client will essentially be forced to abort the negotiation (at application level?) and retry. It could also be the case that mechanisms requiring an interaction with an on-line service to produce or validate a token could encounter a soft failure due to connectivity problems. the net result of this is an exchange which looks to the server or an external third-party observer as if the client violated this MUST NOT... 4) This statement in appendix B needs more detail. "Even if there are such implementations, it is unlikely that they will interoperate because of a critical flaw in the description of the encoding of the mechanism list in RFC 2478." what was this flaw? if there are multiple possible interpretations, an implementation could well try multiple reformulations of the input to the hash function.. overall: allow implementations to cache state and/or policy about peer capabilities, as a better interoperability solution than failing to interop with the RFC? 5) vague material in sec-cons (page 18): The negotiation may not be terminated if an alteration was made but it had no material impact. This is very ambiguous as it's not clear whether it is forbidding termination in this case or merely allowing continuation. I think you mean: If the receiver detects an alteration, but the alteration had no material impact on the negotiation, the reciever MAY opt to continue the session. It's also the case that "material alteration" is not defined. 6) appendix C example: IMHO you should should also pick an example mechanism, key, etc., and include the computed MIC. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Jan 4 02:11:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15301; Tue, 4 Jan 2005 02:11:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Clj3B-0006bE-QE; Tue, 04 Jan 2005 02:24:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Clin3-0002aG-RJ; Tue, 04 Jan 2005 02:07:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Clij3-0008B1-NO for kitten@megatron.ietf.org; Tue, 04 Jan 2005 02:03:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07096 for ; Tue, 4 Jan 2005 02:03:28 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClivJ-0006Qp-LO for kitten@ietf.org; Tue, 04 Jan 2005 02:16:13 -0500 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j0473OVu013016 for ; Tue, 4 Jan 2005 00:03:24 -0700 (MST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j0473OJf024346 for ; Tue, 4 Jan 2005 00:03:24 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id j0472HrG249751; Tue, 4 Jan 2005 01:02:17 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id j0472Gm1249750; Tue, 4 Jan 2005 01:02:16 -0600 (CST) Date: Tue, 4 Jan 2005 01:02:16 -0600 From: Nicolas Williams To: "Liqiang(Larry) Zhu" Message-ID: <20050104070215.GS184117@binky.central.sun.com> Mail-Followup-To: "Liqiang(Larry) Zhu" , Bill Sommerfeld , kitten@ietf.org, Russ Housley , Sam Hartman References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: kitten@ietf.org, Sam Hartman , Russ Housley Subject: Re: Review: of draft-ietf-kitten-2478bis-03.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 On Mon, Jan 03, 2005 at 10:21:53PM -0800, Liqiang(Larry) Zhu wrote: > Bill Sommerfeld wrote: > > 1) ... > > The safety, or lack there of, of making the mechlistMIC optional > appears to depend in part on all of the acceptable > > mechanisms sharing a > > > property: they will never mistake a token for another mechanism as if > it were intended for them. this property needs to > > be explicitly spelled out in the spec. > > I disagree. The security of SPNEGO-bis does not depend on whether the > optimistic token is used or not. > > It is interesting to find out the implication that a mech token can be > accepted by two different mechs, but I am not sure either this can be a > security issue for SPNEGO-bis or SPNEGO-bis is not able handle it > correctly with the current protocol. > > About the thought experiment, this is not strictly necessary in that: > 1) the proof of the security is not difficult (it can be done using > exhaustive enumerations of different sub-cases) and 2) the description > in section 5 can be easily mapped to thought experiments you are looking > for. Bill's thought experiment is, IMO, on the money -- it just isn't specific to SPNEGO. Basically if the OID in the pseudo-ASN.1/DER wrapper on the first GSS token is significant w.r.t. and if the mechanism does not provide integrity protection for that OID, then there may exist an attack on that mechanism involving an MITM changing that OID on the wire. But this is not specific to SPNEGO because an acceptor doesn't need SPNEGO in order to be able to accept contexts for multiple mechanisms at the initiator's choice. That's the way GSS_Accept_sec_context() works. In a multi-mechanism GSS environment it has to route the initial token to the code corresponding to the OID in that wrapper, if the acceptor credential has an element corresponding to it; the mech may output a different actual OID at the end than was used on the wire in that wrapper, but that doesn't mean that mechanism actually provided any integrity protection to that OID. Yet, while I think we can dispose of Bill's thought experiment as being general to the GSS-API, rather than specific to SPNEGO, I also think it's still worthy of mention in the security considerations as I'd rather it be discussed in some GSS RFC than in none at all (to be fair, I haven't checked that it isn't mentioned in any of the GSS RFCs). Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Jan 4 02:35:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20005; Tue, 4 Jan 2005 02:35:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CljPv-0006xw-8D; Tue, 04 Jan 2005 02:47:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Clj6A-00077b-Hq; Tue, 04 Jan 2005 02:27:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Clj4o-0006Vl-Bu for kitten@megatron.ietf.org; Tue, 04 Jan 2005 02:25:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19399 for ; Tue, 4 Jan 2005 02:25:57 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CljH8-0006oD-0c for kitten@ietf.org; Tue, 04 Jan 2005 02:38:42 -0500 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j047PuVu021958 for ; Tue, 4 Jan 2005 00:25:56 -0700 (MST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j047PuJf000827 for ; Tue, 4 Jan 2005 00:25:56 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id j047Om7c249777; Tue, 4 Jan 2005 01:24:49 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id j047Om4A249776; Tue, 4 Jan 2005 01:24:48 -0600 (CST) Date: Tue, 4 Jan 2005 01:24:48 -0600 From: Nicolas Williams To: "Liqiang(Larry) Zhu" , Bill Sommerfeld , kitten@ietf.org, Russ Housley , Sam Hartman Message-ID: <20050104072448.GT184117@binky.central.sun.com> Mail-Followup-To: "Liqiang(Larry) Zhu" , Bill Sommerfeld , kitten@ietf.org, Russ Housley , Sam Hartman References: <20050104070215.GS184117@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050104070215.GS184117@binky.central.sun.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: Re: Review: of draft-ietf-kitten-2478bis-03.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 On Tue, Jan 04, 2005 at 01:02:16AM -0600, Nicolas Williams wrote: > Yet, while I think we can dispose of Bill's thought experiment as being > general to the GSS-API, rather than specific to SPNEGO, I also think > it's still worthy of mention in the security considerations as I'd > rather it be discussed in some GSS RFC than in none at all (to be fair, > I haven't checked that it isn't mentioned in any of the GSS RFCs). I propose this text for this security consideration: Note that the mechanism OID in the pseudo-ASN.1/DER wrapper on initial GSS-API context tokens may not be integrity protected by the actual mechanisms. If a mechanism does not provide integrity protection for the OID in the initial token wrapper and if there exists more than one OID for that mechanism such that the OID used in the wrapper is significant to the mechanism, then there may exist attack against the mechanism where a man in the middle modifies the OID in the mechanism's initial context token wrapper. Since SPNEGO does not provide any additional integrity protection for the mechanism context tokens it transports than any negotiated mechanism would SPNEGO does nothing to prevent this attack. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Jan 4 02:43:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20448; Tue, 4 Jan 2005 02:43:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CljYK-00075x-TF; Tue, 04 Jan 2005 02:56:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CljKp-0003t5-TD; Tue, 04 Jan 2005 02:42:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CljGV-0002ax-C8 for kitten@megatron.ietf.org; Tue, 04 Jan 2005 02:38:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20175 for ; Tue, 4 Jan 2005 02:38:01 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CljSm-0006zp-4g for kitten@ietf.org; Tue, 04 Jan 2005 02:50:47 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 3 Jan 2005 23:37:28 -0800 Received: from red-hub-02.redmond.corp.microsoft.com ([157.54.7.100]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1264); Mon, 3 Jan 2005 23:37:26 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 3 Jan 2005 23:37:27 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Mon, 3 Jan 2005 23:37:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 3 Jan 2005 23:37:26 -0800 Message-ID: Thread-Topic: Review: of draft-ietf-kitten-2478bis-03.txt Thread-Index: AcTyLqkqNtWAfYBOQTOTFl7BzkWCigAAHLBA From: "Liqiang\(Larry\) Zhu" To: "Nicolas Williams" , "Bill Sommerfeld" , , "Russ Housley" , "Sam Hartman" X-OriginalArrivalTime: 04 Jan 2005 07:37:27.0609 (UTC) FILETIME=[3D6C8290:01C4F230] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Subject: RE: Review: of draft-ietf-kitten-2478bis-03.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Thanks, to confirm this attack can be an issue *only* when integrity protection is not provided by the established mechanism context, right? -- Larry =20 -----Original Message----- From: Nicolas Williams [mailto:Nicolas.Williams@sun.com]=20 Sent: Monday, January 03, 2005 11:25 PM To: Liqiang(Larry) Zhu; Bill Sommerfeld; kitten@ietf.org; Russ Housley; Sam Hartman Subject: Re: Review: of draft-ietf-kitten-2478bis-03.txt On Tue, Jan 04, 2005 at 01:02:16AM -0600, Nicolas Williams wrote: > Yet, while I think we can dispose of Bill's thought experiment as=20 > being general to the GSS-API, rather than specific to SPNEGO, I also=20 > think it's still worthy of mention in the security considerations as=20 > I'd rather it be discussed in some GSS RFC than in none at all (to be=20 > fair, I haven't checked that it isn't mentioned in any of the GSS RFCs). I propose this text for this security consideration: Note that the mechanism OID in the pseudo-ASN.1/DER wrapper on initial GSS-API context tokens may not be integrity protected by the actual mechanisms. If a mechanism does not provide integrity protection for the OID in the initial token wrapper and if there exists more than one OID for that mechanism such that the OID used in the wrapper is significant to the mechanism, then there may exist attack against the mechanism where a man in the middle modifies the OID in the mechanism's initial context token wrapper. Since SPNEGO does not provide any additional integrity protection for the mechanism context tokens it transports than any negotiated mechanism would SPNEGO does nothing to prevent this attack. Nico --=20 _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Jan 4 02:50:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20864; Tue, 4 Jan 2005 02:50:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CljeN-0007DK-5y; Tue, 04 Jan 2005 03:02:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CljPH-0005gb-Go; Tue, 04 Jan 2005 02:47:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CljN8-00054d-BB for kitten@megatron.ietf.org; Tue, 04 Jan 2005 02:44:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20510 for ; Tue, 4 Jan 2005 02:44:53 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CljZP-00076p-9U for kitten@ietf.org; Tue, 04 Jan 2005 02:57:38 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 3 Jan 2005 23:44:19 -0800 Received: from red-hub-01.redmond.corp.microsoft.com ([157.54.7.71]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 3 Jan 2005 23:44:17 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1264); Mon, 3 Jan 2005 23:44:17 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Mon, 3 Jan 2005 23:44:17 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 3 Jan 2005 23:44:16 -0800 Message-ID: Thread-Topic: SPNEGO-bis comments/questions Thread-Index: AcTx4R+wRNBmR089Seu4hO2rNMXclAAT4S2A From: "Liqiang\(Larry\) Zhu" To: "Tom Yu" , "Sam Hartman" X-OriginalArrivalTime: 04 Jan 2005 07:44:17.0218 (UTC) FILETIME=[3191E220:01C4F231] X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: RE: SPNEGO-bis comments/questions X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: quoted-printable I could not compile the ASN.1 module with the SIZE constrains using Microsoft ASN.1 compiler. Tom or is there someone else who can verify the correctness of this syntax? SPNEGOASNOneSpec { =20 iso(1) identified-organization(3) dod(6) internet(1) =20 security(5) mechanism(5) snego (2) modules(4) spec2(2) } DEFINITIONS EXPLICIT TAGS ::=3D BEGIN =20 =20 MechType ::=3D OBJECT IDENTIFIER =20 -- OID represents each security mechanism as suggested by -- [RFC2743] =20 MechTypeList ::=3D SEQUENCE OF MechType =20 NegotiationToken ::=3D CHOICE { =20 negTokenInit [0] NegTokenInit, =20 negTokenResp [1] NegTokenResp =20 } =20 NegTokenInit ::=3D SEQUENCE { =20 mechTypes [0] MechTypeList, =20 reqFlags [1] ContextFlags OPTIONAL, -- maintained from RFC 2478 for backward compatibility,=20 -- RECOMMENDED to be left out=20 mechToken [2] OCTET STRING OPTIONAL, =20 mechListMIC [3] OCTET STRING OPTIONAL, ... } =20 NegTokenResp ::=3D SEQUENCE { =20 negState [0] ENUMERATED { =20 accept-completed (0), =20 accept-incomplete (1), =20 reject (2), =20 request-mic (3) =20 } OPTIONAL, -- REQUIRED in the first reply from the target supportedMech [1] MechType OPTIONAL, =20 -- present only in the first reply from the target responseToken [2] OCTET STRING OPTIONAL, =20 mechListMIC [3] OCTET STRING OPTIONAL, ... } =20 ContextFlags ::=3D BIT STRING (SIZE (32)) { =20 delegFlag (0), =20 mutualFlag (1), =20 replayFlag (2), =20 sequenceFlag (3), =20 anonFlag (4), =20 confFlag (5), =20 integFlag (6) =20 }=20 END =20 Also is there any issue w.r.t. allocating the relative-OIDs for the SPNEGO ASN.1 module here? iso(1) identified-organization(3) dod(6) internet(1) =20 security(5) mechanism(5) snego (2) modules(4) spec2(2) -- Larry -----Original Message----- From: Tom Yu [mailto:tlyu@mit.edu]=20 Sent: Monday, January 03, 2005 2:11 PM To: Sam Hartman Cc: Liqiang(Larry) Zhu; Simon Spero; martin.rex@sap.com; kitten@ietf.org Subject: Re: SPNEGO-bis comments/questions >>>>> "Sam" =3D=3D Sam Hartman writes: >>>>> "Tom" =3D=3D Tom Yu writes: Tom> Please recall that applying a size constraint to BIT STRING with=20 Tom> named bits requires that a DER encoder truncate trailing zero bits. Tom> This caused interoperability problems for Kerberos. Sam> doesn't DER already imply this? Oops, yeah, it already does require the truncation, but the size constraint doesn't change the truncation. ---Tom _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Jan 4 03:16:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22481; Tue, 4 Jan 2005 03:16:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Clk4M-0007im-Po; Tue, 04 Jan 2005 03:29:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cljls-0006Gd-VY; Tue, 04 Jan 2005 03:10:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cljjc-00057D-Ux for kitten@megatron.ietf.org; Tue, 04 Jan 2005 03:08:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21972 for ; Tue, 4 Jan 2005 03:08:07 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cljvt-0007YY-Sv for kitten@ietf.org; Tue, 04 Jan 2005 03:20:53 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Jan 2005 00:07:34 -0800 Received: from red-hub-02.redmond.corp.microsoft.com ([157.54.7.100]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Jan 2005 00:07:33 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Jan 2005 00:07:33 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Tue, 4 Jan 2005 00:07:33 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 4 Jan 2005 00:07:32 -0800 Message-ID: Thread-Topic: spnego-bis comments Thread-Index: AcTxvEU+nPXpomBiTmK3zhtEwe4VxwAdXdLg From: "Liqiang\(Larry\) Zhu" To: "Wyllys Ingersoll" , "Ken Raeburn" X-OriginalArrivalTime: 04 Jan 2005 08:07:33.0421 (UTC) FILETIME=[71C58DD0:01C4F234] X-Spam-Score: 0.0 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: RE: spnego-bis comments X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Content-Transfer-Encoding: quoted-printable > > ken Wrote: > > ... (I'm not sure I follow "as a consequence", but I haven't thought > > about it enough, or caught up on the mail) but section 5 says: > Wyllys Ingersoll wrote: > "As a consequence" can probably be edited out of the text without > impacting the meaning. As a consequence signals a deduction. How about s/"As a consequence"/"As the consequence"/? -- larry -----Original Message----- From: kitten-bounces@lists.ietf.org [mailto:kitten-bounces@lists.ietf.org] On Behalf Of Wyllys Ingersoll Sent: Monday, January 03, 2005 9:36 AM To: Ken Raeburn Cc: kitten@ietf.org Subject: Re: spnego-bis comments Ken Raeburn wrote: > Minor: Page 7 first line, "...and it is OPTIONAL to emit a context=20 > level negotiation token", sounds awkward to me (maybe "OPTIONAL=20 > whether to emit" or "emitting...is OPTIONAL"?). Given the aggressive=20 > work by the RFC Editor these days, it will probably get reworded into=20 > active voice, along with a whole bunch of other stuff. Better to do=20 > it first, than give them more work. How about: "In the case of an unsuccessful negotiation, a reject state is returned and emitting a context level negotiation token is OPTIONAL." > > Minor: Page 8, item (c), "...this mechanism token MUST be deposited to > the selected mechanism". The word "deposited" seems odd here, how=20 > about "passed"? Item (d) likewise. And maybe "emit"->"returned" for=20 > outputs of GSS-API functions. I agree, "deposited" is an awkward term here.=20 Also, "emitted" could be changed to "generated" or "returned". > > Minor: Item (d) "until the GSS_S_COMPLETE is returned", drop "the" or=20 > make it "the GSS_S_COMPLETE status" or something. Agreed. > > Section 3.2 "The basic form of the procedure ... is summarized as=20 > follows". Okay, where's the non-basic, non-summary, fully-detailed=20 > description? If this is the fully detailed description, it should=20 > tell me what the target should do if the initial proposed mechanism is > acceptable, but an error happens processing the included token. Near=20 > as I can tell, (c) says I should return GSS_S_COMPLETE and not send a=20 > reply. If the error happens later, then it's clearer what I should=20 > do. I think item 3.2 (IV) should be changed to indicate what to do when no gss_accept_sec_context returns an error state when processing optimistic tokens. Currently, it appears to describe only what to do upon success and ignores the situation where the optimistic token causes an error in mech-specific processing. How about: ... (IV) Otherwise, no additional negotiation tokens are needed from the initiator to establish the context. If no further negotiation is needed and no optimistic mechanism token was included, then GSS_Accept_Sec_Context() should return GSS_S_COMPLETE to the caller and generate a negotiation token with an "accept_complete" state. If an optimistic mechanism token was included and an error occurs processing this token, then the negotiation token result state should be "reject" and GSS_Accept_Sec_Context() should return the corresponding GSSAPI error code to the caller.=20 If the processing of the optimistic token resulted in a GSS_S_CONTINUE_NEEDED state, then the negotiation state should be "accept_incomplete" , the resulting mech token should be generated and included in the output negotiation response token, and GSS_S_CONTINUE_NEEDED should be returned by GSS_Accept_Sec_Context(). If the optimistic token was processed successfully, the negotiation state should be "accept_completed", any resulting mech token should be generated and included in the output negotiation response token, and GSS_S_COMPLETE should be returned by GSS_Accept_Sec_Context(). ... > > Section 3.2 (d) seems to ignore the possibility that the target didn't > like the proposed mechanism and returned a list of different ones. > And what it if returned only ones which weren't supported by the > initiator? I don't think the acceptor can select mechanisms that are not part of the initiators original list. Perhaps I am misunderstanding your=20 question... > Section 4.2.1: > > reqFlags [1] ContextFlags OPTIONAL, > -- maintained from RFC 2478 for backward compatibility, > -- RECOMMENDED to be left out > > reqFlags > > This field, if present, contains the service options that are > requested to establish the context. The context flags SHOULD > be filled in from the req_flags parameter of > > Which is it? Included (and ignored), or omitted? I think it must be included (and ignored) to maintain backwards compat. > > > Section 5, second paragraph: > > as described later in this section, is OPTIONAL. A mechanism is the > acceptor's most preferred mechanism if there is no other mechanism > which, had it been present in the mechanism list, the acceptor would > have preferred over the accepted mechanism. > > "The most preferred mechanism" implies uniqueness. The rest of the > description does not seem to support that. In fact, if my policy is > "use the first mech listed", then isn't that first mech always going > to qualify (assuming I support it at all)? Or is the intent that this > other mech would always be used if it's in the list, regardless of > position or other mechanisms? (In which case, "use the first mech > listed" has no "most preferred mech" at all.) The first mech presented by the initiator is intended to be the initiators most preferred choice. The acceptor may have a different preferred mech (based on local policy). =20 For example: Initiator sends { B, C } Acceptor prefers { A, B, C } The acceptor sees that initiator wants to use B (most preferred) or C. Acceptor's policy states that A would have been best. A MIC must be used in this situation because someone may have tampered with the list and removed "A", so the acceptor must make sure that the initiator really meant "B,C" and not "A,B,C". The Acceptor's rule is: Use the initiators most preferred mech, unless=20 I have a different preference that was not the same as the intiator's, in which case a MIC exchange must occur to make sure that the exchange was not tampered with. > > When is NegTokenInit.mechListMIC used? Section 3 seems to indicate > that the MIC tokens aren't exchanged until *after* GSS_S_COMPLETE has > been returned on both sides by the agreed-upon mechanism, and aren't > we sure to be using NegTokenResp at that point? (In Section 5 it > appears that it's possible to use mechListMIC in NegTokenInit.) > I think that NegTokenInit is always sent by the initiator. So, if the acceptor returns one of the states that requests a MIC exchange, then the initiator will send another NegTokenInit message with a mechListMIC. > MIC requirements: > > influence the acceptor's choice of mechanism. As discussed in > Section 5, if there are mechanisms that if present in the initiator's > list of mechanisms might be preferred by the acceptor to the > initiator's preferred mechanism, the acceptor MUST demand the MIC > token exchange. As a consequence, acceptors MUST demand the MIC > token exchange if they support negotiation of attributes not > available in the initiator's preferred mechanism regardless of > whether the initiator actually requested these attributes. > > ... (I'm not sure I follow "as a consequence", but I haven't thought > about it enough, or caught up on the mail) but section 5 says: "As a consequence" can probably be edited out of the text without impacting the meaning. > > If the mechanism selected by the negotiation does not support > integrity protection, then no mechlistMIC token is used. > > ... so what if the acceptor supports this attribute negotiation but > they agree on a mechanism without integrity protection? In this case there cannot be a MIC exchange. -Wyllys _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Jan 4 03:18:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22546; Tue, 4 Jan 2005 03:18:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Clk5Y-0007kJ-Pz; Tue, 04 Jan 2005 03:30:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CljsJ-00009X-4O; Tue, 04 Jan 2005 03:17:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cljn0-0006iU-PE for kitten@megatron.ietf.org; Tue, 04 Jan 2005 03:11:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22177 for ; Tue, 4 Jan 2005 03:11:37 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CljzH-0007dF-Q3 for kitten@ietf.org; Tue, 04 Jan 2005 03:24:23 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1264); Tue, 4 Jan 2005 00:10:57 -0800 Received: from red-hub-02.redmond.corp.microsoft.com ([157.54.7.100]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1264); Tue, 4 Jan 2005 00:11:02 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Jan 2005 00:11:03 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Tue, 4 Jan 2005 00:11:03 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 4 Jan 2005 00:11:02 -0800 Message-ID: Thread-Topic: spnego-bis comments Thread-Index: AcTx4BWgMX0DF57ZTSGMMfBJxaKcsQAVK1rA From: "Liqiang\(Larry\) Zhu" To: "Nicolas Williams" , "Wyllys Ingersoll" X-OriginalArrivalTime: 04 Jan 2005 08:11:03.0318 (UTC) FILETIME=[EEE14B60:01C4F234] X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org, Ken Raeburn Subject: RE: spnego-bis comments X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Content-Transfer-Encoding: quoted-printable Nicolas Williams wrote: > As to Ken's question, I'm not sure, but I think the initiator can use it in optimistic mech token cases where no further=20 > mech tokens are expected (i.e., one-mech-token exchanges, like krb5 w/o mutual auth) to request that the acceptor respond=20 > with with a negTokenResp containing a mechListMIC. Larry? Ken Raeburn wrote: > When is NegTokenInit.mechListMIC used? Section 3 seems to indicate that the MIC tokens aren't exchanged until *after*=20 > GSS_S_COMPLETE has been returned on both sides by the agreed-upon mechanism, and aren't we sure to be using NegTokenResp > at that point? (In Section 5 it appears that it's possible to use mechListMIC in NegTokenInit.) NegTokenInit.mechListMIC is used according to 5 c). Note that NegTokenInit.mechListMIC is always OPTIONAL according to 5 c) but the current text allows implementers to promote the "OPTIONAL" NegTokenInit.mechListMIC to "REQUIRED". Ken, does this answer your question? -- larry=20 -----Original Message----- From: kitten-bounces@lists.ietf.org [mailto:kitten-bounces@lists.ietf.org] On Behalf Of Nicolas Williams Sent: Monday, January 03, 2005 1:02 PM To: Wyllys Ingersoll Cc: kitten@ietf.org; Ken Raeburn Subject: Re: spnego-bis comments On Mon, Jan 03, 2005 at 12:36:09PM -0500, Wyllys Ingersoll wrote: > Ken Raeburn wrote: > >Section 3.2 (d) seems to ignore the possibility that the target=20 > >didn't like the proposed mechanism and returned a list of different ones. > >And what it if returned only ones which weren't supported by the=20 > >initiator? >=20 >=20 > I don't think the acceptor can select mechanisms that are not part of=20 > the initiators original list. Perhaps I am misunderstanding your=20 > question... Right. The initiator can trivially detect that UNLESS a situation such as brought up by Bill Sommerfeld in his thought experiment exists. > >Section 4.2.1: > > > > reqFlags [1] ContextFlags OPTIONAL, > > -- maintained from RFC 2478 for backward compatibility, > > -- RECOMMENDED to be left out > > > > reqFlags > > > > This field, if present, contains the service options that are > > requested to establish the context. The context flags SHOULD > > be filled in from the req_flags parameter of > > > >Which is it? Included (and ignored), or omitted? >=20 > I think it must be included (and ignored) to maintain backwards=20 > compat. I disagree. It SHOULD NOT be present in the token, and acceptors MUST ignore it. It's ok to leave it out since it's been OPTIONAL all along. And acceptors ignore it nowadays anyways -- what else can they do with it? After all, GSS_Accept_sec_context() does not have a flags input parameter. > > > > > >Section 5, second paragraph: > > > > as described later in this section, is OPTIONAL. A mechanism is the > > acceptor's most preferred mechanism if there is no other mechanism > > which, had it been present in the mechanism list, the acceptor would > > have preferred over the accepted mechanism. > > > >"The most preferred mechanism" implies uniqueness. The rest of the=20 > >description does not seem to support that. In fact, if my policy is=20 > >"use the first mech listed", then isn't that first mech always going=20 > >to qualify (assuming I support it at all)? Or is the intent that=20 > >this other mech would always be used if it's in the list, regardless=20 > >of position or other mechanisms? (In which case, "use the first mech > >listed" has no "most preferred mech" at all.) To me the intent is clear that: a) the mechList is a list of OIDS ordered by initiator preference, from most preferred to least preferred, and b) that the acceptor may or may not have a preference policy of its own, which may be expressed through an abstraction more complex than a list, such that for some initiator's mechLists the acceptor will insist on a mechListMIC exchange. > >When is NegTokenInit.mechListMIC used? Section 3 seems to indicate=20 > >that the MIC tokens aren't exchanged until *after* GSS_S_COMPLETE has > >been returned on both sides by the agreed-upon mechanism, and aren't=20 > >we sure to be using NegTokenResp at that point? (In Section 5 it=20 > >appears that it's possible to use mechListMIC in NegTokenInit.) > > > I think that NegTokenInit is always sent by the initiator. So, if the > acceptor returns one of the states that requests a MIC exchange, then=20 > the initiator will send another NegTokenInit message with a mechListMIC. NegTokenInit is to be used only for the first SPNEGO token, NegTokenResp is to be used for all other tokens. As to Ken's question, I'm not sure, but I think the initiator can use it in optimistic mech token cases where no further mech tokens are expected (i.e., one-mech-token exchanges, like krb5 w/o mutual auth) to request that the acceptor respond with with a negTokenResp containing a mechListMIC. Larry? > > If the mechanism selected by the negotiation does not support > > integrity protection, then no mechlistMIC token is used. > > > >... so what if the acceptor supports this attribute negotiation but=20 > >they agree on a mechanism without integrity protection? This doesn't make sense. Integrity protection and other such context attributes aren't actually negotiated by SPNEGO, NegTokenInit.ContextFlags notwithstanding (see above). > In this case there cannot be a MIC exchange. Right, and there is enough security considerations on this anyways. And, and as has been pointed out, generally speaking negotiation of any security mechanisms that do not support integrity protection means that the negotiation cannot be secure against downgrade attacks. Nico --=20 _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Jan 4 08:14:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09373; Tue, 4 Jan 2005 08:14:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cloif-0004uC-O3; Tue, 04 Jan 2005 08:27:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CloUH-0004KF-Hr; Tue, 04 Jan 2005 08:12:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CloQf-00036W-M6 for kitten@megatron.ietf.org; Tue, 04 Jan 2005 08:08:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09097 for ; Tue, 4 Jan 2005 08:08:52 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Clod2-0004nG-3U for kitten@ietf.org; Tue, 04 Jan 2005 08:21:40 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Jan 2005 05:08:22 -0800 Received: from red-hub-01.redmond.corp.microsoft.com ([157.54.7.71]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Jan 2005 05:08:27 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Tue, 4 Jan 2005 05:08:20 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Tue, 4 Jan 2005 05:08:20 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 4 Jan 2005 05:08:19 -0800 Message-ID: Thread-Topic: spnego-bis comments Thread-Index: AcTkgem2a466Uc2zRAStS7DfXP8z4QNs2TcQ From: "Liqiang\(Larry\) Zhu" To: "Ken Raeburn" , X-OriginalArrivalTime: 04 Jan 2005 13:08:20.0421 (UTC) FILETIME=[769F3750:01C4F25E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Content-Transfer-Encoding: quoted-printable Subject: RE: spnego-bis comments X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Content-Transfer-Encoding: quoted-printable Ken Raeburn wrote: > Section 3.2 "The basic form of the procedure ... is summarized as follows". =20 > Okay, where's the non-basic, non-summary,=20 > fully-detailed description? If this is the fully detailed description, it should=20 > tell me what the target should do if=20 > the initial proposed mechanism is acceptable, but an error happens processing=20 > the included token. Near as I can tell,=20 > (c) says I should return GSS_S_COMPLETE and not send a reply. If the error=20 > happens later, then it's clearer what I=20 > should do. The error conditions are left out for brevity. It is the basic form because it does not describe, for example, what happens if the accepted mechanism does not support integrity protection; it is not fully-detailed because it does not describe error conditions. > ... so what if the acceptor supports this attribute negotiation but they agree on a=20 > mechanism without integrity protection? The negotiation can not be protected in that case. -- Larry -----Original Message----- From: kitten-bounces@lists.ietf.org [mailto:kitten-bounces@lists.ietf.org] On Behalf Of Ken Raeburn Sent: Friday, December 17, 2004 12:39 PM To: kitten@ietf.org Subject: spnego-bis comments Sorry these are so late, I've been working on my 48-hours, important bug fixes, etc. I probably should've spent more time going over the WG email before reviewing this, but.... Section 1, the introduction ought not to have requirements indications, at least not to this degree. I could see maybe an introduction saying under circumstances X or Y an implementation MAY/SHOULD/MUST follow this RFC, but not for how parts of the protocol defined in the RFC are to be implemented. The OID shouldn't be defined here either; probably in section 4 or maybe 4.2. Minor: Page 7 first line, "...and it is OPTIONAL to emit a context level negotiation token", sounds awkward to me (maybe "OPTIONAL whether to emit" or "emitting...is OPTIONAL"?). Given the aggressive work by the RFC Editor these days, it will probably get reworded into active voice, along with a whole bunch of other stuff. Better to do it first, than give them more work. Minor: Page 8, item (c), "...this mechanism token MUST be deposited to the selected mechanism". The word "deposited" seems odd here, how about "passed"? Item (d) likewise. And maybe "emit"->"returned" for outputs of GSS-API functions. Minor: Item (d) "until the GSS_S_COMPLETE is returned", drop "the" or make it "the GSS_S_COMPLETE status" or something. Section 3.1: Might be obvious, but it may be worth noting that the SPNEGO OID itself SHOULD (MUST?) NOT be included in the list of mechanisms. Section 3.2 "The basic form of the procedure ... is summarized as follows". Okay, where's the non-basic, non-summary, fully-detailed description? If this is the fully detailed description, it should tell me what the target should do if the initial proposed mechanism is acceptable, but an error happens processing the included token. Near as I can tell, (c) says I should return GSS_S_COMPLETE and not send a reply. If the error happens later, then it's clearer what I should do. Section 3.2 (d) seems to ignore the possibility that the target didn't like the proposed mechanism and returned a list of different ones. And what it if returned only ones which weren't supported by the initiator? In fact, the word "error" occurs only once in the document, and that's in the introduction. ("Fail" occurs a bit more -- introduction, security considerations, and appendices. But the main body of the spec can't address just the success cases.) Q: Does GSSAPI allow for a state where authentication has essentially succeeded, but one has the option of sending one more mech token and the other can't independently determine whether the it will do so? (I'm wondering if that would affect the scheduling of the MIC token transmission, but haven't looked into it yet.) Section 4.2.1: reqFlags [1] ContextFlags OPTIONAL, -- maintained from RFC 2478 for backward compatibility, -- RECOMMENDED to be left out reqFlags This field, if present, contains the service options that are requested to establish the context. The context flags SHOULD be filled in from the req_flags parameter of Which is it? Included (and ignored), or omitted? Section 5, second paragraph: as described later in this section, is OPTIONAL. A mechanism is the acceptor's most preferred mechanism if there is no other mechanism which, had it been present in the mechanism list, the acceptor would have preferred over the accepted mechanism. "The most preferred mechanism" implies uniqueness. The rest of the description does not seem to support that. In fact, if my policy is "use the first mech listed", then isn't that first mech always going to qualify (assuming I support it at all)? Or is the intent that this other mech would always be used if it's in the list, regardless of position or other mechanisms? (In which case, "use the first mech listed" has no "most preferred mech" at all.) When is NegTokenInit.mechListMIC used? Section 3 seems to indicate that the MIC tokens aren't exchanged until *after* GSS_S_COMPLETE has been returned on both sides by the agreed-upon mechanism, and aren't we sure to be using NegTokenResp at that point? (In Section 5 it appears that it's possible to use mechListMIC in NegTokenInit.) Section 6: A final RFC should probably not talk too much about planned work in specific working groups. MIC requirements: influence the acceptor's choice of mechanism. As discussed in Section 5, if there are mechanisms that if present in the initiator's list of mechanisms might be preferred by the acceptor to the initiator's preferred mechanism, the acceptor MUST demand the MIC token exchange. As a consequence, acceptors MUST demand the MIC token exchange if they support negotiation of attributes not available in the initiator's preferred mechanism regardless of whether the initiator actually requested these attributes. ... (I'm not sure I follow "as a consequence", but I haven't thought about it enough, or caught up on the mail) but section 5 says: If the mechanism selected by the negotiation does not support integrity protection, then no mechlistMIC token is used. ... so what if the acceptor supports this attribute negotiation but they agree on a mechanism without integrity protection? Section 7: The security considerations do need work, as Bill noted. I'd like to see discussion of Bill's thought-experiment case, where the two parties see different OIDs, each thinking they're negotiating for their preferred mech, but in reality they're different mechs with similar-enough initial messages. Minor: I don't think Sections demand page breaks. A bunch of vertical space is wasted just to get sections 2, 6, 7, 8, 9, and 10 to start at the top of their pages. Section 8 (one-line header plus one line of content) is especially wasteful. Minor: Appendix B starts off indented too far by three columns. Appendix B "address the problems in RFC 2478": Since there's been no discussion of what "the problems" are, I'd drop the word "the". Should we say "Microsoft Windows 2000/..."? That's it for now. Ken _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Jan 4 08:17:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09658; Tue, 4 Jan 2005 08:17:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClolT-0004yr-7Y; Tue, 04 Jan 2005 08:30:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CloUH-0004KK-MU; Tue, 04 Jan 2005 08:12:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CloQv-000375-CS for kitten@megatron.ietf.org; Tue, 04 Jan 2005 08:09:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09133 for ; Tue, 4 Jan 2005 08:09:08 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClodG-0004ns-36 for kitten@ietf.org; Tue, 04 Jan 2005 08:21:56 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Jan 2005 05:08:47 -0800 Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Jan 2005 05:08:41 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Jan 2005 05:08:41 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Tue, 4 Jan 2005 05:08:33 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 4 Jan 2005 05:08:33 -0800 Message-ID: Thread-Topic: spnego-bis comments Thread-Index: AcTx4BWgMX0DF57ZTSGMMfBJxaKcsQAUwGOw From: "Liqiang\(Larry\) Zhu" To: "Nicolas Williams" , "Wyllys Ingersoll" X-OriginalArrivalTime: 04 Jan 2005 13:08:33.0881 (UTC) FILETIME=[7EA50C90:01C4F25E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org, Ken Raeburn Subject: RE: spnego-bis comments X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Content-Transfer-Encoding: quoted-printable Nicolas Williams wrote: > I disagree. It SHOULD NOT be present in the token, and acceptors MUST ignore it. > It's ok to leave it out since it's been OPTIONAL all along. And acceptors=20 > ignore it nowadays anyways -- what else can they=20 > do with it? > After all, GSS_Accept_sec_context() does not have a flags input parameter. I agree. -----Original Message----- From: kitten-bounces@lists.ietf.org [mailto:kitten-bounces@lists.ietf.org] On Behalf Of Nicolas Williams Sent: Monday, January 03, 2005 1:02 PM To: Wyllys Ingersoll Cc: kitten@ietf.org; Ken Raeburn Subject: Re: spnego-bis comments On Mon, Jan 03, 2005 at 12:36:09PM -0500, Wyllys Ingersoll wrote: > Ken Raeburn wrote: > >Section 3.2 (d) seems to ignore the possibility that the target=20 > >didn't like the proposed mechanism and returned a list of different ones. > >And what it if returned only ones which weren't supported by the=20 > >initiator? >=20 >=20 > I don't think the acceptor can select mechanisms that are not part of=20 > the initiators original list. Perhaps I am misunderstanding your=20 > question... Right. The initiator can trivially detect that UNLESS a situation such as brought up by Bill Sommerfeld in his thought experiment exists. > >Section 4.2.1: > > > > reqFlags [1] ContextFlags OPTIONAL, > > -- maintained from RFC 2478 for backward compatibility, > > -- RECOMMENDED to be left out > > > > reqFlags > > > > This field, if present, contains the service options that are > > requested to establish the context. The context flags SHOULD > > be filled in from the req_flags parameter of > > > >Which is it? Included (and ignored), or omitted? >=20 > I think it must be included (and ignored) to maintain backwards=20 > compat. I disagree. It SHOULD NOT be present in the token, and acceptors MUST ignore it. It's ok to leave it out since it's been OPTIONAL all along. And acceptors ignore it nowadays anyways -- what else can they do with it? After all, GSS_Accept_sec_context() does not have a flags input parameter. > > > > > >Section 5, second paragraph: > > > > as described later in this section, is OPTIONAL. A mechanism is the > > acceptor's most preferred mechanism if there is no other mechanism > > which, had it been present in the mechanism list, the acceptor would > > have preferred over the accepted mechanism. > > > >"The most preferred mechanism" implies uniqueness. The rest of the=20 > >description does not seem to support that. In fact, if my policy is=20 > >"use the first mech listed", then isn't that first mech always going=20 > >to qualify (assuming I support it at all)? Or is the intent that=20 > >this other mech would always be used if it's in the list, regardless=20 > >of position or other mechanisms? (In which case, "use the first mech > >listed" has no "most preferred mech" at all.) To me the intent is clear that: a) the mechList is a list of OIDS ordered by initiator preference, from most preferred to least preferred, and b) that the acceptor may or may not have a preference policy of its own, which may be expressed through an abstraction more complex than a list, such that for some initiator's mechLists the acceptor will insist on a mechListMIC exchange. > >When is NegTokenInit.mechListMIC used? Section 3 seems to indicate=20 > >that the MIC tokens aren't exchanged until *after* GSS_S_COMPLETE has > >been returned on both sides by the agreed-upon mechanism, and aren't=20 > >we sure to be using NegTokenResp at that point? (In Section 5 it=20 > >appears that it's possible to use mechListMIC in NegTokenInit.) > > > I think that NegTokenInit is always sent by the initiator. So, if the > acceptor returns one of the states that requests a MIC exchange, then=20 > the initiator will send another NegTokenInit message with a mechListMIC. NegTokenInit is to be used only for the first SPNEGO token, NegTokenResp is to be used for all other tokens. As to Ken's question, I'm not sure, but I think the initiator can use it in optimistic mech token cases where no further mech tokens are expected (i.e., one-mech-token exchanges, like krb5 w/o mutual auth) to request that the acceptor respond with with a negTokenResp containing a mechListMIC. Larry? > > If the mechanism selected by the negotiation does not support > > integrity protection, then no mechlistMIC token is used. > > > >... so what if the acceptor supports this attribute negotiation but=20 > >they agree on a mechanism without integrity protection? This doesn't make sense. Integrity protection and other such context attributes aren't actually negotiated by SPNEGO, NegTokenInit.ContextFlags notwithstanding (see above). > In this case there cannot be a MIC exchange. Right, and there is enough security considerations on this anyways. And, and as has been pointed out, generally speaking negotiation of any security mechanisms that do not support integrity protection means that the negotiation cannot be secure against downgrade attacks. Nico --=20 _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Jan 4 10:29:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19205; Tue, 4 Jan 2005 10:29:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClqpN-0007ZN-7p; Tue, 04 Jan 2005 10:42:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Clqbw-0008Ui-Un; Tue, 04 Jan 2005 10:28:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Clqah-0007rx-Hd for kitten@megatron.ietf.org; Tue, 04 Jan 2005 10:27:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19061 for ; Tue, 4 Jan 2005 10:27:21 -0500 (EST) Received: from luminous.mit.edu ([18.101.1.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Clqn2-0007WH-DL for kitten@ietf.org; Tue, 04 Jan 2005 10:40:11 -0500 Received: by luminous.mit.edu (Postfix, from userid 1000) id 367B176A97; Tue, 4 Jan 2005 10:27:14 -0500 (EST) To: "Liqiang(Larry) Zhu" References: <20050104070215.GS184117@binky.central.sun.com> <20050104072448.GT184117@binky.central.sun.com> From: Sam Hartman Date: Tue, 04 Jan 2005 10:27:13 -0500 In-Reply-To: <20050104072448.GT184117@binky.central.sun.com> (Nicolas Williams's message of "Tue, 4 Jan 2005 01:24:48 -0600") Message-ID: <87zmzp1age.fsf@luminous.mit.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: kitten@ietf.org, Russ Housley Subject: Re: Review: of draft-ietf-kitten-2478bis-03.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Tue, Jan 04, 2005 at 01:02:16AM -0600, Nicolas Nicolas> Williams wrote: >> Yet, while I think we can dispose of Bill's thought experiment >> as being general to the GSS-API, rather than specific to >> SPNEGO, I also think it's still worthy of mention in the >> security considerations as I'd rather it be discussed in some >> GSS RFC than in none at all (to be fair, I haven't checked that >> it isn't mentioned in any of the GSS RFCs). Your text is overly specific. The problem can also happen if one mechanism's tokens can be converted into the tokens of another mechanism. I think you are focusing too much on the OID, although I agree integrity-protecting the OID does fix the problem. Nicolas> I propose this text for this security consideration: Nicolas> Note that the mechanism OID in the pseudo-ASN.1/DER Nicolas> wrapper on initial GSS-API context tokens may not be Nicolas> integrity protected by the actual mechanisms. If a Nicolas> mechanism does not provide integrity protection for the How about and if an attacker can convert the token of that mechanism into the token of some other mechanism by making structural changes to the token. Note that if the OID changes, the mechanism changes by definition. Nicolas> OID in the initial token wrapper and if there exists more Nicolas> than one OID for that mechanism such that the OID used in Nicolas> the wrapper is significant to the mechanism, then there Nicolas> may exist attack against the mechanism where a man in the Nicolas> middle modifies the OID in the mechanism's initial Nicolas> context token wrapper. Since SPNEGO does not provide any Nicolas> additional integrity protection for the mechanism context Nicolas> tokens it transports than any negotiated mechanism would Nicolas> SPNEGO does nothing to prevent this attack. Nicolas> Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Jan 4 10:32:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19379; Tue, 4 Jan 2005 10:32:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClqsE-0007cN-Tj; Tue, 04 Jan 2005 10:45:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Clqeo-0001GQ-V1; Tue, 04 Jan 2005 10:31:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Clqdv-0000rK-4o for kitten@megatron.ietf.org; Tue, 04 Jan 2005 10:30:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19270 for ; Tue, 4 Jan 2005 10:30:41 -0500 (EST) Received: from luminous.mit.edu ([18.101.1.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClqqI-0007aN-DR for kitten@ietf.org; Tue, 04 Jan 2005 10:43:31 -0500 Received: by luminous.mit.edu (Postfix, from userid 1000) id 5D54C7681E; Tue, 4 Jan 2005 10:30:40 -0500 (EST) To: "Liqiang(Larry) Zhu" References: From: Sam Hartman Date: Tue, 04 Jan 2005 10:30:39 -0500 In-Reply-To: (Liqiang Zhu's message of "Mon, 3 Jan 2005 23:37:26 -0800") Message-ID: <87vfad1aao.fsf@luminous.mit.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: kitten@ietf.org, Russ Housley , Nicolas Williams Subject: Re: Review: of draft-ietf-kitten-2478bis-03.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a >>>>> "Liqiang(Larry)" == Liqiang(Larry) Zhu writes: Liqiang(Larry)> Thanks, to confirm this attack can be an issue Liqiang(Larry)> *only* when integrity protection is not provided Liqiang(Larry)> by the established mechanism context, right? Not really. The general attack is independent of whether the mechanism provides per-message integrity and has a lot more to do with whether you can manipulate the ciphertext of one mechanism into valid ciphertext for another mechanism. It's in the same class as unauthenticated plaintext attacks discussed in krb-wg. There is an interesting relation to SPNEGO in that if SPNEGO happens to exchange MICs and SPNEGO is actually used, the attack is defeated. I do believe addressing this as a security consideration is appropriate. I don't know of mechanisms today that have structurally similar ciphertext and I believe that we can simply avoid standardizing such mechanisms in the future. --Sam _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Jan 4 10:46:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20627; Tue, 4 Jan 2005 10:46:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Clr5y-0007tU-L8; Tue, 04 Jan 2005 10:59:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Clqqt-00050o-JL; Tue, 04 Jan 2005 10:44:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Clqkx-00032V-J4 for kitten@megatron.ietf.org; Tue, 04 Jan 2005 10:37:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20042 for ; Tue, 4 Jan 2005 10:37:57 -0500 (EST) Received: from luminous.mit.edu ([18.101.1.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Clqx8-0007j4-ME for kitten@ietf.org; Tue, 04 Jan 2005 10:50:35 -0500 Received: by luminous.mit.edu (Postfix, from userid 1000) id 6D40A76A97; Tue, 4 Jan 2005 10:37:44 -0500 (EST) To: "Liqiang(Larry) Zhu" References: From: Sam Hartman Date: Tue, 04 Jan 2005 10:37:44 -0500 In-Reply-To: (Liqiang Zhu's message of "Mon, 3 Jan 2005 22:21:53 -0800") Message-ID: <87r7l119yv.fsf@luminous.mit.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: kitten@ietf.org, Russ Housley Subject: Re: Review: of draft-ietf-kitten-2478bis-03.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 >>>>> "Liqiang(Larry)" == Liqiang(Larry) Zhu writes: Liqiang(Larry)> 5) > This is very ambiguous as it's not clear Liqiang(Larry)> whether it is forbidding termination in this case Liqiang(Larry)> or merely allowing > >> continuation. Liqiang(Larry)> The normative description is in section 5. >> If the receiver detects an alteration, but the alteration had >> no material impact on the negotiation, the receiver MAY opt to >> continue the session. Liqiang(Larry)> This is incorrect: no attempt is made to detect Liqiang(Larry)> alterations when it is safe to omit the meclistMIC Liqiang(Larry)> tokens and if an alteration is detected, the Liqiang(Larry)> current protocol requires the negotiation to fail. I actually like text similar to what's there to stay in the document. Let's see if we can come up with wording that is more clear. How about: Alterations to SPNEGO messages that do not affect the results of the negotiation are not always detected. For example, an attacker could add the OID of some mechanism to the end of the initiator's list of proposed mechanisms. If the rules in section 5 do not require MICs be exchanged for the negotiation in question, the initiator will not discover that the message is altered. Since this can only happen in cases where the alteration has no affect no the result of the negotiation, the attacker does not gain an advantage by making the alteration. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Jan 4 11:56:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26001; Tue, 4 Jan 2005 11:56:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClsBW-00013l-6j; Tue, 04 Jan 2005 12:09:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClrxX-0007R0-Ld; Tue, 04 Jan 2005 11:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Clrwg-00076e-Hh for kitten@megatron.ietf.org; Tue, 04 Jan 2005 11:54:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25845 for ; Tue, 4 Jan 2005 11:54:08 -0500 (EST) Received: from cathode-dark-space.mit.edu ([18.18.1.96]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cls92-00010e-Iz for kitten@ietf.org; Tue, 04 Jan 2005 12:06:59 -0500 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9) id j04Gs6bK007915; Tue, 4 Jan 2005 11:54:06 -0500 (EST) To: "Liqiang\(Larry\) Zhu" References: From: Tom Yu Date: Tue, 04 Jan 2005 11:54:06 -0500 In-Reply-To: (Liqiang Zhu's message of "Mon, 3 Jan 2005 23:44:16 -0800") Message-ID: Lines: 29 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: kitten@ietf.org, Sam Hartman Subject: Re: SPNEGO-bis comments/questions X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 >>>>> "lzhu" == Liqiang\(Larry\) Zhu writes: lzhu> I could not compile the ASN.1 module with the SIZE constrains using lzhu> Microsoft ASN.1 compiler. lzhu> ContextFlags ::= BIT STRING (SIZE (32)) { lzhu> delegFlag (0), lzhu> mutualFlag (1), lzhu> replayFlag (2), lzhu> sequenceFlag (3), lzhu> anonFlag (4), lzhu> confFlag (5), lzhu> integFlag (6) lzhu> } Constraints, including size constraints, go after a type. (There's an exception for SEQUENCE OF and SET OF but we won't worry about that.) The named bit list is part of the BIT STRING type. Try moving the size constraint so that it follows the named bit list. lzhu> Also is there any issue w.r.t. allocating the relative-OIDs for the lzhu> SPNEGO ASN.1 module here? lzhu> iso(1) identified-organization(3) dod(6) internet(1) lzhu> security(5) mechanism(5) snego (2) modules(4) spec2(2) I'm not sure what you're asking. ---Tom _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Jan 4 12:17:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27564; Tue, 4 Jan 2005 12:17:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClsVw-0001YY-UT; Tue, 04 Jan 2005 12:30:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cls3b-0002Id-HS; Tue, 04 Jan 2005 12:01:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cls1H-0001cs-7i for kitten@megatron.ietf.org; Tue, 04 Jan 2005 11:58:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26124 for ; Tue, 4 Jan 2005 11:58:52 -0500 (EST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClsDd-00016C-M0 for kitten@ietf.org; Tue, 04 Jan 2005 12:11:44 -0500 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j04Gwopv018981 for ; Tue, 4 Jan 2005 08:58:51 -0800 (PST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j04GwnJf002704 for ; Tue, 4 Jan 2005 09:58:50 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id j04Gvh1P249917; Tue, 4 Jan 2005 10:57:43 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id j04GvfKl249916; Tue, 4 Jan 2005 10:57:41 -0600 (CST) Date: Tue, 4 Jan 2005 10:57:41 -0600 From: Nicolas Williams To: "Liqiang(Larry) Zhu" Message-ID: <20050104165741.GU184117@binky.central.sun.com> Mail-Followup-To: "Liqiang(Larry) Zhu" , Bill Sommerfeld , kitten@ietf.org, Russ Housley , Sam Hartman References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Cc: kitten@ietf.org, Sam Hartman , Russ Housley Subject: Re: Review: of draft-ietf-kitten-2478bis-03.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de On Mon, Jan 03, 2005 at 11:37:26PM -0800, Liqiang(Larry) Zhu wrote: > Thanks, to confirm this attack can be an issue *only* when integrity > protection is not provided by the established mechanism context, right? No. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Jan 4 12:38:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00736; Tue, 4 Jan 2005 12:38:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClsqC-0002HO-0Q; Tue, 04 Jan 2005 12:51:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Clsc9-0003cr-Cv; Tue, 04 Jan 2005 12:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClsXX-0001hN-Ve for kitten@megatron.ietf.org; Tue, 04 Jan 2005 12:32:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00097 for ; Tue, 4 Jan 2005 12:32:13 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Clsju-00027H-4N for kitten@ietf.org; Tue, 04 Jan 2005 12:45:05 -0500 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j04HW9dt006758 for ; Tue, 4 Jan 2005 10:32:09 -0700 (MST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j04HW9jW017759 for ; Tue, 4 Jan 2005 10:32:09 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id j04HV263249934; Tue, 4 Jan 2005 11:31:02 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id j04HV2W3249933; Tue, 4 Jan 2005 11:31:02 -0600 (CST) Date: Tue, 4 Jan 2005 11:31:02 -0600 From: Nicolas Williams To: kitten@ietf.org Message-ID: <20050104173102.GV184117@binky.central.sun.com> Mail-Followup-To: kitten@ietf.org, "Liqiang(Larry) Zhu" , Russ Housley References: <20050104070215.GS184117@binky.central.sun.com> <20050104072448.GT184117@binky.central.sun.com> <87zmzp1age.fsf@luminous.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87zmzp1age.fsf@luminous.mit.edu> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: "Liqiang\(Larry\) Zhu" , Russ Housley Subject: Re: Review: of draft-ietf-kitten-2478bis-03.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 On Tue, Jan 04, 2005 at 10:27:13AM -0500, Sam Hartman wrote: > >>>>> "Nicolas" == Nicolas Williams writes: > > Nicolas> On Tue, Jan 04, 2005 at 01:02:16AM -0600, Nicolas > Nicolas> Williams wrote: > >> Yet, while I think we can dispose of Bill's thought experiment > >> as being general to the GSS-API, rather than specific to > >> SPNEGO, I also think it's still worthy of mention in the > >> security considerations as I'd rather it be discussed in some > >> GSS RFC than in none at all (to be fair, I haven't checked that > >> it isn't mentioned in any of the GSS RFCs). > > Your text is overly specific. The problem can also happen if one > mechanism's tokens can be converted into the tokens of another > mechanism. I think you are focusing too much on the OID, although I > agree integrity-protecting the OID does fix the problem. Right. Second try: Note that where there exist multiple mechanisms with similar context tokens, but different semantics, such that some or all of the mechanisms' context tokens can be easily altered so that one mechanism's context tokens may pass for another of the similar mechanism's context tokens, then there may exist downgrade or similar attacks. For example, if a given family of mechanisms uses the same context token syntax for two or more variants and depends on the OID in the initial token's pseudo-ASN.1/DER wrapper, but does not provide integrity protection for that OID, then there may exist an attack against those mechanisms. SPNEGO does not generally defeat such attacks. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Jan 4 13:28:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04986; Tue, 4 Jan 2005 13:28:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cltcm-0003Xf-7U; Tue, 04 Jan 2005 13:41:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CltH9-0004DI-IP; Tue, 04 Jan 2005 13:19:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CltEX-0002c5-H1 for kitten@megatron.ietf.org; Tue, 04 Jan 2005 13:16:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03883 for ; Tue, 4 Jan 2005 13:16:38 -0500 (EST) Received: from smtpsrv12.isis.unc.edu ([152.2.1.243] helo=smtp.unc.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CltQu-0003C6-50 for kitten@ietf.org; Tue, 04 Jan 2005 13:29:31 -0500 Received: from [152.2.246.1] (hillary.oit.unc.edu [152.2.246.1]) by smtp.unc.edu (8.12.9/8.12.9) with ESMTP id j04IGRI7008336; Tue, 4 Jan 2005 13:16:27 -0500 (EST) Message-ID: <41DADD82.9000806@unc.edu> Date: Tue, 04 Jan 2005 13:16:34 -0500 From: Simon Spero User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en 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: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, Sam Hartman Subject: Re: SPNEGO-bis comments/questions X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Liqiang(Larry) Zhu wrote: >Also is there any issue w.r.t. allocating the relative-OIDs for the >SPNEGO ASN.1 module here? > >iso(1) identified-organization(3) dod(6) internet(1) > security(5) mechanism(5) snego (2) modules(4) spec2(2) > > > Should that read snego or spnego? Who owns 1.3.6.1.5.5.2? If it's been delegated to kitten (SPNEKO?) then it's fair game. Simon _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Jan 4 16:27:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24175; Tue, 4 Jan 2005 16:27:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClwQ1-0000uv-WA; Tue, 04 Jan 2005 16:40:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Clw5t-0008Mm-5X; Tue, 04 Jan 2005 16:19:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClvtI-0004Or-CR for kitten@megatron.ietf.org; Tue, 04 Jan 2005 16:06:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19689 for ; Tue, 4 Jan 2005 16:06:54 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Clw5h-0007lg-9c for kitten@ietf.org; Tue, 04 Jan 2005 16:19:47 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Jan 2005 13:06:23 -0800 Received: from red-hub-03.redmond.corp.microsoft.com ([157.54.2.25]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Jan 2005 13:06:14 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1264); Tue, 4 Jan 2005 13:06:07 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Tue, 4 Jan 2005 13:06:20 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 4 Jan 2005 13:06:18 -0800 Message-ID: Thread-Topic: SPNEGO-bis comments/questions Thread-Index: AcTyfhP2MjTUYJnqR6KGG4LzSHAPLAAIn0xA From: "Liqiang\(Larry\) Zhu" To: "Tom Yu" X-OriginalArrivalTime: 04 Jan 2005 21:06:20.0087 (UTC) FILETIME=[3D08F470:01C4F2A1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org, Sam Hartman Subject: RE: SPNEGO-bis comments/questions X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable Tom Yu wrote: > Constraints, including size constraints, go after a type. (There's an exception for SEQUENCE OF and SET OF but we won't=20 > worry about that.) The named bit list is part of the BIT STRING type. Try moving the size constraint so that it follows=20 > the named bit list. Thanks, lzhu> Also is there any issue w.r.t. allocating the relative-OIDs for=20 lzhu> the SPNEGO ASN.1 module here? lzhu> iso(1) identified-organization(3) dod(6) internet(1) =20 lzhu> security(5) mechanism(5) snego (2) modules(4) spec2(2) Tom, can you verify the selected OID is available -- larry -----Original Message----- From: Tom Yu [mailto:tlyu@mit.edu]=20 Sent: Tuesday, January 04, 2005 8:54 AM To: Liqiang(Larry) Zhu Cc: Sam Hartman; Simon Spero; martin.rex@sap.com; kitten@ietf.org Subject: Re: SPNEGO-bis comments/questions >>>>> "lzhu" =3D=3D Liqiang\(Larry\) Zhu writes: lzhu> I could not compile the ASN.1 module with the SIZE constrains=20 lzhu> using Microsoft ASN.1 compiler. lzhu> ContextFlags ::=3D BIT STRING (SIZE (32)) { =20 lzhu> delegFlag (0), =20 lzhu> mutualFlag (1), =20 lzhu> replayFlag (2), =20 lzhu> sequenceFlag (3), =20 lzhu> anonFlag (4), =20 lzhu> confFlag (5), =20 lzhu> integFlag (6) =20 lzhu> } Constraints, including size constraints, go after a type. (There's an exception for SEQUENCE OF and SET OF but we won't worry about that.) The named bit list is part of the BIT STRING type. Try moving the size constraint so that it follows the named bit list. lzhu> Also is there any issue w.r.t. allocating the relative-OIDs for=20 lzhu> the SPNEGO ASN.1 module here? lzhu> iso(1) identified-organization(3) dod(6) internet(1) =20 lzhu> security(5) mechanism(5) snego (2) modules(4) spec2(2) I'm not sure what you're asking. ---Tom _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Jan 4 18:20:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02572; Tue, 4 Jan 2005 18:20:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClyAz-0003BI-Df; Tue, 04 Jan 2005 18:33:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClxuU-0000YX-KF; Tue, 04 Jan 2005 18:16:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Clxro-0006gw-Il for kitten@megatron.ietf.org; Tue, 04 Jan 2005 18:13:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01820 for ; Tue, 4 Jan 2005 18:13:29 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cly4F-00034H-QE for kitten@ietf.org; Tue, 04 Jan 2005 18:26:25 -0500 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j04NDTVu016908; Tue, 4 Jan 2005 16:13:29 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j04NDSJd007908; Tue, 4 Jan 2005 18:13:28 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.1+Sun/8.13.1) with ESMTP id j04NDSQn028580; Tue, 4 Jan 2005 18:13:28 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.1+Sun/8.13.1/Submit) id j04NDOAq028579; Tue, 4 Jan 2005 18:13:24 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f From: Bill Sommerfeld To: Sam Hartman In-Reply-To: <87vfad1aao.fsf@luminous.mit.edu> References: <87vfad1aao.fsf@luminous.mit.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1104880403.28053.50.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.324 Date: Tue, 04 Jan 2005 18:13:24 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, "Liqiang\(Larry\) Zhu" , Russ Housley , Nicolas Williams Subject: Re: Review: of draft-ietf-kitten-2478bis-03.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit On Tue, 2005-01-04 at 10:30, Sam Hartman wrote: > There is an interesting relation to SPNEGO in that if SPNEGO happens > to exchange MICs and SPNEGO is actually used, the attack is defeated. > > I do believe addressing this as a security consideration is > appropriate. I think that's what I suggested in my initial note: document the requirement on mechanisms as clearly as possible and move on. > I don't know of mechanisms today that have structurally > similar ciphertext and I believe that we can simply avoid > standardizing such mechanisms in the future. IMHO, avoiding structural similarities is the wrong fix here (among other reasons, enforcing this assumes mechanism development is sufficiently serialized that a mechanism developer can know what other mechanisms are going to do by the time their mechanism deploys). instead, in new mechanisms, the mechanism id should be cryptographically bound into the exchange. - Bill _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Jan 4 18:39:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04575; Tue, 4 Jan 2005 18:39:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClyTj-0003cr-BJ; Tue, 04 Jan 2005 18:52:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClyDX-0002eC-7a; Tue, 04 Jan 2005 18:35:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClyAK-0001Op-NS for kitten@megatron.ietf.org; Tue, 04 Jan 2005 18:32:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03977 for ; Tue, 4 Jan 2005 18:32:37 -0500 (EST) Received: from stratton-four-forty-two.mit.edu ([18.187.6.187] helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClyMm-0003UC-3r for kitten@ietf.org; Tue, 04 Jan 2005 18:45:33 -0500 Received: by cz.mit.edu (Postfix, from userid 8042) id 1A996E0063; Tue, 4 Jan 2005 18:33:40 -0500 (EST) To: Bill Sommerfeld References: <87vfad1aao.fsf@luminous.mit.edu> <1104880403.28053.50.camel@thunk> From: Sam Hartman Date: Tue, 04 Jan 2005 18:33:40 -0500 In-Reply-To: <1104880403.28053.50.camel@thunk> (Bill Sommerfeld's message of "Tue, 04 Jan 2005 18:13:24 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: kitten@ietf.org, "Liqiang\(Larry\) Zhu" , Russ Housley , Nicolas Williams Subject: Re: Review: of draft-ietf-kitten-2478bis-03.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 >>>>> "Bill" == Bill Sommerfeld writes: Bill> On Tue, 2005-01-04 at 10:30, Sam Hartman wrote: >> There is an interesting relation to SPNEGO in that if SPNEGO >> happens to exchange MICs and SPNEGO is actually used, the >> attack is defeated. >> >> I do believe addressing this as a security consideration is >> appropriate. Bill> I think that's what I suggested in my initial note: document Bill> the requirement on mechanisms as clearly as possible and Bill> move on. It is. >> I don't know of mechanisms today that have structurally similar >> ciphertext and I believe that we can simply avoid standardizing >> such mechanisms in the future. Bill> IMHO, avoiding structural similarities is the wrong fix here Bill> (among other reasons, enforcing this assumes mechanism Bill> development is sufficiently serialized that a mechanism Bill> developer can know what other mechanisms are going to do by Bill> the time their mechanism deploys). I have no problem doing this or recommending it. In some cases it may be difficult. Keep in mind that you only need to worry about mechanisms that share the same underlying credential; I don't anticipate someone turning a Kerberos TGT into a valid PGP signature or anything like that. If for your family of related or semi-related mechanisms, you find it easier to bind to something other than the OID, that's fine with me. I do agree that the binding is cryptographic. I'm treating this attack as a possible chosen ciphertext attack against GSSAPI mechanisms. I realize that I'm using the term ciphertext loosly; what I'm calling ciphertext also includes ASN.1 wrappers and other framing, but I find thinking of this as a CCA gets me in the right mindset to consider what solutions are possible and what sorts of manipulations might produce a successful attack. --Sam _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Jan 4 19:41:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08215; Tue, 4 Jan 2005 19:41:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClzRm-0004ly-IO; Tue, 04 Jan 2005 19:54:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClzC1-000782-Qt; Tue, 04 Jan 2005 19:38:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Clz8K-0006Dg-3I for kitten@megatron.ietf.org; Tue, 04 Jan 2005 19:34:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07879 for ; Tue, 4 Jan 2005 19:34:36 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClzKn-0004eO-0b for kitten@ietf.org; Tue, 04 Jan 2005 19:47:33 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Jan 2005 16:34:08 -0800 Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Tue, 4 Jan 2005 16:34:08 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Jan 2005 16:34:07 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Tue, 4 Jan 2005 16:34:07 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 4 Jan 2005 16:34:06 -0800 Message-ID: Thread-Topic: SPNEGO-bis comments/questions Thread-Index: AcTys19cdO53AN/8Sg6lgXvVXPxzHgACsQKw From: "Liqiang\(Larry\) Zhu" To: X-OriginalArrivalTime: 05 Jan 2005 00:34:07.0693 (UTC) FILETIME=[444EA7D0:01C4F2BE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org, hartmans@mit.edu Subject: RE: SPNEGO-bis comments/questions X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable Martin wrote: > So I think we should be fine extending the S(P)NEGO OID for additional usage within the SPNEGO spec. =20 This is good. Thanks, -- Larry -----Original Message----- From: Martin Rex [mailto:martin.rex@sap.com]=20 Sent: Tuesday, January 04, 2005 3:16 PM To: Liqiang(Larry) Zhu Cc: tlyu@mit.edu; hartmans@mit.edu; ses@unc.edu; martin.rex@sap.com; kitten@ietf.org Subject: Re: SPNEGO-bis comments/questions Liqiang\ wrote: >=20 > lzhu> Also is there any issue w.r.t. allocating the relative-OIDs for=20 > lzhu> the SPNEGO ASN.1 module here? >=20 > lzhu> iso(1) identified-organization(3) dod(6) internet(1) =20 > lzhu> security(5) mechanism(5) snego (2) modules(4) spec2(2) What kind of issue do you expect? The OID (arc) 1.3.6.1.5.5.2 was assigned by IANA for use with S(P)NEGO. Normally, by assigning an OID to someone/something, you give up control for the entire arc beginning with that OID along with it (I would say), so whoever gets assigned the OID becomes the registrar for OID extensions below. So I think we should be fine extending the S(P)NEGO OID for additional usage within the SPNEGO spec. =20 -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Jan 4 20:27:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10985; Tue, 4 Jan 2005 20:27:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cm0AI-0005dJ-7I; Tue, 04 Jan 2005 20:40:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Clztq-0004aR-DP; Tue, 04 Jan 2005 20:23:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClzsK-00040n-3E for kitten@megatron.ietf.org; Tue, 04 Jan 2005 20:22:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10557 for ; Tue, 4 Jan 2005 20:22:10 -0500 (EST) Received: from smtpsrv12.isis.unc.edu ([152.2.1.243] helo=smtp.unc.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cm04k-0005WK-Jo for kitten@ietf.org; Tue, 04 Jan 2005 20:35:05 -0500 Received: from [152.2.246.1] (hillary.oit.unc.edu [152.2.246.1]) by smtp.unc.edu (8.12.9/8.12.9) with ESMTP id j051LHI7009348; Tue, 4 Jan 2005 20:21:17 -0500 (EST) Message-ID: <41DB4115.2050004@unc.edu> Date: Tue, 04 Jan 2005 20:21:25 -0500 From: Simon Spero User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Williams References: <20050103210212.GJ184117@binky.central.sun.com> <200501040046.BAA04277@uw1048.wdf.sap.corp> <20050104005322.GM184117@binky.central.sun.com> In-Reply-To: <20050104005322.GM184117@binky.central.sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, Wyllys.Ingersoll@Sun.COM, raeburn@MIT.EDU Subject: Re: spnego-bis comments X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Nicolas Williams wrote: >>not be noticable. >> >> > In most cases the effect of the acceptor ignoring these flags will > > >Correct. Do you know of any implementations where a SPNEGO acceptor >does not ignore the context flags field > > Which initiators include it? I don't remember seeing it from IE, but I wasn't paying too close attention Simon _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Jan 4 23:18:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22410; Tue, 4 Jan 2005 23:18:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cm2pN-0000fQ-5c; Tue, 04 Jan 2005 23:31:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cm2Z9-0008UV-5W; Tue, 04 Jan 2005 23:14:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cm2Qb-0004Lb-Kz for kitten@megatron.ietf.org; Tue, 04 Jan 2005 23:05:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21422 for ; Tue, 4 Jan 2005 23:05:43 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cm2d4-0000LK-Bh for kitten@ietf.org; Tue, 04 Jan 2005 23:18:40 -0500 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j0545fdt022695 for ; Tue, 4 Jan 2005 21:05:42 -0700 (MST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j0545fjW001683 for ; Tue, 4 Jan 2005 21:05:41 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id j0544ZDH343327; Tue, 4 Jan 2005 22:04:35 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id j0544WLg343326; Tue, 4 Jan 2005 22:04:32 -0600 (CST) Date: Tue, 4 Jan 2005 22:04:32 -0600 From: Nicolas Williams To: Simon Spero Message-ID: <20050105040432.GI184117@binky.central.sun.com> Mail-Followup-To: Simon Spero , Martin Rex , kitten@ietf.org, Wyllys.Ingersoll@Sun.COM, raeburn@MIT.EDU References: <20050103210212.GJ184117@binky.central.sun.com> <200501040046.BAA04277@uw1048.wdf.sap.corp> <20050104005322.GM184117@binky.central.sun.com> <41DB4115.2050004@unc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41DB4115.2050004@unc.edu> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: kitten@ietf.org, Wyllys.Ingersoll@Sun.COM, raeburn@MIT.EDU Subject: Re: spnego-bis comments X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab On Tue, Jan 04, 2005 at 08:21:25PM -0500, Simon Spero wrote: > Nicolas Williams wrote: > > >>not be noticable. > >> > >> > >In most cases the effect of the acceptor ignoring these flags will > > > > > >Correct. Do you know of any implementations where a SPNEGO acceptor > >does not ignore the context flags field > > > > > Which initiators include it? I don't remember seeing it from IE, but I > wasn't paying too close attention Ours does, but our acceptor blissfully ignores it if present. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Mon Jan 17 11:25:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20408; Mon, 17 Jan 2005 11:25:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqZwJ-00009e-Oq; Mon, 17 Jan 2005 11:41:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqZbn-0006SQ-5T; Mon, 17 Jan 2005 11:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqZRv-0004YD-EZ for kitten@megatron.ietf.org; Mon, 17 Jan 2005 11:09:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19081 for ; Mon, 17 Jan 2005 11:09:48 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqZgz-0008Cb-W6 for kitten@ietf.org; Mon, 17 Jan 2005 11:25:26 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Mon, 17 Jan 2005 08:09:18 -0800 Received: from red-hub-03.redmond.corp.microsoft.com ([157.54.2.25]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 17 Jan 2005 08:09:18 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Mon, 17 Jan 2005 08:09:17 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Mon, 17 Jan 2005 08:08:53 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Jan 2005 08:08:52 -0800 Message-ID: Thread-Topic: spnego-bis comments Thread-Index: AcTkgem2a466Uc2zRAStS7DfXP8z4QYK8VXw From: "Liqiang\(Larry\) Zhu" To: "Ken Raeburn" , X-OriginalArrivalTime: 17 Jan 2005 16:08:53.0747 (UTC) FILETIME=[D7285430:01C4FCAE] X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 Content-Transfer-Encoding: quoted-printable Subject: RE: spnego-bis comments X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Content-Transfer-Encoding: quoted-printable =20 Ken Raeburn wrote: > Section 5, second paragraph: > as described later in this section, is OPTIONAL. =20 > A mechanism is the > acceptor's most preferred mechanism if there is no other mechanism > which, had it been present in the mechanism list,=20 > the acceptor would > have preferred over the accepted mechanism. > "The most preferred mechanism" implies uniqueness. The rest of the description does not seem to support=20 > that. In fact, if my policy is "use the first mech listed", then isn't that first mech always going to=20 > qualify (assuming I support it at all)? Or is the intent that this other mech would always be used if it's=20 > in the list, regardless of position or other mechanisms? (In which case, "use the first mech listed" has no=20 > "most preferred mech" at all.) For the initiator, the most preferred mechanism in the first on the mechanism list, For the acceptor, there are two cases: 1) if the serer selects the mechanism preference order based on the list sent by the client, then it prefers the first on the list from the client 2) otherwise, the server's preference order can be different from the order specified in the list. I do not quite understand your statement about if this conflicts with the uniqueness semantics. > Minor: I don't think Sections demand page breaks. =20 > A bunch of vertical space is wasted just to get=20 > sections 2, 6, 7, 8, 9, and 10 to start at the=20 > top of their pages. Section 8 (one-line header=20 > plus one line of > content) is especially wasteful. > Minor: Appendix B starts off indented too far by=20 > three columns. The draft is generated using XML2RFC, and I can not change these. RFC editor should handle these issues at the time of final publication. The rest of the issues in this thread should have been addressed in the latest version. -- Larry -----Original Message----- From: kitten-bounces@lists.ietf.org [mailto:kitten-bounces@lists.ietf.org] On Behalf Of Ken Raeburn Sent: Friday, December 17, 2004 12:39 PM To: kitten@ietf.org Subject: spnego-bis comments Sorry these are so late, I've been working on my 48-hours, important bug fixes, etc. I probably should've spent more time going over the WG email before reviewing this, but.... Section 1, the introduction ought not to have requirements indications, at least not to this degree. I could see maybe an introduction saying under circumstances X or Y an implementation MAY/SHOULD/MUST follow this RFC, but not for how parts of the protocol defined in the RFC are to be implemented. The OID shouldn't be defined here either; probably in section 4 or maybe 4.2. Minor: Page 7 first line, "...and it is OPTIONAL to emit a context level negotiation token", sounds awkward to me (maybe "OPTIONAL whether to emit" or "emitting...is OPTIONAL"?). Given the aggressive work by the RFC Editor these days, it will probably get reworded into active voice, along with a whole bunch of other stuff. Better to do it first, than give them more work. Minor: Page 8, item (c), "...this mechanism token MUST be deposited to the selected mechanism". The word "deposited" seems odd here, how about "passed"? Item (d) likewise. And maybe "emit"->"returned" for outputs of GSS-API functions. Minor: Item (d) "until the GSS_S_COMPLETE is returned", drop "the" or make it "the GSS_S_COMPLETE status" or something. Section 3.1: Might be obvious, but it may be worth noting that the SPNEGO OID itself SHOULD (MUST?) NOT be included in the list of mechanisms. Section 3.2 "The basic form of the procedure ... is summarized as follows". Okay, where's the non-basic, non-summary, fully-detailed description? If this is the fully detailed description, it should tell me what the target should do if the initial proposed mechanism is acceptable, but an error happens processing the included token. Near as I can tell, (c) says I should return GSS_S_COMPLETE and not send a reply. If the error happens later, then it's clearer what I should do. Section 3.2 (d) seems to ignore the possibility that the target didn't like the proposed mechanism and returned a list of different ones. And what it if returned only ones which weren't supported by the initiator? In fact, the word "error" occurs only once in the document, and that's in the introduction. ("Fail" occurs a bit more -- introduction, security considerations, and appendices. But the main body of the spec can't address just the success cases.) Q: Does GSSAPI allow for a state where authentication has essentially succeeded, but one has the option of sending one more mech token and the other can't independently determine whether the it will do so? (I'm wondering if that would affect the scheduling of the MIC token transmission, but haven't looked into it yet.) Section 4.2.1: reqFlags [1] ContextFlags OPTIONAL, -- maintained from RFC 2478 for backward compatibility, -- RECOMMENDED to be left out reqFlags This field, if present, contains the service options that are requested to establish the context. The context flags SHOULD be filled in from the req_flags parameter of Which is it? Included (and ignored), or omitted? Section 5, second paragraph: as described later in this section, is OPTIONAL. A mechanism is the acceptor's most preferred mechanism if there is no other mechanism which, had it been present in the mechanism list, the acceptor would have preferred over the accepted mechanism. "The most preferred mechanism" implies uniqueness. The rest of the description does not seem to support that. In fact, if my policy is "use the first mech listed", then isn't that first mech always going to qualify (assuming I support it at all)? Or is the intent that this other mech would always be used if it's in the list, regardless of position or other mechanisms? (In which case, "use the first mech listed" has no "most preferred mech" at all.) When is NegTokenInit.mechListMIC used? Section 3 seems to indicate that the MIC tokens aren't exchanged until *after* GSS_S_COMPLETE has been returned on both sides by the agreed-upon mechanism, and aren't we sure to be using NegTokenResp at that point? (In Section 5 it appears that it's possible to use mechListMIC in NegTokenInit.) Section 6: A final RFC should probably not talk too much about planned work in specific working groups. MIC requirements: influence the acceptor's choice of mechanism. As discussed in Section 5, if there are mechanisms that if present in the initiator's list of mechanisms might be preferred by the acceptor to the initiator's preferred mechanism, the acceptor MUST demand the MIC token exchange. As a consequence, acceptors MUST demand the MIC token exchange if they support negotiation of attributes not available in the initiator's preferred mechanism regardless of whether the initiator actually requested these attributes. ... (I'm not sure I follow "as a consequence", but I haven't thought about it enough, or caught up on the mail) but section 5 says: If the mechanism selected by the negotiation does not support integrity protection, then no mechlistMIC token is used. ... so what if the acceptor supports this attribute negotiation but they agree on a mechanism without integrity protection? Section 7: The security considerations do need work, as Bill noted. I'd like to see discussion of Bill's thought-experiment case, where the two parties see different OIDs, each thinking they're negotiating for their preferred mech, but in reality they're different mechs with similar-enough initial messages. Minor: I don't think Sections demand page breaks. A bunch of vertical space is wasted just to get sections 2, 6, 7, 8, 9, and 10 to start at the top of their pages. Section 8 (one-line header plus one line of content) is especially wasteful. Minor: Appendix B starts off indented too far by three columns. Appendix B "address the problems in RFC 2478": Since there's been no discussion of what "the problems" are, I'd drop the word "the". Should we say "Microsoft Windows 2000/..."? That's it for now. Ken _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Mon Jan 24 13:23:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08691; Mon, 24 Jan 2005 13:23:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct98N-0006k7-OX; Mon, 24 Jan 2005 13:40:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct8kl-0003nk-W0; Mon, 24 Jan 2005 13:15:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct8dN-0001xj-2K for kitten@megatron.ietf.org; Mon, 24 Jan 2005 13:08:17 -0500 Received: from serrano.cc.columbia.edu (IDENT:cu41754@serrano.cc.columbia.edu [128.59.29.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07203 for ; Mon, 24 Jan 2005 13:08:12 -0500 (EST) Received: from [192.168.1.10] (24-193-46-55.nyc.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j0OI8ENj027820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 24 Jan 2005 13:08:14 -0500 (EST) Message-ID: <41F53A27.6010205@columbia.edu> Date: Mon, 24 Jan 2005 13:10:47 -0500 From: Jeffrey Altman Organization: Not Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kitten@ietf.org X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 Subject: IETF 62 Scheduling X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1387349349==" Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 This is a cryptographically signed message in MIME format. --===============1387349349== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040808000606030404050202" This is a cryptographically signed message in MIME format. --------------ms040808000606030404050202 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit In preparation for scheduling a meeting for IETF 62, I would appreciate a list of topics participants would like to have placed on the agenda. So far I have: * SPNEGO * PRF * Naming * Java/C# Binding Update The current list of working groups for which I am requesting conflict avoidance includes: * SASL * SECSH * KERBEROS * SAAG * PKI4IPSE * INCH * ISMS * OPENPGP * NFSV4 * RDDP * APPS AREA OPEN MTG Please advise me privately of any additional groups. Thank you. Jeffrey Altman --------------ms040808000606030404050202 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAwxk8TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNTI3MTc1ODU4WhcNMDUwNTI3MTc1ODU4 WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc3JqO5AsZrozd+mJ2mPuCTYo2 +nJ9Qq6jtUYtp7YTMW4d2Q6GLhNaHb1l9m74SxuY4f5vP6JtZjr6p9+LCCxD0w0NVLKRgUDp z+tKFitbkJe9BSCxCURRvY3vdWA71gSCUvZAN3346hHb4oGVqgdpmfFJXYAHWpC46wiL72N9 WxySzY17/0eU0c8+r9dNoLpPQeL43O66O80jCl1qnXMaXaakZPsfm+5W90MYXhpQ1WIQpv02 lBn3BH5YE8xwbsNrw5AF4v7pjMuW85GI6FrDmfbpJX473Rpl5rmv3TpXkJ+7UsIIO1puyS8r 1o7kjDZ5EUYJxxglTGR6XL/RNzqHAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAZYeVFCMP0iV+UVa0 eFoXkzMVl61CNAVY2YQ9/QQazO3G4qNiif35ArrnjPRDRj5M7WTeOCFqPVuvCttyJRiDKsEe L4Yah22mRA3mR7x52j2FquPYZ9qCr1IhrNGzsMk+gopX5G0fTHZb6+uDu5SeMPNNcIznGA7M CMpXAJ2PcKgwggL6MIICY6ADAgECAgMMZPEwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0MDUyNzE3NTg1OFoXDTA1 MDUyNzE3NTg1OFowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3NyajuQLGa6M 3fpidpj7gk2KNvpyfUKuo7VGLae2EzFuHdkOhi4TWh29ZfZu+EsbmOH+bz+ibWY6+qffiwgs Q9MNDVSykYFA6c/rShYrW5CXvQUgsQlEUb2N73VgO9YEglL2QDd9+OoR2+KBlaoHaZnxSV2A B1qQuOsIi+9jfVscks2Ne/9HlNHPPq/XTaC6T0Hi+NzuujvNIwpdap1zGl2mpGT7H5vuVvdD GF4aUNViEKb9NpQZ9wR+WBPMcG7Da8OQBeL+6YzLlvORiOhaw5n26SV+O90aZea5r906V5Cf u1LCCDtabskvK9aO5Iw2eRFGCccYJUxkely/0Tc6hwIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAGWH lRQjD9IlflFWtHhaF5MzFZetQjQFWNmEPf0EGsztxuKjYon9+QK654z0Q0Y+TO1k3jghaj1b rwrbciUYgyrBHi+GGodtpkQN5ke8edo9harj2Gfagq9SIazRs7DJPoKKV+RtH0x2W+vrg7uU njDzTXCM5xgOzAjKVwCdj3CoMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMZPEw CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDUwMTI0MTgxMDQ3WjAjBgkqhkiG9w0BCQQxFgQULb9KCN2KPEmJgW41KSJFQmG7RfIw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxk8TB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMMZPEwDQYJKoZIhvcNAQEBBQAEggEAufZnAplGLliWt5IhHfijdmPGySgYh2q1oOJEpwQx P0h6GrYG/zpUSJOdS490w8SvKXnQ7b7O5tdHzfCPF378mu9UU4AG9RA/ij6irJUUb70UFCPI aoY4Ka7idmr3qMxhgvdXYQU1zM8iZdVilhgQg+7DH5OHdyc5CFFhbsM03xH7P9KHdYf6vrbc DfcmWr2stkJiNgsXgEiR5FAkHgKdzelw6iePN+sheIvJv2I4An/WnUlNCzzaBa9gFbCuX67h Ne/7Fubbd5k4Fco0MNXrNirNE9FA5RedjxC3muIrNGRIZaadjzqlXNF3IOjGlJ3rp311xsGj p2m+9hOe2ok4SAAAAAAAAA== --------------ms040808000606030404050202-- --===============1387349349== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============1387349349==-- From kitten-bounces@ietf.org Mon Jan 24 16:13:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28170; Mon, 24 Jan 2005 16:13:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtBnC-00065d-V4; Mon, 24 Jan 2005 16:30:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtB2t-0000MI-3L; Mon, 24 Jan 2005 15:42:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtB00-0007aH-Jk; Mon, 24 Jan 2005 15:39:48 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21383; Mon, 24 Jan 2005 15:39:46 -0500 (EST) Message-Id: <200501242039.PAA21383@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 24 Jan 2005 15:39:45 -0500 Cc: kitten@ietf.org Subject: I-D ACTION:draft-ietf-kitten-2478bis-05.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Kitten (GSS-API Next Generation) Working Group of the IETF. Title : The Simple and Protected GSS-API Negotiation Mechanism Author(s) : L. Zhu, et al. Filename : draft-ietf-kitten-2478bis-05.txt Pages : 30 Date : 2005-1-24 This document specifies a negotiation mechanism for the Generic Security Service Application Program Interface (GSS-API) which is described in RFC 2743. GSS-API peers can use this negotiation mechanism to choose from a common set of security mechanisms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-2478bis-05.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-ietf-kitten-2478bis-05.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-ietf-kitten-2478bis-05.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-1-24154130.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-kitten-2478bis-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-kitten-2478bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-1-24154130.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --NextPart-- From kitten-bounces@ietf.org Mon Jan 24 19:41:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24394; Mon, 24 Jan 2005 19:41:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtF2O-0008DO-HV; Mon, 24 Jan 2005 19:58:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtEj7-0005uj-3b; Mon, 24 Jan 2005 19:38:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtEe9-0004YK-BD for kitten@megatron.ietf.org; Mon, 24 Jan 2005 19:33:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23687 for ; Mon, 24 Jan 2005 19:33:25 -0500 (EST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtEuj-0007tv-Jm for kitten@ietf.org; Mon, 24 Jan 2005 19:50:39 -0500 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j0P0XQpv018507 for ; Mon, 24 Jan 2005 16:33:26 -0800 (PST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j0P0XPwg011416 for ; Mon, 24 Jan 2005 17:33:26 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id j0P0W66p361168; Mon, 24 Jan 2005 18:32:06 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id j0P0W4wT361167; Mon, 24 Jan 2005 18:32:04 -0600 (CST) Date: Mon, 24 Jan 2005 18:32:04 -0600 From: Nicolas Williams To: "Liqiang(Larry) Zhu" Message-ID: <20050125003204.GC361016@binky.central.sun.com> Mail-Followup-To: "Liqiang(Larry) Zhu" , Ken Raeburn , kitten@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: kitten@ietf.org, Ken Raeburn Subject: Re: spnego-bis comments X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 On Mon, Jan 17, 2005 at 08:08:52AM -0800, Liqiang(Larry) Zhu wrote: > Ken Raeburn wrote: > > Minor: I don't think Sections demand page breaks. > > A bunch of vertical space is wasted just to get > > sections 2, 6, 7, 8, 9, and 10 to start at the > > top of their pages. Section 8 (one-line header > > plus one line of > > content) is especially wasteful. > > Minor: Appendix B starts off indented too far by > > three columns. > > The draft is generated using XML2RFC, and I can not change these. RFC > editor should handle these issues at the time of final publication. Quoting Bill Fenner from the xml2rfc list: BF>Change BF> BF> BF> BF>to BF> BF> Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten