From spkm-bounces@ietf.org Thu Apr 05 17:52:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZZt2-0002e2-EO; Thu, 05 Apr 2007 17:52:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZZt0-0002V5-Nj for spkm@ietf.org; Thu, 05 Apr 2007 17:52:54 -0400 Received: from citi.umich.edu ([141.211.133.111]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HZZsz-0004qI-Cz for spkm@ietf.org; Thu, 05 Apr 2007 17:52:54 -0400 Received: from [141.211.133.26] (yoga.citi.umich.edu [141.211.133.26]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "aglo", Issuer "CITI Production KCA" (verified OK)) by citi.umich.edu (Postfix) with ESMTP id DACAD392A1; Thu, 5 Apr 2007 17:52:52 -0400 (EDT) Message-ID: <46156FB4.4070007@citi.umich.edu> Date: Thu, 05 Apr 2007 17:52:52 -0400 From: Olga Kornievskaia User-Agent: Thunderbird 1.5.0.10 (X11/20070301) MIME-Version: 1.0 To: kitten@lists.ietf.org, spkm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Subject: [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.txt X-BeenThere: spkm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org Is PKU2U meant to be a GSS API mechanism or a stand alone security protocol? The abstract seems to imply that pku2u could be a stand alone protocol. However, the 1st sentence of the Section 5 says that pku2u "can only be used in conjunction with GSS-API". In Section 5, The syntax of the initial context establishment token follows the initialContextToken syntax defined in Section 3.1 of [RFC2743]. PKU2U is identified by the Objection Identifier (OID) id-kerberos- pku2u. id-kerberos-pku2u ::= { iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2) pku2u(7) } Subsequent context establishment tokens MUST NOT be encapsulated in this GSS-API generic token framing. First, I hope that the 1st sentence refers to "tokens" not just the 1st (AS_REQ) token. As its written, it says that AS_REQ token is framed but the AS_REP token is not which doesn't make sense. Second, what does the "subsequent context establishment tokens" refer to? AP_REP/AP_REQ or a something else (ie. , new pku2u sessions)? Furthermore, there shouldn't be any unframed tokens in GSS-API mechanism. I propose to remove this sentence from the draft. What would be left is the description how to frame context establishment tokens (AS_REQ/AS_REP) and then the rest are treated as per-message token according to rfc4121. _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Thu Apr 05 19:08:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZb49-0001GE-46; Thu, 05 Apr 2007 19:08:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZb47-0001Cq-BX for spkm@ietf.org; Thu, 05 Apr 2007 19:08:28 -0400 Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZb43-0002Va-U7 for spkm@ietf.org; Thu, 05 Apr 2007 19:08:27 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l35N8Ns1020920 for ; Thu, 5 Apr 2007 23:08:23 GMT Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l35N8M7K021836 for ; Thu, 5 Apr 2007 17:08:23 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l35N7VR0005662; Thu, 5 Apr 2007 18:07:31 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l35N7Upr005661; Thu, 5 Apr 2007 18:07:30 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 5 Apr 2007 18:07:30 -0500 From: Nicolas Williams To: Olga Kornievskaia Subject: Re: [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.txt Message-ID: <20070405230730.GB28748@Sun.COM> Mail-Followup-To: Olga Kornievskaia , kitten@lists.ietf.org, spkm@ietf.org References: <46156FB4.4070007@citi.umich.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46156FB4.4070007@citi.umich.edu> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: kitten@lists.ietf.org, spkm@ietf.org X-BeenThere: spkm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org On Thu, Apr 05, 2007 at 05:52:52PM -0400, Olga Kornievskaia wrote: > Is PKU2U meant to be a GSS API mechanism or a stand alone security > protocol? The abstract seems to imply that pku2u could be a stand alone > protocol. However, the 1st sentence of the Section 5 says that pku2u > "can only be used in conjunction with GSS-API". GSS mechanisms can be stand-alone too, I suppose. PKU2U has got to be intended to be a standards-track GSS-API mechanism, else why are we here? > In Section 5, > > The syntax of the initial context establishment token follows the > initialContextToken syntax defined in Section 3.1 of [RFC2743]. > PKU2U is identified by the Objection Identifier (OID) id-kerberos- > pku2u. > > id-kerberos-pku2u ::= > { iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2) > pku2u(7) } > > Subsequent context establishment tokens MUST NOT be encapsulated in > this GSS-API generic token framing. > > > First, I hope that the 1st sentence refers to "tokens" not just the 1st > (AS_REQ) token. As its written, it says that AS_REQ token is framed but > the AS_REP token is not which doesn't make sense. No, it *does* make sense. RFC2743 only requires the pseudo-ASN.1 DER header on the initial context token. It does not require it on any other tokens at all. RFC1964 went beyond this and required the use of that header on all of the Kerberos V GSS mechanism's context and per-message tokens. We all recognize that there was little or no point to this, so when we were working on RFC4121 we wanted to dispense with that header on all but the initial context token (that one being required by RFC2743) and settled for not having that header on per-message tokens but keeping it on all context tokens (primarily because of packet inspection tools that are used to them having that header, as I recall). > Second, what does the "subsequent context establishment tokens" refer > to? AP_REP/AP_REQ or a something else (ie. , new pku2u sessions)? PKU2U's context token exchanges look like this: I: AS-REQ A: AS-REP I: AP-REQ A: AP-REP Here the first one is the "initial context establishment token" and the subsequent three tokens are ""subsequent context establishment tokens." > Furthermore, there shouldn't be any unframed tokens in GSS-API mechanism. This is incorrect. > I propose to remove this sentence from the draft. What would be left is > the description how to frame context establishment tokens > (AS_REQ/AS_REP) and then the rest are treated as per-message token > according to rfc4121. You might argue that if you'd like to build PKU2U as a stackable mechanism that stacks on top of RFC4121 *then* having the RFC2743 header on the AP-REQ/AP-REP tokens in the PKU2U spec would help keep your implementation simple. As a proponent of stackable mechanisms I tend to agree, but because this stackable mechanism in particular would be stackable only on top of RFC1964/RFC4121 it would be OK for the implementation to know to remove the header on output/insert the header on input. [Note to skeptics: yes, such a stackable mechanism would need a special interface by which it could turn acquire a CREDENTIAL HANDLE for the Kerberos V mechanism using a Ticket, ticket session key and ancilliary data. In Solaris we have gss_acquire_cred_with_password(); we could easily add gss_acquire_cred_with_ticket()...] I feel loath to perpetuate the mistake made in RFC1964 of adding that header that had been intended only for the initial context token to all tokens. Nico -- _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Fri Apr 06 03:28:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZisO-0007YQ-Lk; Fri, 06 Apr 2007 03:28:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZisM-0007YH-MZ for spkm@ietf.org; Fri, 06 Apr 2007 03:28:50 -0400 Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZisJ-0001uz-7x for spkm@ietf.org; Fri, 06 Apr 2007 03:28:50 -0400 Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Fri, 6 Apr 2007 00:28:46 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) with Microsoft SMTP Server id 8.0.685.25; Fri, 6 Apr 2007 00:28:46 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Apr 2007 00:28:46 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.txt Date: Fri, 6 Apr 2007 00:28:27 -0700 Message-ID: In-Reply-To: <46156FB4.4070007@citi.umich.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.txt thread-index: Acd4BGUsFkcuKA6FRNmwF8cjiYBM3AAGKRiw References: <46156FB4.4070007@citi.umich.edu> From: "Liqiang(Larry) Zhu" To: Olga Kornievskaia , , X-OriginalArrivalTime: 06 Apr 2007 07:28:46.0262 (UTC) FILETIME=[363BC560:01C7781D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: X-BeenThere: spkm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org Olga Kornievskaia wrote: > Is PKU2U meant to be a GSS API mechanism or a standalone security=20 > protocol? The abstract seems to imply that pku2u could be a stand=20 > alone protocol. However, the 1st sentence of the Section 5 says that=20 > pku2u "can only be used in conjunction with GSS-API". PKU2U as defined here requires the use of GSS-API. I do not know if you have objections to this requirement. > First, I hope that the 1st sentence refers to "tokens" not just the=20 > 1st > (AS_REQ) token. As its written, it says that AS_REQ token is framed=20 > but the AS_REP token is not which doesn't make sense. Your understanding is correct. Only the first message has the framing. This is consistent with RFC4121 and RFC4178. > Second, what does the "subsequent context establishment tokens" refer=20 > to? AP_REP/AP_REQ or a something else (ie. , new pku2u sessions)? > Furthermore, there shouldn't be any unframed tokens in GSS-API mechanism. Only the first message has the token framing. This is how all other GSS-API mechanisms work today. --larry -----Original Message----- From: Olga Kornievskaia [mailto:aglo@citi.umich.edu]=20 Sent: Thursday, April 05, 2007 2:53 PM To: kitten@lists.ietf.org; spkm@ietf.org Subject: [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.txt Is PKU2U meant to be a GSS API mechanism or a stand alone security=20 protocol? The abstract seems to imply that pku2u could be a stand alone=20 protocol. However, the 1st sentence of the Section 5 says that pku2u=20 "can only be used in conjunction with GSS-API". In Section 5, The syntax of the initial context establishment token follows the initialContextToken syntax defined in Section 3.1 of [RFC2743]. PKU2U is identified by the Objection Identifier (OID) id-kerberos- pku2u. id-kerberos-pku2u ::=3D { iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2) pku2u(7) } Subsequent context establishment tokens MUST NOT be encapsulated in this GSS-API generic token framing. First, I hope that the 1st sentence refers to "tokens" not just the 1st=20 (AS_REQ) token. As its written, it says that AS_REQ token is framed but=20 the AS_REP token is not which doesn't make sense. Second, what does the "subsequent context establishment tokens" refer=20 to? AP_REP/AP_REQ or a something else (ie. , new pku2u sessions)?=20 Furthermore, there shouldn't be any unframed tokens in GSS-API mechanism. I propose to remove this sentence from the draft. What would be left is=20 the description how to frame context establishment tokens=20 (AS_REQ/AS_REP) and then the rest are treated as per-message token=20 according to rfc4121. _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Wed Apr 18 16:46:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeH3D-0004tB-UV; Wed, 18 Apr 2007 16:46:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeH3C-0004t3-2l; Wed, 18 Apr 2007 16:46:50 -0400 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeH3B-0003nK-M6; Wed, 18 Apr 2007 16:46:50 -0400 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id WAA28427; Wed, 18 Apr 2007 22:46:40 +0200 (MESZ) From: Martin Rex Message-Id: <200704182046.l3IKkfsK024424@fs4113.wdf.sap.corp> Subject: Re: [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.txt To: lzhu@windows.microsoft.com (Liqiang) Date: Wed, 18 Apr 2007 22:46:41 +0200 (MEST) In-Reply-To: from "Liqiang" at Apr 6, 7 00:28:27 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: aglo@citi.umich.edu, spkm@ietf.org, kitten@lists.ietf.org X-BeenThere: spkm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org Liqiang wrote: > > Olga Kornievskaia wrote: > > First, I hope that the 1st sentence refers to "tokens" not just the > > 1st (AS_REQ) token. As its written, it says that AS_REQ token is framed > > but the AS_REP token is not which doesn't make sense. > > Your understanding is correct. Only the first message has the framing. > This is consistent with RFC4121 and RFC4178. NOPE, it is significantly different from rfc1964 and rfc4121. rfc4121 only dropped the framing on the per-message tokens, it still uses the same=full framing as rfc1964 for all of the context level tokens: quoting rfc4121: [RFC1964] describes the GSS-API mechanism for Kerberos Version 5. It defines the format of context establishment, per-message and context deletion tokens, and uses algorithm identifiers for each cryptosystem in per-message and context deletion tokens. The approach taken in this document obviates the need for algorithm identifiers. This is accomplished by using the same encryption algorithm, specified by the crypto profile [RFC3961] for the session key or subkey that is created during context negotiation, and its * required checksum algorithm. Message layouts of the per-message * tokens are therefore revised to remove algorithm indicators and to add extra information to support the generic crypto framework [RFC3961]. I don't like the idea of dropping the generic framing on any of the context level tokens. > > > Second, what does the "subsequent context establishment tokens" refer > > to? AP_REP/AP_REQ or a something else (ie. , new pku2u sessions)? > > Furthermore, there shouldn't be any unframed tokens in GSS-API > > mechanism. > > Only the first message has the token framing. This is how all other > GSS-API mechanisms work today. The GSS-API spec only requires the generic token framing on the initial context token. There is no requirement for any other (context level and message protection tokens). rfc4121 is actually the only mechanism that I know which does not use the token, and it only does so for the message protection tokens. rfc-1964 (Kerberos 5 gssapi mechanism) has been using the generic framing on all tokens, as well as rfc-2025 (Simple Public Key GSS-API mechanisms). Quoting rfc-2025 (SPKM): The above GSS-API framing shall be applied to all tokens emitted by the SPKM GSS-API mechanism, including SPKM-REP-TI (the response from the Target to the Initiator), SPKM-REP-IT (the response from the Initiator to the Target), SPKM-ERROR, context-deletion, and per- message tokens, not just to the initial token in a context establishment exchange. While not required by RFC-1508, this enables implementations to perform enhanced error-checking. and using this framing throughout is an extremely reasonable approach (you may remember that I opposed that change in rfc4121... :) section 6.1 of rfc2025: 6.1. SPKM_Parse_token call [...] If all tokens are framed as suggested in RFC-1508, Appendix B (specified both in the Kerberos V5 GSS mechanism [KRB5] and in this document), then any mechanism implementation should be able to return at least the mech_type parameter (the other parameters being NULL) for any uncorrupted input token. If the mechanism implementation whose SPKM_Parse_token() function is being called does recognize the token, it can return token_type so that the application can subsequently call the correct GSS function. -Martin _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Wed Apr 18 16:54:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeHB5-0007jA-Mg; Wed, 18 Apr 2007 16:54:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeHB4-0007iv-QN for spkm@ietf.org; Wed, 18 Apr 2007 16:54:58 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeHB3-0006IE-6O for spkm@ietf.org; Wed, 18 Apr 2007 16:54:58 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3IKsuS1001556 for ; Wed, 18 Apr 2007 20:54:56 GMT Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l3IKsuCJ013616 for ; Wed, 18 Apr 2007 14:54:56 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l3IKrvU6010459; Wed, 18 Apr 2007 15:53:57 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l3IKrtsI010458; Wed, 18 Apr 2007 15:53:55 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 18 Apr 2007 15:53:55 -0500 From: Nicolas Williams To: Martin Rex Subject: Re: [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.txt Message-ID: <20070418205355.GS4375@Sun.COM> Mail-Followup-To: Martin Rex , Liqiang , aglo@citi.umich.edu, spkm@ietf.org, kitten@lists.ietf.org References: <200704182046.l3IKkfsK024424@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200704182046.l3IKkfsK024424@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: aglo@citi.umich.edu, spkm@ietf.org, kitten@lists.ietf.org X-BeenThere: spkm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org On Wed, Apr 18, 2007 at 10:46:41PM +0200, Martin Rex wrote: > Liqiang wrote: > > > > Olga Kornievskaia wrote: > > > First, I hope that the 1st sentence refers to "tokens" not just the > > > 1st (AS_REQ) token. As its written, it says that AS_REQ token is framed > > > but the AS_REP token is not which doesn't make sense. > > > > Your understanding is correct. Only the first message has the framing. > > This is consistent with RFC4121 and RFC4178. > > NOPE, it is significantly different from rfc1964 and rfc4121. Regardless, RFC2743 only requires it on the initial context token. We should probably consider whether we want to RECOMMEND, or even REQUIRE that that header be added to all security context establishment tokens, not just the initial one. But until somebody tables that matter we should not consider RFC1964/4121 as imposing such a requirement on other mechanism that use different mechanism OIDs. That said, there's this interesting question: PKU2U re-uses RFC4121 for everything following PKU2U's first two security context tokens (which are KDC messages between the initiator and the acceptor acting as a pseudo-KDC), so, should those context tokens lifted from RFC4121 bear this header? I could go either way. Nico -- _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Wed Apr 18 17:04:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeHK3-0005BM-2s; Wed, 18 Apr 2007 17:04:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeHK2-0005Ah-Km; Wed, 18 Apr 2007 17:04:14 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeHJx-0001ir-5V; Wed, 18 Apr 2007 17:04:14 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id XAA19449; Wed, 18 Apr 2007 23:03:56 +0200 (MESZ) From: Martin Rex Message-Id: <200704182103.l3IL3tQb025387@fs4113.wdf.sap.corp> Subject: Re: [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.txt To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Wed, 18 Apr 2007 23:03:55 +0200 (MEST) In-Reply-To: <20070418205355.GS4375@Sun.COM> from "Nicolas Williams" at Apr 18, 7 03:53:55 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: kitten@lists.ietf.org, Martin.Rex@sap.com, spkm@ietf.org, aglo@citi.umich.edu X-BeenThere: spkm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org Nicolas Williams wrote: > > On Wed, Apr 18, 2007 at 10:46:41PM +0200, Martin Rex wrote: > > Liqiang wrote: > > > > > > Olga Kornievskaia wrote: > > > > First, I hope that the 1st sentence refers to "tokens" not just the > > > > 1st (AS_REQ) token. As its written, it says that AS_REQ token is framed > > > > but the AS_REP token is not which doesn't make sense. > > > > > > Your understanding is correct. Only the first message has the framing. > > > This is consistent with RFC4121 and RFC4178. > > > > NOPE, it is significantly different from rfc1964 and rfc4121. > > Regardless, RFC2743 only requires it on the initial context token. I know. I did confirm this a few lines later. > > We should probably consider whether we want to RECOMMEND, or even > REQUIRE that that header be added to all security context establishment > tokens, not just the initial one. > > But until somebody tables that matter we should not consider > RFC1964/4121 as imposing such a requirement on other mechanism that use > different mechanism OIDs. Require, because it will amount to less code, less complexity and less confusion. The overhead is negligable. I don't expect any implementation of PKU2U to NOT provide rfc1964/rfc4121 functionality as well, despite the seperate mechanism OID. > > That said, there's this interesting question: PKU2U re-uses RFC4121 for > everything following PKU2U's first two security context tokens (which > are KDC messages between the initiator and the acceptor acting as a > pseudo-KDC), so, should those context tokens lifted from RFC4121 bear > this header? I really want to see the generic framing on all context level tokens (which is what you meant by header, I assume). Could it be that you actually didn't want to ask about the framing, but about the mechanism OID within the header (if it is present)? I'd like to see the generic framing, and I'd like to see it with the same mechanism OID as in the initial context token (which is different from rfc1964/rfc2141). -Martin _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Wed Apr 18 17:11:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeHQw-0003wm-UN; Wed, 18 Apr 2007 17:11:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeHQv-0003wG-J7 for spkm@ietf.org; Wed, 18 Apr 2007 17:11:22 -0400 Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeHQo-0004Ni-FL for spkm@ietf.org; Wed, 18 Apr 2007 17:11:21 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l3ILBDlb000265 for ; Wed, 18 Apr 2007 21:11:13 GMT Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l3ILBDUl011336 for ; Wed, 18 Apr 2007 15:11:13 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l3ILAEPn010539; Wed, 18 Apr 2007 16:10:14 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l3ILAEdM010538; Wed, 18 Apr 2007 16:10:14 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 18 Apr 2007 16:10:14 -0500 From: Nicolas Williams To: Martin Rex Subject: Re: [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.txt Message-ID: <20070418211013.GT4375@Sun.COM> Mail-Followup-To: Martin Rex , lzhu@windows.microsoft.com, aglo@citi.umich.edu, spkm@ietf.org, kitten@lists.ietf.org References: <20070418205355.GS4375@Sun.COM> <200704182103.l3IL3tQb025387@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200704182103.l3IL3tQb025387@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: aglo@citi.umich.edu, spkm@ietf.org, kitten@lists.ietf.org X-BeenThere: spkm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org On Wed, Apr 18, 2007 at 11:03:55PM +0200, Martin Rex wrote: > > We should probably consider whether we want to RECOMMEND, or even > > REQUIRE that that header be added to all security context establishment > > tokens, not just the initial one. > > > > But until somebody tables that matter we should not consider > > RFC1964/4121 as imposing such a requirement on other mechanism that use > > different mechanism OIDs. > > Require, because it will amount to less code, less complexity and less > confusion. The overhead is negligable. I don't expect any implementation > of PKU2U to NOT provide rfc1964/rfc4121 functionality as well, despite > the seperate mechanism OID. I can't tell if RFC2478/4178 require that header on non-initial SPNEGO context tokens, but our implementation does NOT put it on any SPNEGO context token other than the initial one. Did we miss this? This requirement, if we wanted to make it, would have to apply only to future Standards-Track mechs. > > That said, there's this interesting question: PKU2U re-uses RFC4121 for > > everything following PKU2U's first two security context tokens (which > > are KDC messages between the initiator and the acceptor acting as a > > pseudo-KDC), so, should those context tokens lifted from RFC4121 bear > > this header? > > I really want to see the generic framing on all context level tokens > (which is what you meant by header, I assume). Yes, that's what I meant by 'header'. > Could it be that you actually didn't want to ask about the framing, > but about the mechanism OID within the header (if it is present)? No. > I'd like to see the generic framing, and I'd like to see it with > the same mechanism OID as in the initial context token (which is > different from rfc1964/rfc2141). Yes, if the generic header is on all context tokens then the same OID has to be used for all those context tokens for any given security context. Nico -- _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Thu Apr 19 10:16:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeXR9-0003CF-AG; Thu, 19 Apr 2007 10:16:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeXR7-0003Bu-Vo; Thu, 19 Apr 2007 10:16:37 -0400 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeXR7-0007xQ-Hy; Thu, 19 Apr 2007 10:16:37 -0400 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id QAA11705; Thu, 19 Apr 2007 16:16:21 +0200 (MESZ) From: Martin Rex Message-Id: <200704191416.l3JEGHn3002032@fs4113.wdf.sap.corp> Subject: Re: [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.txt To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Thu, 19 Apr 2007 16:16:16 +0200 (MEST) In-Reply-To: <20070418211013.GT4375@Sun.COM> from "Nicolas Williams" at Apr 18, 7 04:10:14 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: kitten@lists.ietf.org, Martin.Rex@sap.com, spkm@ietf.org, aglo@citi.umich.edu X-BeenThere: spkm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org Nicolas Williams wrote: > > On Wed, Apr 18, 2007 at 11:03:55PM +0200, Martin Rex wrote: > > > We should probably consider whether we want to RECOMMEND, or even > > > REQUIRE that that header be added to all security context establishment > > > tokens, not just the initial one. > > > > > > But until somebody tables that matter we should not consider > > > RFC1964/4121 as imposing such a requirement on other mechanism that use > > > different mechanism OIDs. > > > > Require, because it will amount to less code, less complexity and less > > confusion. The overhead is negligable. I don't expect any implementation > > of PKU2U to NOT provide rfc1964/rfc4121 functionality as well, despite > > the seperate mechanism OID. > > I can't tell if RFC2478/4178 require that header on non-initial SPNEGO > context tokens, but our implementation does NOT put it on any SPNEGO > context token other than the initial one. Did we miss this? > > This requirement, if we wanted to make it, would have to apply only to > future Standards-Track mechs. That requirement *DID* exist in rfc-2478. So there seems to be a completely backwards incompatible change in rfc-4178. At least rfc-4178 is very explicit what it wants in 4.2. Rfc2478 was always meant to use the generic framing on all context tokens (they're called "negotiation tokens"). It's true that this is not explicitly spelled out, but at the time when rfc-2478 was produced, both of the gss-api mechanism in the IETF/CAT discussion (rfc-1964 Kerberos 5, rfc-2025 SPKM) was using the generic framing on all of the tokens (context level AND per-message tokens), and the little words about the issue in rfc-2478: 3.2.1. Syntax This section specifies the syntax of the corresponding "innerContextToken" field for the first token and subsequent negotiation tokens. During the mechanism negociation, the "innerContextToken" field contains the ASN.1 structure "NegociationToken" given below, encoded using the DER encoding conventions. talks about "innerContextToken" for the first **AND** subsequent negotiation tokens, which implies that all negotiation (=context level) tokens are built in the same fashion an all carry the generic framing. I thought there was an interop of SPNEGO-implementations a while ago-- I would have expected this issue to become apparent if it was ambiguous, provided that there are truely independent implementations of _the_spec_. In TLS it regularly happens that there is an early adopter of a new feature and all others follow the lead instead of the spec, and as a result breaking the spec in various subtle ways (i.e. I just noticed that SSLv3 and TLS v1.0 prohibit the use of an empty CAlist in the CertificatRequest message from the server, TLS v1.1 secretly changes this in a backwards incompatible fashion without the slightest warning and OpenSSL seems to have violated the SSLv3 and TLSv1 specs from the beginning). > > > > That said, there's this interesting question: PKU2U re-uses RFC4121 for > > > everything following PKU2U's first two security context tokens (which > > > are KDC messages between the initiator and the acceptor acting as a > > > pseudo-KDC), so, should those context tokens lifted from RFC4121 bear > > > this header? > > > > I really want to see the generic framing on all context level tokens > > (which is what you meant by header, I assume). > > Yes, that's what I meant by 'header'. > > > Could it be that you actually didn't want to ask about the framing, > > but about the mechanism OID within the header (if it is present)? > > No. > > > I'd like to see the generic framing, and I'd like to see it with > > the same mechanism OID as in the initial context token (which is > > different from rfc1964/rfc2141). > > Yes, if the generic header is on all context tokens then the same OID > has to be used for all those context tokens for any given security > context. > > Nico > -- > _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Thu Apr 19 10:57:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeY4V-0004EP-2f; Thu, 19 Apr 2007 10:57:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeY4U-0004EF-7Z for spkm@ietf.org; Thu, 19 Apr 2007 10:57:18 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeY4S-0000HO-OM for spkm@ietf.org; Thu, 19 Apr 2007 10:57:18 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3JEvGZd001917 for ; Thu, 19 Apr 2007 14:57:16 GMT Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l3JEvFfO029130 for ; Thu, 19 Apr 2007 08:57:15 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l3JEuGea011318; Thu, 19 Apr 2007 09:56:16 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l3JEuFMV011317; Thu, 19 Apr 2007 09:56:15 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 19 Apr 2007 09:56:15 -0500 From: Nicolas Williams To: Martin Rex Subject: Re: [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.txt Message-ID: <20070419145614.GJ4375@Sun.COM> Mail-Followup-To: Martin Rex , lzhu@windows.microsoft.com, aglo@citi.umich.edu, spkm@ietf.org, kitten@lists.ietf.org References: <20070418211013.GT4375@Sun.COM> <200704191416.l3JEGHn3002032@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200704191416.l3JEGHn3002032@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: aglo@citi.umich.edu, spkm@ietf.org, kitten@lists.ietf.org X-BeenThere: spkm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org On Thu, Apr 19, 2007 at 04:16:16PM +0200, Martin Rex wrote: > Nicolas Williams wrote: > > I can't tell if RFC2478/4178 require that header on non-initial SPNEGO > > context tokens, but our implementation does NOT put it on any SPNEGO > > context token other than the initial one. Did we miss this? > > > > > This requirement, if we wanted to make it, would have to apply only to > > future Standards-Track mechs. > > That requirement *DID* exist in rfc-2478. So there seems to be > a completely backwards incompatible change in rfc-4178. > At least rfc-4178 is very explicit what it wants in 4.2. > > Rfc2478 was always meant to use the generic framing on all context > tokens (they're called "negotiation tokens"). It's true that this > is not explicitly spelled out, but at the time when rfc-2478 was > produced, both of the gss-api mechanism in the IETF/CAT discussion > (rfc-1964 Kerberos 5, rfc-2025 SPKM) was using the generic framing > on all of the tokens (context level AND per-message tokens), and > the little words about the issue in rfc-2478: > > 3.2.1. Syntax > > This section specifies the syntax of the corresponding > "innerContextToken" field for the first token and subsequent > negotiation tokens. During the mechanism negociation, the > "innerContextToken" field contains the ASN.1 structure > "NegociationToken" given below, encoded using the DER encoding > conventions. > > talks about "innerContextToken" for the first **AND** subsequent > negotiation tokens, which implies that all negotiation (=context level) > tokens are built in the same fashion an all carry the generic framing. I don't agree with that reading of the text. Regardless, if there are posts on the old CAT list about this saying that the generic framing is expected on non-initial context tokens then I agree that RFC4178 made a change. But we can't all be reading mailing lists from years ago -- RFCs shouldn't miss such things, and RFC2478 was missing a lot of details (e.g., what ASN.1 encoding to use). > I thought there was an interop of SPNEGO-implementations a while ago-- > I would have expected this issue to become apparent if it was ambiguous, > provided that there are truely independent implementations of _the_spec_. There truly independent implementations of _RFC4178_ were tested. Nico -- _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Thu Apr 19 11:54:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeYxr-0004ap-JP; Thu, 19 Apr 2007 11:54:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeYxp-0004aZ-HO; Thu, 19 Apr 2007 11:54:29 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeYxm-00080j-3O; Thu, 19 Apr 2007 11:54:29 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id RAA00774; Thu, 19 Apr 2007 17:54:16 +0200 (MESZ) From: Martin Rex Message-Id: <200704191552.l3JFqNWE008872@fs4113.wdf.sap.corp> Subject: Re: [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.txt To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Thu, 19 Apr 2007 17:52:23 +0200 (MEST) In-Reply-To: <20070419145614.GJ4375@Sun.COM> from "Nicolas Williams" at Apr 19, 7 09:56:15 am 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: 25620135586de10c627e3628c432b04a Cc: kitten@lists.ietf.org, spkm@ietf.org X-BeenThere: spkm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org Nicolas Williams wrote: > > On Thu, Apr 19, 2007 at 04:16:16PM +0200, Martin Rex wrote: > > Nicolas Williams wrote: > > > I can't tell if RFC2478/4178 require that header on non-initial SPNEGO > > > context tokens, but our implementation does NOT put it on any SPNEGO > > > context token other than the initial one. Did we miss this? > > > > > > > > This requirement, if we wanted to make it, would have to apply only to > > > future Standards-Track mechs. > > > > That requirement *DID* exist in rfc-2478. So there seems to be > > a completely backwards incompatible change in rfc-4178. > > At least rfc-4178 is very explicit what it wants in 4.2. > > [...] > > I thought there was an interop of SPNEGO-implementations a while ago-- > > I would have expected this issue to become apparent if it was ambiguous, > > provided that there are truely independent implementations of _the_spec_. > > There truly independent implementations of _RFC4178_ were tested. As I said, rfc-4178 is very explicit what it wants in section 4.2. and this fact is highly appreciated. I would have expected this backwards incompatible change to become apparent when interop-testing backwards compatibility with exiting (i.e. legacy) implementations of SPNEGO. SPNEGO started out as SNEGO (without the handshake protection and without the optimistic token), and IIRC there (once) was a sample implementation of SNEGO by Bull announced by Denis Pinkas: From: pinkas@emsc.frcl.bull.fr (Denis Pinkas) Message-Id: <9602271637.AA23945@emsc.frcl.bull.fr> Subject: Simple GSS-API negotiation available To: cat-ietf@mit.edu (IETF CAT WG) Date: Tue, 27 Feb 1996 17:37:43 +0100 (NFT) An implementation of the Simple GSS-API negotiation mechanism (Internet-Draft draft-ietf-cat-snego-01.txt, 19 February 1996) is now available at the following URL : ftp://ftp.enst-bretagne.fr/pub/security/gssneg.tar.gz It uses SNACC 1.1 libraries for encoding and decoding of PDUs described in ASN.1. The SNACC compiler can be found at: Unfortunately, that "reference" implementation appears to be no longer available anywhere. Anyway -- there seemed to be very few independent implementations of rfc-2478 and only one implementation with a significant installed base. Personally, I never liked SPNEGO, and the claimed abiguities in rfc-2748 seemed to cause a certain amount of interoperability problems anyway, so I think it is OK if rfc-4178 prefers interoperability with a significant installed base to interoperability with rfc-2478. When a feature of a revised spec is significantly clarified over the previous version of the spec, a backwards interoperability warning should be added. This is missing in rfc-4178 4.2. -Martin _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Thu Apr 19 12:09:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeZC3-0004Wu-P5; Thu, 19 Apr 2007 12:09:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeZC3-0004UR-BE for spkm@ietf.org; Thu, 19 Apr 2007 12:09:11 -0400 Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeZC1-0003P4-WC for spkm@ietf.org; Thu, 19 Apr 2007 12:09:11 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l3JG95fQ010807 for ; Thu, 19 Apr 2007 16:09:09 GMT Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l3JG95aI012922 for ; Thu, 19 Apr 2007 10:09:05 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l3JG86nn011408; Thu, 19 Apr 2007 11:08:06 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l3JG86YF011407; Thu, 19 Apr 2007 11:08:06 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 19 Apr 2007 11:08:05 -0500 From: Nicolas Williams To: Martin Rex Subject: Re: [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.txt Message-ID: <20070419160805.GO4375@Sun.COM> Mail-Followup-To: Martin Rex , spkm@ietf.org, kitten@lists.ietf.org References: <20070419145614.GJ4375@Sun.COM> <200704191552.l3JFqNWE008872@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200704191552.l3JFqNWE008872@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: kitten@lists.ietf.org, spkm@ietf.org X-BeenThere: spkm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org On Thu, Apr 19, 2007 at 05:52:23PM +0200, Martin Rex wrote: > When a feature of a revised spec is significantly clarified over the > previous version of the spec, a backwards interoperability warning > should be added. This is missing in rfc-4178 4.2. It is certainly not missing from where it belongs -- see RFC 4178, Appendix C: ... The working group was not aware of any RFC 2478 implementations deployed on the Internet. Even if there are such implementations, it is unlikely that they will inter-operate because of a critical flaw in the description of the encoding of the mechanism list in RFC 2478. With the approach taken in this specification, security is ensured between new implementations all the time while maintaining interoperability with the implementations deployed within the IETF community. The working group believes that this justifies breaking compatibility with a correct implementation of RFC 2478. ... Nico -- _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm From spkm-bounces@ietf.org Thu Apr 19 13:18:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeaGn-00034x-2I; Thu, 19 Apr 2007 13:18:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeaGl-00033k-19; Thu, 19 Apr 2007 13:18:07 -0400 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeaGj-0000ko-K5; Thu, 19 Apr 2007 13:18:07 -0400 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id TAA25445; Thu, 19 Apr 2007 19:18:01 +0200 (MESZ) From: Martin Rex Message-Id: <200704191718.l3JHI22h015497@fs4113.wdf.sap.corp> Subject: Re: [SPKM] Re: FW: I-D ACTION:draft-zhu-pku2u-01.txt To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Thu, 19 Apr 2007 19:18:02 +0200 (MEST) In-Reply-To: <20070419160805.GO4375@Sun.COM> from "Nicolas Williams" at Apr 19, 7 11:08:05 am 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: 8b30eb7682a596edff707698f4a80f7d Cc: Martin.Rex@sap.com, spkm@ietf.org, kitten@lists.ietf.org X-BeenThere: spkm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: Low Infrastructure Public Key GSS mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spkm-bounces@ietf.org Nicolas Williams wrote: > > On Thu, Apr 19, 2007 at 05:52:23PM +0200, Martin Rex wrote: > > When a feature of a revised spec is significantly clarified over the > > previous version of the spec, a backwards interoperability warning > > should be added. This is missing in rfc-4178 4.2. > > It is certainly not missing from where it belongs -- see RFC 4178, > Appendix C: > > ... > The working group was not aware of any RFC 2478 implementations > deployed on the Internet. Even if there are such implementations, it > is unlikely that they will inter-operate because of a critical flaw > in the description of the encoding of the mechanism list in RFC 2478. > > With the approach taken in this specification, security is ensured > between new implementations all the time while maintaining > interoperability with the implementations deployed within the IETF > community. The working group believes that this justifies breaking > compatibility with a correct implementation of RFC 2478. > ... I disagree. As I said, I want to see a "change warning" _exactly_ where a feature or detail is (incompatibly) changed, i.e. section 4.2. not in an Appendix. The particular change is not even mentioned in the text you quoted, probably because it wasn't realized as a change by the authors and by reviewers. If a change/clarification is locally highlighted as such, it will much more likely result in adequate thought and review about the change/clarification. -Martin _______________________________________________ SPKM mailing list SPKM@ietf.org https://www1.ietf.org/mailman/listinfo/spkm