From jimsch@nwlink.com Sun May 1 19:47:00 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1586E068B for ; Sun, 1 May 2011 19:47:00 -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 mMsJP4e7vNSc for ; Sun, 1 May 2011 19:47:00 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id ECD6BE062A for ; Sun, 1 May 2011 19:46:59 -0700 (PDT) Received: from TITUS (176.120.168.69.static.onlinenw.com [69.168.120.176]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.pacifier.net (Postfix) with ESMTP id CC4D26EF13; Sun, 1 May 2011 19:46:58 -0700 (PDT) From: "Jim Schaad" To: "'Sam Hartman'" References: <009301cc0065$94173eb0$bc45bc10$@nwlink.com> <009601cc0498$aad5f330$0081d990$@nwlink.com> <000001cc0610$f924e590$eb6eb0b0$@nwlink.com> In-Reply-To: Date: Sun, 1 May 2011 19:46:00 -0700 Message-ID: <009201cc0873$12b3b450$381b1cf0$@nwlink.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI0AuynjYFFecPcDkHdzLf/dRaImAHIzFAvAl0dqKsCYbRNCAKa6LxpARe9KRyTVwoq4A== Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] Comments on draft-lear-abfab-arch-02 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 02:47:00 -0000 > -----Original Message----- > From: Sam Hartman [mailto:hartmans@painless-security.com] > Sent: Friday, April 29, 2011 4:04 AM > To: Jim Schaad > Cc: abfab@ietf.org; 'Eliot Lear' > Subject: Re: [abfab] Comments on draft-lear-abfab-arch-02 > > >>>>> "Jim" == Jim Schaad writes: > > > It's absolutely critical for mutual authentication that we have EAP channel > binding. That goes between the peer/initiator/subject and the IDP/EAP > server. > That is independent of GSS channel binding which goes between the > initiator/subject/peer and the RP/acceptor. > > > > Jim> Jim> Since we don't have the channel binding data for the IdP to > Jim> compare unless the channel is going to produce it. There is no > Jim> channel binding data from the GSS-EAP mechanism until the MSK > Jim> is created. This would not be an issue if we were comparing > Jim> text names, but then we have the issue of the difference > Jim> between the DNS name used by the client and the AAAA realm name > Jim> used by the RP. > > > OK, so we also have confusion about channels. EAP channel binding > describes properties of the EAP lower layer--in our case the GSS exchange. > The attributes we care about with regard to this channel are (at least so far) > the acceptor name. > > The other channel, over which we apply GSS channel binding, is between the > subject and RP. That's the channel that might be TLS. There', the attributes > we care about are things like the server certificate or the hash of the finish > messages. > > GSS and EAP channel binding are even more different than is implied so far. > It's not just that the channel is different and the attributes we're talking > about are different. GSS channel binding is intended to detect a man-in-the- > middle attack. EAP channel binding does make sure that both ends of a > connection have a consistent idea of naming. > However it's not really about detecting man in the middle attacks, but more > about maintaining consistency in a complex multi-party system. > > Continual apologies for the terminology confusion. The EAP and GSS > communities independently came up with the term channel binding and > didn't realize the conflict until it was well established in both communities. > > --Sam I think that I am getting some of the terms straight. What I think I have problems with is the requirements and points at which things occur. The following is a list of the "channels" that I believe exist in the current abfab architecture (Please forgive the names that I am using as they are made up on the spot): 1. Client to RP transport channel - This would be the TLS channel that exists between the client and the RP. The channel binding material is provided by any certificates and the final message (i.e. a cryptographic token for the channel). This will normally be either a one-way authentication of identity (i.e. the client knows who the RP is) or a zero-way authentication of identity (i.e. anonymous on both sides). It could be a mutual authentication, but in that case there would be no reason to involve the entire abfab architecture except potentially for assignment of privileges. 2. Client to RP GSS-API channel - This is slightly weird to think of as a channel as it is going to be a channel between the requestor and the acceptor, but the keying material is provided by a "third party" to both entities. (My understanding is that the client can derive this material on its own, but the RP gets the material from the IdP.) There is no cryptographic binding on this channel until the EAP processing has totally finished and the MSK is transferred from the IdP to the RP - i.e. after the client/IdP authentication has completed. 3. RP to IdP channel - This is the weakest of the communication channels in terms of authentication and security. Most of these hops are going to be point-to-point and anybody in the middle can play with the data that is being transferred in either direction. The base architecture is responsible for providing any authentication assurances between the RP and the IdP. All authentication is fully established prior to the EAP conversation between the client and the IdP. 4. Client to IdP - This is the EAP channel. It has the strongest mutual authentication between that exists. We have stated that the IdP is responsible during this processing to determine that the RP that is communication to the client over channel #3 (Rp to IdP) and the one talking between the client the RP (channel #1?) are going to be the same entity as the client provides the IdP it's version of the RP name during the EAP conversation. Thus it needs to reconcile the name forms between channel #1 and channel #3 during this authentication process. At this point channel #2 and channel #4 are known to have cryptographic protections. Channel #1 and channel #3 may or may not have cryptographic protections. We need to specify what level of services are provided in these channels and how important those services are. Jim From hartmans@painless-security.com Mon May 2 05:46:21 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E905E072D for ; Mon, 2 May 2011 05:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.807 X-Spam-Level: X-Spam-Status: No, score=-2.807 tagged_above=-999 required=5 tests=[AWL=-0.542, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 AKZuw-X4bZH4 for ; Mon, 2 May 2011 05:46:21 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 07FB1E06BA for ; Mon, 2 May 2011 05:46:20 -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 244562033D; Mon, 2 May 2011 08:42:35 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6B19F41F4; Mon, 2 May 2011 08:46:19 -0400 (EDT) From: Sam Hartman To: "Jim Schaad" References: <009301cc0065$94173eb0$bc45bc10$@nwlink.com> <009601cc0498$aad5f330$0081d990$@nwlink.com> <000001cc0610$f924e590$eb6eb0b0$@nwlink.com> <009201cc0873$12b3b450$381b1cf0$@nwlink.com> Date: Mon, 02 May 2011 08:46:19 -0400 In-Reply-To: <009201cc0873$12b3b450$381b1cf0$@nwlink.com> (Jim Schaad's message of "Sun, 1 May 2011 19:46:00 -0700") 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 Cc: abfab@ietf.org Subject: Re: [abfab] Comments on draft-lear-abfab-arch-02 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 12:46:21 -0000 >>>>> "Jim" == Jim Schaad writes: Jim> 3. RP to IdP channel - This is the weakest of the Jim> communication channels in terms of authentication and security. Jim> Most of these hops are going to be point-to-point and anybody Jim> in the middle can play with the data that is being transferred Jim> in either direction. The base architecture is responsible for Jim> providing any authentication assurances between the RP and the Jim> IdP. All authentication is fully established prior to the EAP Jim> conversation between the client and the IdP. Note that with RADSEC this may be much stronger than you describe. In particular you can have a one-hop mutually authenticated channel between the RP and IDP if your deployment architecture has a suitable PKI and you do not require intermediate nodes. Going quite that far is not something Moonshot is focusing on: we expect that at least one intermediate within the RP organization will be required for our deployments. However I believe ABFAB should support this deployment. Jim> 4. Client to IdP - This is the EAP channel. It has the Jim> strongest mutual authentication between that exists. We have Jim> stated that the IdP is responsible during this processing to Jim> determine that the RP that is communication to the client over Jim> channel #3 (Rp to IdP) and the one talking between the client Jim> the RP (channel #1?) are going to be the same entity as the Jim> client provides the IdP it's version of the RP name during the Jim> EAP conversation. Thus it needs to reconcile the name forms Jim> between channel #1 and channel #3 during this authentication Jim> process. No it reconciles names from channel #2 (GSS) with channel #3 (RP to IDP). Channel #1 may not exist. If channel #1 exists channel #2 is responsible for reconciling channel #1 and channel #2. The IDP never knows about channel #1. Jim> At this point channel #2 and channel #4 are known to have Jim> cryptographic protections. Channel #1 and channel #3 may or Jim> may not have cryptographic protections. We need to specify Jim> what level of services are provided in these channels and how Jim> important those services are. we assume that channel #3 provides integrity and while this assumption is unrealistic in some deployments we assume that channel #3 provides confidentiality of the MSK. From nico@cryptonector.com Mon May 2 08:35:28 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04805E06E7 for ; Mon, 2 May 2011 08:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=-0.534, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 tO2jCdhlK-XN for ; Mon, 2 May 2011 08:35:26 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id E0969E0651 for ; Mon, 2 May 2011 08:35:26 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 7C652B805B for ; Mon, 2 May 2011 08:35:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=YPjbjppavej/vrJkZWIEDvYN+uxQ3lt1CFL00q75dPqy FsfyJ/p1X2sKTYbiUZqk5/8CcY/6GjOpug4fkItqO73Vp61w3o8Zi+VRqHGfO2GU SlWQ7ObZ8GajUd7QhNFUR2Xh/+W8TcGXW31k2l408+LN0bIV7649gFehyBAgNSU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=qyxEc7JrXbM1u7oqMoDnE5esHdU=; b=MmSsJNzl8KT uUUt2i51tUJoMpUXa07dfv3whhhHMooHxvo4/gN4JEabfGsHzi/08tcR+uF5X1Z7 ZVbQDQALhL9kIgAvtqPTq/RhMMKJJPuS/D95VpgkT1YrlnqQ2KHR4OgbYa0v7WL4 zNweEqheYxUWueLIlFibN6uUOwIeqFSU= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id 4610AB8057 for ; Mon, 2 May 2011 08:35:25 -0700 (PDT) Received: by vws12 with SMTP id 12so5040493vws.31 for ; Mon, 02 May 2011 08:35:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.116.33 with SMTP id jt1mr4926140vdb.249.1304350524548; Mon, 02 May 2011 08:35:24 -0700 (PDT) Received: by 10.52.163.71 with HTTP; Mon, 2 May 2011 08:35:24 -0700 (PDT) In-Reply-To: <009201cc0873$12b3b450$381b1cf0$@nwlink.com> References: <009301cc0065$94173eb0$bc45bc10$@nwlink.com> <009601cc0498$aad5f330$0081d990$@nwlink.com> <000001cc0610$f924e590$eb6eb0b0$@nwlink.com> <009201cc0873$12b3b450$381b1cf0$@nwlink.com> Date: Mon, 2 May 2011 10:35:24 -0500 Message-ID: From: Nico Williams To: Jim Schaad Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: abfab@ietf.org Subject: Re: [abfab] Comments on draft-lear-abfab-arch-02 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 15:35:28 -0000 On Sun, May 1, 2011 at 9:46 PM, Jim Schaad wrote: > The following is a list of the "channels" that I believe exist in the > current abfab architecture =C2=A0(Please forgive the names that I am usin= g as > they are made up on the spot): > > 1. =C2=A0Client to RP transport channel - This would be the TLS channel t= hat > exists between the client and the RP. =C2=A0The channel binding material = is > provided by any certificates and the final message (i.e. a cryptographic Final TLS Finished message, the exact details being in RFC5929 :) > token for the channel). =C2=A0This will normally be either a one-way > authentication of identity (i.e. the client knows who the RP is) or a > zero-way authentication of identity (i.e. anonymous on both sides). =C2= =A0It > could be a mutual authentication, but in that case there would be no reas= on > to involve the entire abfab =C2=A0architecture except potentially for ass= ignment > of privileges. Correct: ABFAB should not concern itself at all with what authentication, if any, takes place at this layer. RFC5056 channel binding gives you this luxury of not having to require authentication at the lower layer. > 2. =C2=A0Client to RP GSS-API channel - This is slightly weird to think o= f as a > channel as it is going to be a channel between =C2=A0the requestor and th= e > acceptor, but the keying material is provided by a "third party" to both > entities. =C2=A0(My understanding is that the client can derive this mate= rial on > its own, but the RP gets the material from the IdP.) =C2=A0There is no > cryptographic binding on this channel until the EAP processing has totall= y > finished and the MSK is transferred from the IdP to the RP - i.e. after t= he > client/IdP authentication has completed. A GSS-API security context can represent a channel, yes. If its per-message tokens are used at all to protect application data (as opposed to, say, constructing a channel binding operation), then it is a channel properly in the RFC5056 sense. The GSS security context here is at the highest layer, and since we want to use it only for authentication and channel binding to a lower layer. There's nothing to bind to it. We could conceivably use GSS security contexts in lower layers and have other higher layers bind to a GSS channel, and we know how to define the channel bindings for GSS channels too -- it just hasn't come up yet. > 3. =C2=A0RP to IdP channel - This is the weakest of the communication cha= nnels in > terms of authentication and security. =C2=A0Most of these hops are going = to be > point-to-point and anybody in the middle can play with the data that is > being transferred in either direction. =C2=A0The base architecture is res= ponsible > for providing any authentication assurances between the RP and the IdP. = =C2=A0All > authentication is fully established prior to the EAP conversation between > the client and the IdP. These are channels, indeed. When we speak of channel binding we generally refer to end-to-end channels between ends of interest (or end-to-end channels between trusted proxies for the actual ends), so that in the context of the "client" and "RP", these are not channels of interest, whereas in the context of the "RP" and "IdP" they are. Context is everything :) (This is not a correction though. You're quite right that these are channels.) > 4. Client to IdP - This is the EAP channel. =C2=A0It has the strongest mu= tual > authentication between that exists. =C2=A0We have stated that the IdP is > responsible during this processing to determine that the RP that is > communication to the client over channel #3 (Rp to IdP) and the one talki= ng > between the client the RP (channel #1?) are going to be the same entity a= s > the client provides the IdP it's version of the RP name during the EAP > conversation. =C2=A0Thus it needs to reconcile the name forms between cha= nnel #1 > and channel #3 during this authentication process. As Sam explains, it's channels #2 and #3 that channel #4 reconciles. Channel #1, if it exists, is bound in via RFC5056 channel binding, which means that we do not concern ourselves at all with what forms of authentication take place in channel #1, if any -- we only concern ourselves with the characteristics of channel #1 (resistant to MITMs when bound into channel #2, provides the desired level of cryptographic protection to application data, and so on). Well, there is one way in which we might care about what authentication channel #1 provides: we might use the channel binding operation to decide that, there not being any MITMs in channel #1, whatever RP authentication channel #1 provided can be trusted in the future. I.e., we can use channel binding to learn the RP's TLS server cert and treat it as pre-shared so that in the future we can trust that cert much more than we might have if all we had was the TLS "PKI". This is nice, but hardly necessary. > At this point channel #2 and channel #4 are known to have cryptographic > protections. =C2=A0Channel #1 and channel #3 may or may =C2=A0not have cr= yptographic > protections. =C2=A0We need to specify what level of services are provided= in > these channels and how important those services are. The application at the client and RP decide what characteristics channel #1 must have (e.g., whether or not it must provide confidentiality protection). The client has nothing to do with channel #3 and cannot have any say in it. The {client, IdP} and {RP, IdPs} get to decide what characteristics channels #3 and #4, respectively, must have. Applications might even involve multiple RPs (think of something like SIP), in which case there may be many instances of each of these channels that you've identified. In that case the analysis is complicated by the number of instances of channels, but by and large the analysis will take the same form: what are the end-points of the channels, what characteristics must they have, who decides what those must be, whether there's any channel binding, and from what channel to what channel, finally leaving us with a set of channels that we agree "speak for" specific end pairs. One key idea is to neatly demarcate cryptographic analysis such that we need only analyze: a) each channel standing alone, b) each channel's channel bindings data definition, if we need it, c) each channel's channel binding operation definition, if we need it. We still need to analyze the whole, but we do not need to apply any cryptographic protocol analysis to the whole from scratch -- instead we build the analysis of the whole from the analysis of building blocks. This is, ultimately, the most important feature of channel binding: it is a channel composition tool that allows us to simplify design _and_ *analysis*. Coming back to ABFAB to wrap up the analysis. GSS applications using the GSS-EAP mechanism will not need to concern themselves with any details of channels #3 and #4 except for the authenticated client (initiator) and RP (acceptor) names that are produced by the IdPs. The IdPs need not concern themselves with any details of channel #1 (though the IdPs might be involved in the channel binding operation, but since the channel bindings data are opaque...). The GSS-EAP mechanism itself does need to concern itself intimately with the details of channels #3 (on the initiator and IdP sides) and #4 (on the acceptor and IdP sides), but not with channel #1 (again, channel #1's channel bindings data are opaque to the GSS mechanism). Nico -- From hartmans@painless-security.com Mon May 2 08:59:59 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4677EE06F8 for ; Mon, 2 May 2011 08:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 XhnouePcLxeW for ; Mon, 2 May 2011 08:59:58 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id C7BA3E06F3 for ; Mon, 2 May 2011 08:59:58 -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 B7FDB202C9 for ; Mon, 2 May 2011 11:56:10 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E472541F4; Mon, 2 May 2011 11:59:54 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org References: <009301cc0065$94173eb0$bc45bc10$@nwlink.com> <009601cc0498$aad5f330$0081d990$@nwlink.com> <000001cc0610$f924e590$eb6eb0b0$@nwlink.com> <009201cc0873$12b3b450$381b1cf0$@nwlink.com> Date: Mon, 02 May 2011 11:59:54 -0400 In-Reply-To: (Nico Williams's message of "Mon, 2 May 2011 10:35:24 -0500") 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: Re: [abfab] Comments on draft-lear-abfab-arch-02 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 15:59:59 -0000 This conversation is starting to yield a lot of useful information. Does someone want to take an action item to write this up for the architecture document? From lukeh@padl.com Fri May 20 04:57:18 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24B36E06FE for ; Fri, 20 May 2011 04:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.424 X-Spam-Level: X-Spam-Status: No, score=-3.424 tagged_above=-999 required=5 tests=[AWL=-0.825, BAYES_00=-2.599] 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 Pmmmp5hg9zdd for ; Fri, 20 May 2011 04:57:17 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 9966EE065D for ; Fri, 20 May 2011 04:57:17 -0700 (PDT) Received: by us.padl.com with ESMTP id p4KBvBOi019982; Fri, 20 May 2011 07:57:15 -0400 From: Luke Howard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 20 May 2011 13:57:10 +0200 Message-Id: <79AA0F35-87D1-426C-9C1D-03C8BEE9F6CE@padl.com> To: abfab@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_50,RCVD_IN_PBL,RCVD_IN_SORBS_DUL X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: 0.1 Subject: [abfab] MIC on extension token X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2011 11:57:18 -0000 We went back and forth on the usefulness and implementability of the = conversation MIC in GSS EAP. Recall that it was difficult to have more = than two of hash agility, minimum state and RFC 3961 compatibility. Even = the key confirmation approach would have required changes to RFC 3961 = and many existing Kerberos libraries (because there is no Update = function). Instead I propose (well, Sam proposes and I implemented) the following. = On the initiator extension token leg (the last token from the = initiator), a MIC is sent of the mechanism OID and the extension tokens, = excluding the MIC token. The acceptor verifies it and generates a MIC of = its extension token to send to the initiator. The initiator verifies = this. This gives us protection of all extension tokens sent in the last round = trip. -- Luke= From hartmans@painless-security.com Tue May 31 07:57:27 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21179E06BB for ; Tue, 31 May 2011 07:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 ex5KTl33NUNc for ; Tue, 31 May 2011 07:57:26 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 5EED7E068E for ; Tue, 31 May 2011 07:57:26 -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 99C5C20239; Tue, 31 May 2011 10:53:07 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B84944125; Tue, 31 May 2011 10:57:15 -0400 (EDT) From: Sam Hartman To: Luke Howard References: <79AA0F35-87D1-426C-9C1D-03C8BEE9F6CE@padl.com> Date: Tue, 31 May 2011 10:57:15 -0400 In-Reply-To: <79AA0F35-87D1-426C-9C1D-03C8BEE9F6CE@padl.com> (Luke Howard's message of "Fri, 20 May 2011 13:57:10 +0200") 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 Cc: abfab@ietf.org Subject: Re: [abfab] MIC on extension token X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 14:57:27 -0000 >>>>> "Luke" == Luke Howard writes: Luke> Instead I propose (well, Sam proposes and I implemented) the Luke> following. On the initiator extension token leg (the last Luke> token from the initiator), a MIC is sent of the mechanism OID Luke> and the extension tokens, excluding the MIC token. The Luke> acceptor verifies it and generates a MIC of its extension Luke> token to send to the initiator. The initiator verifies this. Luke> This gives us protection of all extension tokens sent in the Luke> last round trip. I'd like to hear comments on this. Unless we hear objections or the editors receive different instructinos from the chairs, we will make this so in the next version of the gss-eap draft. From lukeh@padl.com Tue May 31 14:13:40 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB6F0E090B for ; Tue, 31 May 2011 14:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.929 X-Spam-Level: X-Spam-Status: No, score=-2.929 tagged_above=-999 required=5 tests=[AWL=-0.330, BAYES_00=-2.599] 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 TaA04S++9VJ3 for ; Tue, 31 May 2011 14:13:39 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id EB02FE083E for ; Tue, 31 May 2011 14:13:38 -0700 (PDT) Received: by us.padl.com with ESMTP id p4VLDY1U013931; Tue, 31 May 2011 17:13:37 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: Date: Tue, 31 May 2011 17:13:34 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <79AA0F35-87D1-426C-9C1D-03C8BEE9F6CE@padl.com> To: Sam Hartman X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL, BAYES_05, FH_HELO_EQ_D_D_D_D, HELO_DYNAMIC_IPADDR2, TVD_RCVD_IP, USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -18.9 Cc: abfab@ietf.org Subject: Re: [abfab] MIC on extension token X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 21:13:40 -0000 On 31/05/2011, at 10:57 AM, Sam Hartman wrote: >>>>>> "Luke" == Luke Howard writes: > > Luke> Instead I propose (well, Sam proposes and I implemented) the > Luke> following. On the initiator extension token leg (the last > Luke> token from the initiator), a MIC is sent of the mechanism OID > Luke> and the extension tokens, excluding the MIC token. The > Luke> acceptor verifies it and generates a MIC of its extension > Luke> token to send to the initiator. The initiator verifies this. > > Luke> This gives us protection of all extension tokens sent in the > Luke> last round trip. > > I'd like to hear comments on this. Unless we hear objections or the > editors receive different instructinos from the chairs, we will make > this so in the next version of the gss-eap draft. +1 from me. -- Luke