From jsalowey@cisco.com Mon Jun 13 13:22:12 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46D80228015 for ; Mon, 13 Jun 2011 13:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNReaq6C7Df4 for ; Mon, 13 Jun 2011 13:22:11 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id BBF04228007 for ; Mon, 13 Jun 2011 13:22:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=2976; q=dns/txt; s=iport; t=1307996531; x=1309206131; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=6JQEft7pJ9QCNjoCDLMLY3uWR94B0g9TYm7ugKRUe64=; b=UxZgoKgtXEhjh03oX4dWJtaAumLnIG929jJmNk9lNLjEAhdEEfHKpRJA DNVAHcOefLxzaRO7w4x0y9V0XbwnYDnbSh6me1zcbBbIp1TIQxVGVsMDS itqR5fZKtfwOQcEaIdVFpUYUDa/GyG6VroSkoLV7n1or1Fa1DeZNGB1Qp 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJlw9k2rRDoI/2dsb2JhbABSpjF3iHKhWJ1uhiQEhw2KJ4RPiy4 X-IronPort-AV: E=Sophos;i="4.65,360,1304294400"; d="scan'208";a="375804870" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 13 Jun 2011 20:22:11 +0000 Received: from [10.33.249.205] ([10.33.249.205]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5DKMA7P002547; Mon, 13 Jun 2011 20:22:11 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Salowey In-Reply-To: <4DE489C6.40900@net-zen.net> Date: Mon, 13 Jun 2011 13:22:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <938A8B5F-E69C-4932-83B5-C57253BC01CF@cisco.com> References: <4DCD4E3F.70601@deployingradius.com> <4DDB00BD.2050504@net-zen.net> <4DE489C6.40900@net-zen.net> To: Glen Zorn X-Mailer: Apple Mail (2.1084) Cc: "emu@ietf.org" Subject: Re: [Emu] Results of consensus call on tunnel method document X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 20:22:12 -0000 It looks like we have rough consensus for a new EAP type. I Agree, = that with a new EAP type it makes sense to start the version at 1. I = was originally thinking of the SSL 3.0 to TLS 1.0 transition where the = protocol version went from 3.0 to 3.1, but in that case TLS did not have = an equivalent code point assigned. I'll add these to the list of = changes for the next revision. =20 Cheers, Joe On May 30, 2011, at 11:25 PM, Glen Zorn wrote: > On 5/31/2011 11:08 AM, Joe Salowey wrote: >=20 >>=20 >> On May 23, 2011, at 5:50 PM, Glen Zorn wrote: >>=20 >>> On 5/24/2011 12:53 AM, Joe Salowey wrote: >>>=20 >>>> One benefit I see in keeping the same EAP method type code is it = allows secure version negotiation from v1 to v2 with version rollback = protection. =20 >>>>=20 >>>> However, moving to a new EAP type code would seem to make EAP = method negotiation somewhat better since all implementation may not = implement v1. =20 >>>>=20 >>>> I'm OK with assigning a new EAP method type code, but I'd like to = try to maintain some backward compatibility with the v1 versioning in = the case that v1=20 >>>>=20 >>>> implementations find it advantageous to negotiate the v2 feature = set under the v1 type code.=20 >>>=20 >>> None of this seems to me to be relevant to the IETF, the emu WG or = the >>> discussion at hand. =20 >>=20 >> [Joe] I would hope that negotiation of methods is relevant to the EMU = WG.=20 >=20 > Hmm. I thought we were talking about EAP-FAST version negotiation. >=20 >>=20 >>> Just to be clear, EAP-FAST is not a product of any >>> IETF WG and does not specify a standard of any kind. Furthermore, >>> regardless of the IANA type registration status, EAP-FAST is, in = fact, a >>> proprietary protocol; it's publication in RFC 4851 reflects the RFC >>> Series as a vanity press, not the IETF as a SDO. The method that = this >>> WG is developing will be a standard, however, and must not be = tethered >>> in any way to a proprietary protocol; i.e., backward compatibility = with >>> EAP-FAST. Whatever the name of the tunneled method ends up to be, = the >>> version number must be one (1). =20 >>=20 >> [Joe] A new method name would be good. =20 >=20 > A new EAP type would be better. If a new EAP type is assigned, how = does > it make sense to start the version numbering for that type @ 2? >=20 >> How the protocol evolves is up to the working group. =20 >=20 > Absolutely, but unless the rules have changed rather drastically > recently, I'm pretty sure that I'm a WG member... >=20 >>=20 >>> If a vendor wants to track the IETF >>> protocol development for whatever reason so that, for example, v2 of = its >>> protocol is equivalent to v1 of the standard then that is their = choice, >>> but enabling (let alone encouraging) that behavior is not any of our >>> concern. >>>=20 >>> ... >>> >>=20 >>=20 >>=20 > From ietf-denmike@snkmail.com Tue Jun 7 08:41:27 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E28C11E816A for ; Tue, 7 Jun 2011 08:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cj23rj9COAef for ; Tue, 7 Jun 2011 08:41:26 -0700 (PDT) Received: from sneak2.sneakemail.com (sneak2.sneakemail.com [38.113.6.65]) by ietfa.amsl.com (Postfix) with SMTP id AE45C11E8162 for ; Tue, 7 Jun 2011 08:41:25 -0700 (PDT) Received: (qmail 29613 invoked from network); 7 Jun 2011 15:41:22 -0000 Received: from unknown (HELO localhost.localdomain) (192.168.0.1) by sneak2.sneakemail.com with SMTP; 7 Jun 2011 15:41:22 -0000 Received: from 192.168.0.2 by mail.sneakemail.com with SMTP; 7 Jun 2011 15:41:22 -0000 Received: (sneakemail censored 1595-1307461282-359547 #2); 7 Jun 2011 15:41:22 -0000 Received: (sneakemail censored 1595-1307461282-359547 #1); 7 Jun 2011 15:41:22 -0000 Date: Tue, 7 Jun 2011 15:41:22 +0000 To: emu@ietf.org Message-ID: <1595-1307461282-359547@sneakemail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 From: "Michael Thomsen" X-Mailer: Perl5 Mail::Internet v X-Mailman-Approved-At: Mon, 13 Jun 2011 13:25:52 -0700 Subject: Re: [Emu] draft-urien-eap-smartcard-20.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 15:41:27 -0000 Hi Pascal, sorry, I don't quite understand what you mean by "former EAP-AKA version", but I've stumpled upon a few things I don't quite understand: 1: -- In test #2 (Wrong SQN) you're calculating MAC-S with a non-zero AMF giving 7CD924E739F12369. According to 3GPP TS 33.102 AMF is set to zeros when calculating AUTS. When doing that I get 0010C1DA38A75A31 instead. According to RFC4187 AT_AUTS should include "the AKA AUTS parameter, 112 bits" I don't see anything about the AMF field not being zeroed, as it is per usual. 2: -- In test #6 (Reauth, Good Counter) the counter value is 0000, whereas RFC4187 specifies that the minimum counter value of the first packet should be 0001. Also, you use the 64-byte MSK value generated in test #1 instead of MK, whereas RFC4187 specifies XKEY'=SHA1(Identity|counter|NONCE_S|MK). This obviously gives a quite different result than what you get. 3: -- In the "Get MSK" commands in test #1 and test #6 the first 32 bytes of MSK are switched with the last 32 bytes of MSK. I don't see anything in your document stating that this should be the behaviour. 4: -- In test #6 and test #7 the MAC is not calculated over (EAP-packet | Nounce-S), as specified in RFC4187. Kind regards, Michael Thomsen From hartmans@mit.edu Tue Jun 28 12:34:02 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F5211E8100 for ; Tue, 28 Jun 2011 12:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.432 X-Spam-Level: X-Spam-Status: No, score=-104.432 tagged_above=-999 required=5 tests=[AWL=-2.167, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6xfJW+CTk0F for ; Tue, 28 Jun 2011 12:34:02 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id EA24711E807B for ; Tue, 28 Jun 2011 12:34:00 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 64240202C9 for ; Tue, 28 Jun 2011 15:29:09 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 45C664307; Tue, 28 Jun 2011 15:33:53 -0400 (EDT) From: Sam Hartman To: emu@ietf.org Cc: Date: Tue, 28 Jun 2011 15:33:53 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Emu] Proposed changes for Channel Binding draft X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 19:34:02 -0000 Over the past couple of days I've been organizing proposed edits for the channel binding document. First, I could really use some help producing some ascii art diagrams. I think I have non-ascii-art diagrams for the packets involved; is anyone willing to step forward and help with this? Secondly, I'd like to ask the chairs' permission to revisit the encoding decision. I was uncomfortable with how rough that consensus was and despite being not in the rough, I've been trying to work through whether we're doing the right thing. A couple of things have caused me to believe that Alan is right and that encoding #2 (re-using RADIUS encoding for RADIUS AVPs) is the right approach. 1) With encoding 1 (the current text) we cannot encode an attribute value greater than 254 octets. This isn't an issue for RADIUS, but if we ever had some other attribute format it could be an issue. We all agree that 255 octets is as long (or longer) than any attribute we'd want to see in channel binding. However with overhead for things like vendor numbers, diameter attribute numbers or the like, I'm concerned that in the future we might be off by one or two octets in what we can encode vs what we need to encode. 2) I recently re-read draft-ietf-radext-radius-extensions again. RADIUS attribue naming is getting more complicated. I think there's more RADIUS-specific code to re-use. So, I'd like to ask the chairs if they believe the consensus call was close enough that they'd have a problem with me going with option #2 instead of #1 given these somewhat new reasons. If you think we're done on this issue I'm happy to go forward with #1: it's already in the document. I'm just no longer sure it's right. I'm still reasonably convinced this is not a huge issue. Besides that, we're still waiting for review of the 802.11 text. If that review does not happen by Quebec I'll ask the chairs for permission to pull that text so we can last call the framework. Specific changes I'd like to make are: 1) Update authors' addresses 2) Move the encoding to option #2 with the chairs' permission 3) Remover some references to diameter encoding that are still in the text. 4) Add ascii art. With that I believe the only open issue will be the 802.11 text. I read through the document and am quite happy with where we are. From jsalowey@cisco.com Tue Jun 28 14:10:26 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C4A21F86CB for ; Tue, 28 Jun 2011 14:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9S-y3sZaKKw for ; Tue, 28 Jun 2011 14:10:25 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3824721F86C0 for ; Tue, 28 Jun 2011 14:10:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=3145; q=dns/txt; s=iport; t=1309295425; x=1310505025; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=SX38uX1x/f9yVUiK2cOn3GSmXzEAVnBiHi95Lc0xGAI=; b=YRg0esUrqolcJpxk4z9VhTHAUU8r2cdHSSgFI4tez+tUQ2FJnxtskkXe PVMAiy/3D5Uyu/rjXb/qtPUjyQ4oUOvu6evGq04zNf4t8EUl1MPvxnP2k 1exUEWaSFv/nXGBAz/1q1LIFl5SmCm6MJtOjBwfkxqqIV5qi0G/ko2CiY o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPVCCk6rRDoJ/2dsb2JhbABTEKcyd4h3o3qeFoYwBIc0ilyEbop8Vw X-IronPort-AV: E=Sophos;i="4.65,439,1304294400"; d="scan'208";a="349234965" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 28 Jun 2011 21:10:15 +0000 Received: from [10.33.248.247] ([10.33.248.247]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5SLACTb001313; Tue, 28 Jun 2011 21:10:14 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Salowey In-Reply-To: Date: Tue, 28 Jun 2011 14:10:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <26E5ABE8-A33E-4F6F-8D8F-3C24D17E57CB@cisco.com> References: To: Sam Hartman X-Mailer: Apple Mail (2.1084) Cc: emu@ietf.org Subject: Re: [Emu] Proposed changes for Channel Binding draft X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 21:10:26 -0000 Hi Sam, I think you list some good reasons for going with encoding 2. I'm = comfortable with including this in the draft given that the document is = still going through working group review. I'll see if I can get some = help on reviewing the 802.11 text, but I think it would be OK to move = this into a separate document if it is going to hold up the main = document. =20 Cheers, Joe On Jun 28, 2011, at 12:33 PM, Sam Hartman wrote: >=20 >=20 > Over the past couple of days I've been organizing proposed edits for = the > channel binding document. >=20 > First, I could really use some help producing some ascii art diagrams. = I > think I have non-ascii-art diagrams for the packets involved; is = anyone > willing to step forward and help with this? >=20 > Secondly, I'd like to ask the chairs' permission to revisit the = encoding > decision. I was uncomfortable with how rough that consensus was and > despite being not in the rough, I've been trying to work through = whether > we're doing the right thing. >=20 > A couple of things have caused me to believe that Alan is right and = that > encoding #2 (re-using RADIUS encoding for RADIUS AVPs) is the right > approach. >=20 > 1) With encoding 1 (the current text) we cannot encode an attribute > value greater than 254 octets. This isn't an issue for RADIUS, but if = we > ever had some other attribute format it could be an issue. We all = agree > that 255 octets is as long (or longer) than any attribute we'd want to > see in channel binding. However with overhead for things like vendor > numbers, diameter attribute numbers or the like, I'm concerned that in > the future we might be off by one or two octets in what we can encode > vs what we need to encode. >=20 > 2) I recently re-read draft-ietf-radext-radius-extensions again. = RADIUS > attribue naming is getting more complicated. I think there's more > RADIUS-specific code to re-use. >=20 > So, I'd like to ask the chairs if they believe the consensus call was > close enough that they'd have a problem with me going with option #2 > instead of #1 given these somewhat new reasons. > If you think we're done on this issue I'm happy to go forward with #1: > it's already in the document. I'm just no longer sure it's right. > I'm still reasonably convinced this is not a huge issue. >=20 > Besides that, we're still waiting for review of the 802.11 text. If = that > review does not happen by Quebec I'll ask the chairs for permission to > pull that text so we can last call the framework. >=20 > Specific changes I'd like to make are: >=20 > 1) Update authors' addresses >=20 > 2) Move the encoding to option #2 with the chairs' permission >=20 > 3) Remover some references to diameter encoding that are still in the > text. >=20 > 4) Add ascii art. >=20 > With that I believe the only open issue will be the 802.11 text. I = read > through the document and am quite happy with where we are. > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From khoeper@motorolasolutions.com Tue Jun 28 15:30:50 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC17011E818C for ; Tue, 28 Jun 2011 15:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZqFjLdZToSZ for ; Tue, 28 Jun 2011 15:30:50 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id A3B5D21F8545 for ; Tue, 28 Jun 2011 15:30:10 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: khoeper@motorolasolutions.com X-Msg-Ref: server-12.tower-119.messagelabs.com!1309300208!26494379!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [136.182.1.13] Received: (qmail 5849 invoked from network); 28 Jun 2011 22:30:09 -0000 Received: from motgate3.mot-solutions.com (HELO motgate3.mot-solutions.com) (136.182.1.13) by server-12.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Jun 2011 22:30:09 -0000 Received: from il27exr01.cig.mot.com ([10.17.196.70]) by motgate3.mot-solutions.com (8.14.3/8.14.3) with ESMTP id p5SMU7kL027975 for ; Tue, 28 Jun 2011 15:30:08 -0700 (MST) Received: from il27exr01.cig.mot.com (il27vts03.cig.mot.com [10.17.196.87]) by il27exr01.cig.mot.com (8.13.1/Vontu) with ESMTP id p5SMU7bw004269 for ; Tue, 28 Jun 2011 17:30:07 -0500 (CDT) Received: from de01exm68.ds.mot.com (de01exm68.am.mot.com [10.176.8.24]) by il27exr01.cig.mot.com (8.13.1/8.13.0) with ESMTP id p5SMU7C7004256 for ; Tue, 28 Jun 2011 17:30:07 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Jun 2011 18:29:45 -0400 Message-ID: <3A241A6B234BE948B8B474D261FEBC2F06A82D4F@de01exm68.ds.mot.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Proposed changes for Channel Binding draft Thread-Index: Acw1yltOQjxmTGC1R0eim3cPC2VO7QAGABCQ References: From: "Hoeper Katrin-QWKN37" To: "Sam Hartman" , X-CFilter-Loop: Reflected Subject: Re: [Emu] Proposed changes for Channel Binding draft X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 22:30:51 -0000 Hi Sam, I volunteer to create the ascii-art diagrams. Please send me your files, including existing images. Katrin PS: My new contact info Katrin Hoeper Motorola Solutions, Inc 1301 E Algonquin Rd Schaumburg, IL 60196 USA khoeper@motorolasolutions.com -----Original Message----- From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of Sam Hartman Sent: Tuesday, June 28, 2011 2:34 PM To: emu@ietf.org Subject: [Emu] Proposed changes for Channel Binding draft Over the past couple of days I've been organizing proposed edits for the channel binding document. First, I could really use some help producing some ascii art diagrams. I think I have non-ascii-art diagrams for the packets involved; is anyone willing to step forward and help with this? Secondly, I'd like to ask the chairs' permission to revisit the encoding decision. I was uncomfortable with how rough that consensus was and despite being not in the rough, I've been trying to work through whether we're doing the right thing. A couple of things have caused me to believe that Alan is right and that encoding #2 (re-using RADIUS encoding for RADIUS AVPs) is the right approach. 1) With encoding 1 (the current text) we cannot encode an attribute value greater than 254 octets. This isn't an issue for RADIUS, but if we ever had some other attribute format it could be an issue. We all agree that 255 octets is as long (or longer) than any attribute we'd want to see in channel binding. However with overhead for things like vendor numbers, diameter attribute numbers or the like, I'm concerned that in the future we might be off by one or two octets in what we can encode vs what we need to encode. 2) I recently re-read draft-ietf-radext-radius-extensions again. RADIUS attribue naming is getting more complicated. I think there's more RADIUS-specific code to re-use. So, I'd like to ask the chairs if they believe the consensus call was close enough that they'd have a problem with me going with option #2 instead of #1 given these somewhat new reasons. If you think we're done on this issue I'm happy to go forward with #1: it's already in the document. I'm just no longer sure it's right. I'm still reasonably convinced this is not a huge issue. Besides that, we're still waiting for review of the 802.11 text. If that review does not happen by Quebec I'll ask the chairs for permission to pull that text so we can last call the framework. Specific changes I'd like to make are: 1) Update authors' addresses 2) Move the encoding to option #2 with the chairs' permission 3) Remover some references to diameter encoding that are still in the text. 4) Add ascii art. With that I believe the only open issue will be the 802.11 text. I read through the document and am quite happy with where we are. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu