From stefan.winter@restena.lu Mon Jun 6 02:03:16 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 D933C11E808F for ; Mon, 6 Jun 2011 02:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 DOHbKEh2-drh for ; Mon, 6 Jun 2011 02:03:15 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 1C06711E808E for ; Mon, 6 Jun 2011 02:03:14 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 52DF910584 for ; Mon, 6 Jun 2011 11:03:12 +0200 (CEST) Received: from [IPv6:2001:a18:1:8::155] (unknown [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 3CA6D10086 for ; Mon, 6 Jun 2011 11:03:12 +0200 (CEST) Message-ID: <4DEC97D0.9080608@restena.lu> Date: Mon, 06 Jun 2011 11:03:12 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: abfab@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig936BE4739CEC367A3ADEEE8F" X-Virus-Scanned: ClamAV Subject: [abfab] Work Item: Update to the EAP Applicability Statement 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, 06 Jun 2011 09:03:17 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig936BE4739CEC367A3ADEEE8F Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hello, I foolishly volunteered to draft an update to the EAP applicability statement. With the help of very knowledgable people, in particular Joe Salowey and Sam Hartman, I made an initial attempt: http://tools.ietf.org/html/draft-winter-abfab-eapapplicability-00 This obviously isn't perfect, and I would welcome comments of any sort (including, but not limited to, offers for text and/or co-authorship :-) = ). Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig936BE4739CEC367A3ADEEE8F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3sl9AACgkQ+jm90f8eFWZPQQCeNco2lYT69WGPhtt8zyJ1guyz jPQAnRFCYBKnYq7AHFXUYNAlVaMXCLmO =VDDI -----END PGP SIGNATURE----- --------------enig936BE4739CEC367A3ADEEE8F-- From alper.yegin@yegin.org Mon Jun 6 03:20:45 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 556BD11E8106 for ; Mon, 6 Jun 2011 03:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.15 X-Spam-Level: X-Spam-Status: No, score=-101.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, 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 r-1tu3vGA8Ld for ; Mon, 6 Jun 2011 03:20:44 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA7211E80FD for ; Mon, 6 Jun 2011 03:20:44 -0700 (PDT) Received: from ibm (dsl88-247-34762.ttnet.net.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MKpbM-1QTWvH2UZU-000DA0; Mon, 06 Jun 2011 06:20:42 -0400 From: "Alper Yegin" To: "'Stefan Winter'" , References: <4DEC97D0.9080608@restena.lu> In-Reply-To: <4DEC97D0.9080608@restena.lu> Date: Mon, 6 Jun 2011 13:20:34 +0300 Message-ID: <003301cc2433$62e1f7d0$28a5e770$@yegin@yegin.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcwkKJQqNvevxSZLTqGZKPrBekt7BwABuPZA Content-Language: en-us X-Provags-ID: V02:K0:JZqHQ4jq29FgLWvKcYj05aFzfncf3c5hs+lZw4pElDJ 18Xqlqqh0WU/qM6qcrGDLDfof0/aa7ofulLnLETbYvaQipRjTm h76HS320RJot6sl1+6BKgX0TSS5fnY1joIOI/x5K+2/C3QTo+M VbTvt2jmFKoRDfORl2VgO4KD3hFjWkIq0uIwekRMA/iLL6chie prUYpbxJPAUd0+x/KgLlEXLCMLHRVv/XbuwXuSqQE0= Subject: Re: [abfab] Work Item: Update to the EAP Applicability Statement 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, 06 Jun 2011 10:20:45 -0000 Hi Stefan, Here are few comments: "2.1. Communication of authorisation information: EAP-MSCHAPv2;" Do you think this (and similar, if any) example indicates that we shall extend EAP to also signal authorization results, or should this qualify = as one EAP method going beyond the scope?=20 I'm inclined to think latter. "2.4. EAP over IP: PANA" It'd be more accurate to call it EAP over UDP, or UDP-based EAP = lower-layer. "The original EAP applicability statement states that EAP is applicable in cases where "IP layer connectivity may not be available". The wording in the applicability statement leaves open whether the transport of EAP over IP is in scope or not. "=20 Complete statement from RFC 3748 reads like this: "EAP was designed for use in network access authentication, where IP layer connectivity may not be available." So, this provides historical background and an observation. It shouldn't = be taken as "EAP can/shall/should not be carried above IP". Btw, you may also want to note IKEv2, which also carries EAP over UDP. "This limits the use of EAP to transport layers which are on top of IP, and provide their own ordering guarantees." Sure thing. But neither IKEv2 nor PANA are "EAP naked over IP". There is UDP, and a UDP-based header in between which ensures the EAP = requirements are satisfied. "In most network access use cases all access servers that are served by a particular EAP server are providing the same or very similar types of service. The peer does not need to differentiate between different access network services supported by the same EAP server. Same EAP server can be serving multiple different types of access = technology for the same terminal (e.g., WiFi, WiMAX, 3G). So, the aforementioned assumption may not be true. "A device can be created that impersonates a Network Access Service to peers, but actually proxies the authentication to the service that newly accepts EAP auths may decrease the security of this service even for users who previously used non-EAP means of authentication to the service." Isn't this supposed to be handled by the crypto-secured AAA signaling between the NAS and the AAA proxy/server? AAA infra would not let anyone drop some arbitrary AAA node in and get it on the AAA path. " Pending issuance of a Channel Binding RFC, it is thus due to extend the EAP applicability statement to include non-network access contexts if - and only if - this context mandates channel bindings." I couldn't parse this well. To me, EAP applicability statement revision = is needed for ABFAB work (even though the ordering of these developments = taking place is not natural :-). And plus you are saying channel binding work = is needed for ABFAB work too. " The use of EAP over IP is recommended if - and only if - it is transported over a transport layer on top of IP which provides ordering guarantees." I think this goes w/o saying. Whatever requirements exist for EAP lower-layer applies to any lower layer. Besides, like I don't think = this is part of "extending" the applicability because it was already allowed. Nevertheless, an explicit recognition of that possibility can be useful = too. Thanks. Alper > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Stefan Winter > Sent: Monday, June 06, 2011 12:03 PM > To: abfab@ietf.org > Subject: [abfab] Work Item: Update to the EAP Applicability Statement >=20 > Hello, >=20 > I foolishly volunteered to draft an update to the EAP applicability > statement. With the help of very knowledgable people, in particular = Joe > Salowey and Sam Hartman, I made an initial attempt: >=20 > http://tools.ietf.org/html/draft-winter-abfab-eapapplicability-00 >=20 > This obviously isn't perfect, and I would welcome comments of any sort > (including, but not limited to, offers for text and/or co-authorship = :- > ) ). >=20 > Greetings, >=20 > Stefan Winter >=20 > -- > Stefan WINTER > Ingenieur de Recherche > Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education = Nationale et > de la Recherche 6, rue Richard Coudenhove-Kalergi > L-1359 Luxembourg >=20 > Tel: +352 424409 1 > Fax: +352 422473 >=20 From stefan.winter@restena.lu Mon Jun 6 05:28:12 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 ED0C411E8130 for ; Mon, 6 Jun 2011 05:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 4YhcibtuPMCw for ; Mon, 6 Jun 2011 05:28:12 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id B7E4011E80FF for ; Mon, 6 Jun 2011 05:28:10 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 9258210584; Mon, 6 Jun 2011 14:28:06 +0200 (CEST) Received: from [IPv6:2001:a18:1:8::155] (unknown [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 7A76610086; Mon, 6 Jun 2011 14:28:06 +0200 (CEST) Message-ID: <4DECC7D2.9000003@restena.lu> Date: Mon, 06 Jun 2011 14:28:02 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Alper Yegin References: <4DEC97D0.9080608@restena.lu> <003301cc2433$62e1f7d0$28a5e770$@yegin@yegin.org> In-Reply-To: <003301cc2433$62e1f7d0$28a5e770$@yegin@yegin.org> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB241B5B991CE416D2AFD5013" X-Virus-Scanned: ClamAV Cc: abfab@ietf.org Subject: Re: [abfab] Work Item: Update to the EAP Applicability Statement 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, 06 Jun 2011 12:28:13 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB241B5B991CE416D2AFD5013 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, thanks for these quick comments! Much appreciated! > Here are few comments: > > "2.1. Communication of authorisation information: EAP-MSCHAPv2;" > > Do you think this (and similar, if any) example indicates that we shall= > extend EAP to also signal authorization results, or should this qualify= as > one EAP method going beyond the scope?=20 > > I'm inclined to think latter. I try not to judge this. The point I'm trying to make is: it has been done, and it seems to work well. Whether or not it is something that should be expressly endorsed or better not - that is something that should be discussed. Same goes for the "change password" stuff in EAP-MSCHAPv2. There, I'm even less sure that it is something that should be endorsed. But it exists, and works - for some at least. I think it would be good to have more examples of both aspects: authorisation information and account management. After a few off-line discussions, it seems that transport of authorisation information is something that happens on a broader scale than just EAP-MSCHAPv2; I've heard that at least 3GPP does the same thing with something called AT_TRUST_IND within EAP-AKA. But, knowing nothing about 3GPP, I didn't dare use this as an example. The "change password" things though - I don't have any other example for that on the top of my head right now. If this feature is a singleton in EAP-MSCHAPv2, maybe it's not a good indicator of what should be done within EAP. > "2.4. EAP over IP: PANA" > > It'd be more accurate to call it EAP over UDP, or UDP-based EAP lower-l= ayer. I was trying *not* to mention UDP specifically. SCTP might make a just-as-good lower-layer for EAP, and runs on IP. PANA should only serve as an example for the section "EAP over IP"; I guess that wasn't very cle= ar. > "The > original EAP applicability statement states that EAP is applicable i= n > cases where "IP layer connectivity may not be available". The > wording in the applicability statement leaves open whether the > transport of EAP over IP is in scope or not. "=20 > > > Complete statement from RFC 3748 reads like this: > > "EAP was designed for use in network access authentication, where IP= > layer connectivity may not be available." > > So, this provides historical background and an observation. It shouldn'= t be > taken as "EAP can/shall/should not be carried above IP". > > Btw, you may also want to note IKEv2, which also carries EAP over UDP. Point taken, I'll enlarge the quote and add IKEv2. > "This limits the use of EAP > to transport layers which are on top of IP, and provide their own > ordering guarantees." > > Sure thing. But neither IKEv2 nor PANA are "EAP naked over IP". There i= s > UDP, and a UDP-based header in between which ensures the EAP requiremen= ts > are satisfied. Well, the applicability statement should also provide limits on what NOT to do. So, it's good that PANA and IKEv2 use UDP. But some ill-advised person might envisage "EAP over ICMP", which is on top of IP, but does not provide ordering guarantees. I think it would be good to tell such a person that they should... do something else. > "In most network > access use cases all access servers that are served by a particular > EAP server are providing the same or very similar types of service. > The peer does not need to differentiate between different access > network services supported by the same EAP server. > > > Same EAP server can be serving multiple different types of access techn= ology > for the same terminal (e.g., WiFi, WiMAX, 3G). So, the aforementioned > assumption may not be true. That's a good point; it depends largely on how one defines "very similar". I was just about to write back "but these are all just IP network access technologies" - but they aren't. IIRC, EAP-AKA in the 3GPP world isn't only used for IP network data access, it's also for good old voice telephony (is that right? I think I mentioned before that the 3GPP world is a mystery to me ... ). Still, even with data being "different" - it is still a network. Circuit-switched as opposed to packet-switched alright, but for some, it might still qualify as being "very similar". IOW, the text still has a bit of leeway for interpretation here. I'm happy to get text suggestions. > "A device can be created that impersonates a Network > Access Service to peers, but actually proxies the authentication to > the service that newly accepts EAP auths may decrease the security o= f > this service even for users who previously used non-EAP means of > authentication to the service." > > Isn't this supposed to be handled by the crypto-secured AAA signaling > between the NAS and the AAA proxy/server? AAA infra would not let anyon= e > drop some arbitrary AAA node in and get it on the AAA path. That's not where I understood the impersonation threat to come from. Isn't it more like: Consider user A who uses a NAS B to get network access, where B authenticates the user credentials to EAP server C. A also reads his email via IMAP, but the IMAP server will do plain old PAP, against server C (not speaking EAP though). B can't read the user's email because it doesn't know A's credentials at C; it's just a pass-through. Now, the IMAP administrative personnel enables IMAP server access with abfab technology, i.e. GSSAPI and EAP, authenticating against the same server C (now speaking EAP). B's operator would now love to read the user's email, and waits for the user to login via B (network access!) next time. He then triggers a GSSAPI-based EAP authentication at the IMAP server, and relays the EAP conversation from A to the IMAP server, which uses it to authenticate "A" at C. B (or, the sinister administrator of B) now has access to A's mails without actually being A - a successful impersonation. B will never learn the actual credential of A; that is hopefully cryptographically secured inside the EAP mechanism, but it may get access to another service in the name of the user. So, while B and IMAP are both part of the same AAA infrastructure, they only have a per-service trust towards the EAP server; the AAA infrastructure doesn't preclude the two from cheating over each other. > " Pending issuance of > a Channel Binding RFC, it is thus due to extend the EAP applicabilit= y > statement to include non-network access contexts if - and only if - > this context mandates channel bindings." > > I couldn't parse this well. To me, EAP applicability statement revision= is > needed for ABFAB work (even though the ordering of these developments t= aking > place is not natural :-). And plus you are saying channel binding work = is > needed for ABFAB work too. This is not necessarily about ABFAB in a narrow sense. It's more like: "using EAP for access to multiple services requires channel bindings". Since one usage of EAP is for the service "network access" ever since, adding any other second use triggers the need to add channel bindings. But yes, ABFAB is such a "second use". > " The use of EAP over IP is recommended if - and only if - it is > transported over a transport layer on top of IP which provides > ordering guarantees." > > I think this goes w/o saying. Whatever requirements exist for EAP > lower-layer applies to any lower layer. Besides, like I don't think th= is is > part of "extending" the applicability because it was already allowed. > Nevertheless, an explicit recognition of that possibility can be useful= too. Well, yes, it doesn't hurt to be explicit. Greetings, Stefan Winter > > Thanks. > > Alper > > > > > > > > > > > > > > > > > > >> -----Original Message----- >> From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf= >> Of Stefan Winter >> Sent: Monday, June 06, 2011 12:03 PM >> To: abfab@ietf.org >> Subject: [abfab] Work Item: Update to the EAP Applicability Statement >> >> Hello, >> >> I foolishly volunteered to draft an update to the EAP applicability >> statement. With the help of very knowledgable people, in particular Jo= e >> Salowey and Sam Hartman, I made an initial attempt: >> >> http://tools.ietf.org/html/draft-winter-abfab-eapapplicability-00 >> >> This obviously isn't perfect, and I would welcome comments of any sort= >> (including, but not limited to, offers for text and/or co-authorship := - >> ) ). >> >> Greetings, >> >> Stefan Winter >> >> -- >> Stefan WINTER >> Ingenieur de Recherche >> Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Natio= nale et >> de la Recherche 6, rue Richard Coudenhove-Kalergi >> L-1359 Luxembourg >> >> Tel: +352 424409 1 >> Fax: +352 422473 >> > --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enigB241B5B991CE416D2AFD5013 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3sx9cACgkQ+jm90f8eFWZsEwCeK3LOnA3KKFycR6EdkV1fK+ru FA8AnArYG9xl0UGUnqViPG/HbCZg9byh =DhML -----END PGP SIGNATURE----- --------------enigB241B5B991CE416D2AFD5013-- From alper.yegin@yegin.org Tue Jun 7 06:04:12 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 68AC711E80D6 for ; Tue, 7 Jun 2011 06:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.15 X-Spam-Level: X-Spam-Status: No, score=-101.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, 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 WchqCiEfW4YA for ; Tue, 7 Jun 2011 06:04:11 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 9C45711E80C0 for ; Tue, 7 Jun 2011 06:04:11 -0700 (PDT) Received: from ibm (dsl88-247-34762.ttnet.net.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MAhf9-1QIdQL290N-00B2GV; Tue, 07 Jun 2011 09:04:09 -0400 From: "Alper Yegin" To: "'Stefan Winter'" References: <4DEC97D0.9080608@restena.lu> <003301cc2433$62e1f7d0$28a5e770$@yegin@yegin.org> <4DECC7D2.9000003@restena.lu> In-Reply-To: <4DECC7D2.9000003@restena.lu> Date: Tue, 7 Jun 2011 16:04:00 +0300 Message-ID: <01b101cc2513$622eeab0$268cc010$@yegin@yegin.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcwkRTD6ZrNs5nrqQb+xDuuTTUP9VQAygrxg Content-Language: en-us X-Provags-ID: V02:K0:d7n9gB5/oqPYDGfqPDFXI84tKL6NtC8DstQNpMR9MlY VbL+Gt3zzF7PYMQNdZoKyZrIHcgSWbYh195pyBrvv6rbIZlnYA 86kT8RotMle2esM4FRINSRDg6OT7FjTcSxVJRDejLYq+j4q5MM spsdeBpbafLv6vL53j5c4fAKSsQqDcm0vE0pQce8ksvwfBdP1S Oz60hBZnoFnLBM4EYgld+usj9fi9D243JB1Hc4ZhXM= Cc: abfab@ietf.org Subject: Re: [abfab] Work Item: Update to the EAP Applicability Statement 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, 07 Jun 2011 13:04:12 -0000 > > "This limits the use of EAP > > to transport layers which are on top of IP, and provide their own > > ordering guarantees." > > > > Sure thing. But neither IKEv2 nor PANA are "EAP naked over IP". = There > > is UDP, and a UDP-based header in between which ensures the EAP > > requirements are satisfied. >=20 > Well, the applicability statement should also provide limits on what > NOT to do.=20 Here your I-D is sliding into talking about "EAP lower-layer = requirements" which is a different thing than "EAP applicability statement". > So, it's good that PANA and IKEv2 use UDP. But some ill- > advised person might envisage "EAP over ICMP", which is on top of IP, > but does not provide ordering guarantees. I think it would be good to > tell such a person that they should... do something else. I don't think there is anything to prevent an ICMP-based EAP lower-layer being designed. >=20 > > "In most network > > access use cases all access servers that are served by a > particular > > EAP server are providing the same or very similar types of > service. > > The peer does not need to differentiate between different access > > network services supported by the same EAP server. > > > > > > Same EAP server can be serving multiple different types of access > > technology for the same terminal (e.g., WiFi, WiMAX, 3G). So, the > > aforementioned assumption may not be true. >=20 > That's a good point; it depends largely on how one defines "very > similar". I was just about to write back "but these are all just IP > network access technologies" - but they aren't. IIRC, EAP-AKA in the > 3GPP world isn't only used for IP network data access, it's also for > good old voice telephony (is that right? I think I mentioned before > that the 3GPP world is a mystery to me ... ). >=20 > Still, even with data being "different" - it is still a network. > Circuit-switched as opposed to packet-switched alright, but for some, > it might still qualify as being "very similar". >=20 > IOW, the text still has a bit of leeway for interpretation here. I'm > happy to get text suggestions. >=20 > > "A device can be created that impersonates a Network > > Access Service to peers, but actually proxies the authentication > to > > the service that newly accepts EAP auths may decrease the = security > of > > this service even for users who previously used non-EAP means of > > authentication to the service." > > > > Isn't this supposed to be handled by the crypto-secured AAA = signaling > > between the NAS and the AAA proxy/server? AAA infra would not let > > anyone drop some arbitrary AAA node in and get it on the AAA path. >=20 > That's not where I understood the impersonation threat to come from. > Isn't it more like: >=20 > Consider user A who uses a NAS B to get network access, where B > authenticates the user credentials to EAP server C. > A also reads his email via IMAP, but the IMAP server will do plain old > PAP, against server C (not speaking EAP though). >=20 > B can't read the user's email because it doesn't know A's credentials > at C; it's just a pass-through. >=20 > Now, the IMAP administrative personnel enables IMAP server access with > abfab technology, i.e. GSSAPI and EAP, authenticating against the same > server C (now speaking EAP). >=20 > B's operator would now love to read the user's email, and waits for = the > user to login via B (network access!) next time. He then triggers a > GSSAPI-based EAP authentication at the IMAP server, and relays the EAP > conversation from A to the IMAP server, which uses it to authenticate > "A" at C. B (or, the sinister administrator of B) now has access to = A's > mails without actually being A - a successful impersonation. >=20 > B will never learn the actual credential of A; that is hopefully > cryptographically secured inside the EAP mechanism, but it may get > access to another service in the name of the user. >=20 > So, while B and IMAP are both part of the same AAA infrastructure, = they > only have a per-service trust towards the EAP server; the AAA > infrastructure doesn't preclude the two from cheating over each other. B is a NAS. It's not allowed to source AAA messages for non-NAS related procedures (e.g., IMAP). Wouldn't this simply solution handle the issue? >=20 > > " Pending issuance of > > a Channel Binding RFC, it is thus due to extend the EAP > applicability > > statement to include non-network access contexts if - and only if > - > > this context mandates channel bindings." > > > > I couldn't parse this well. To me, EAP applicability statement > > revision is needed for ABFAB work (even though the ordering of these > > developments taking place is not natural :-). And plus you are = saying > > channel binding work is needed for ABFAB work too. >=20 > This is not necessarily about ABFAB in a narrow sense. It's more like: > "using EAP for access to multiple services requires channel bindings". > Since one usage of EAP is for the service "network access" ever since, > adding any other second use triggers the need to add channel bindings. > But yes, ABFAB is such a "second use". >=20 > > " The use of EAP over IP is recommended if - and only if - it is > > transported over a transport layer on top of IP which provides > > ordering guarantees." > > > > I think this goes w/o saying. Whatever requirements exist for EAP > > lower-layer applies to any lower layer. Besides, like I don't think > > this is part of "extending" the applicability because it was already > allowed. > > Nevertheless, an explicit recognition of that possibility can be > useful too. >=20 > Well, yes, it doesn't hurt to be explicit. I'm afraid this is mixing up requirements and applicability discussions. Probably any transport protocol (including pigeons) is fine as an EAP lower-layer as long as it satisfies the EAP lower-layer requirements.=20 But carrying anything or doing anything with EAP is not fine, and that's where the applicability statement comes into the picture. On a more radical note, why EAP has applicability statement, but no(?) = other IETF protocol has one? What happens if we get rid of the applicability statement completely? Cheers, Alper >=20 > Greetings, >=20 > Stefan Winter >=20 > > > > Thanks. > > > > Alper > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> -----Original Message----- > >> From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On > >> Behalf Of Stefan Winter > >> Sent: Monday, June 06, 2011 12:03 PM > >> To: abfab@ietf.org > >> Subject: [abfab] Work Item: Update to the EAP Applicability > Statement > >> > >> Hello, > >> > >> I foolishly volunteered to draft an update to the EAP applicability > >> statement. With the help of very knowledgable people, in particular > >> Joe Salowey and Sam Hartman, I made an initial attempt: > >> > >> http://tools.ietf.org/html/draft-winter-abfab-eapapplicability-00 > >> > >> This obviously isn't perfect, and I would welcome comments of any > >> sort (including, but not limited to, offers for text and/or > >> co-authorship :- > >> ) ). > >> > >> Greetings, > >> > >> Stefan Winter > >> > >> -- > >> Stefan WINTER > >> Ingenieur de Recherche > >> Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education = Nationale > >> et de la Recherche 6, rue Richard Coudenhove-Kalergi > >> L-1359 Luxembourg > >> > >> Tel: +352 424409 1 > >> Fax: +352 422473 > >> > > >=20 >=20 > -- > Stefan WINTER > Ingenieur de Recherche > Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education = Nationale et > de la Recherche 6, rue Richard Coudenhove-Kalergi > L-1359 Luxembourg >=20 > Tel: +352 424409 1 > Fax: +352 422473 >=20 From hartmans@painless-security.com Tue Jun 7 06:31:36 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 A666E11E80D4 for ; Tue, 7 Jun 2011 06:31:36 -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 6-mG2CK1KI2e for ; Tue, 7 Jun 2011 06:31:35 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 5EBA111E808E for ; Tue, 7 Jun 2011 06:31:35 -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 72AAC20220; Tue, 7 Jun 2011 09:27:06 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6E7C04426; Tue, 7 Jun 2011 09:31:25 -0400 (EDT) From: Sam Hartman To: "Alper Yegin" References: <4DEC97D0.9080608@restena.lu> <003301cc2433$62e1f7d0$28a5e770$@yegin@yegin.org> <4DECC7D2.9000003@restena.lu> <01b101cc2513$622eeab0$268cc010$@yegin@yegin.org> Date: Tue, 07 Jun 2011 09:31:25 -0400 In-Reply-To: <01b101cc2513$622eeab0$268cc010$@yegin@yegin.org> (Alper Yegin's message of "Tue, 7 Jun 2011 16:04:00 +0300") 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] Work Item: Update to the EAP Applicability Statement 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, 07 Jun 2011 13:31:36 -0000 >>>>> "Alper" == Alper Yegin writes: >> > "This limits the use of EAP > to transport layers which are on >> top of IP, and provide their own > ordering guarantees." >> > >> > Sure thing. But neither IKEv2 nor PANA are "EAP naked over >> IP". There > is UDP, and a UDP-based header in between which >> ensures the EAP > requirements are satisfied. >> >> Well, the applicability statement should also provide limits on >> what NOT to do. Alper> Here your I-D is sliding into talking about "EAP lower-layer Alper> requirements" which is a different thing than "EAP Alper> applicability statement". I believe that requirements of the domain of applicability--in this case lower layer requirements--are in scope for this draft. My current position is that I support this discussion. >> Consider user A who uses a NAS B to get network access, where B >> authenticates the user credentials to EAP server C. A also reads >> his email via IMAP, but the IMAP server will do plain old PAP, >> against server C (not speaking EAP though). >> >> B can't read the user's email because it doesn't know A's >> credentials at C; it's just a pass-through. >> >> Now, the IMAP administrative personnel enables IMAP server access >> with abfab technology, i.e. GSSAPI and EAP, authenticating >> against the same server C (now speaking EAP). >> >> B's operator would now love to read the user's email, and waits >> for the user to login via B (network access!) next time. He then >> triggers a GSSAPI-based EAP authentication at the IMAP server, >> and relays the EAP conversation from A to the IMAP server, which >> uses it to authenticate "A" at C. B (or, the sinister >> administrator of B) now has access to A's mails without actually >> being A - a successful impersonation. >> >> B will never learn the actual credential of A; that is hopefully >> cryptographically secured inside the EAP mechanism, but it may >> get access to another service in the name of the user. >> >> So, while B and IMAP are both part of the same AAA >> infrastructure, they only have a per-service trust towards the >> EAP server; the AAA infrastructure doesn't preclude the two from >> cheating over each other. Alper> B is a NAS. It's not allowed to source AAA messages for Alper> non-NAS related procedures (e.g., IMAP). Wouldn't this simply Alper> solution handle the issue? B is malicious. It doesn't care what you think it is allowed to do. Something in the system needs to prevent B from acting improperly. The logical place to enfore that is at the EAP server. To do that, the EAP server needs to know what the user thought they were trying to do--it needs channel binding. Alper> I'm afraid this is mixing up requirements and applicability Alper> discussions. Probably any transport protocol (including Alper> pigeons) is fine as an EAP lower-layer as long as it Alper> satisfies the EAP lower-layer requirements. But carrying Alper> anything or doing anything with EAP is not fine, and that's Alper> where the applicability statement comes into the picture. Alper> On a more radical note, why EAP has applicability statement, Alper> but no(?) other IETF protocol has one? What happens if we get Alper> rid of the applicability statement completely? Alper> Cheers, I would be strongly against removing the applicability statement entirely. One of the main reasons for this is exactly because we have found requirements such as channel binding that we need to place on other uses of EAP. From alper.yegin@yegin.org Wed Jun 8 06:09:51 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 D4F96228010 for ; Wed, 8 Jun 2011 06:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.15 X-Spam-Level: X-Spam-Status: No, score=-101.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, 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 wNVput5aFsTH for ; Wed, 8 Jun 2011 06:09:51 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 282F411E80CE for ; Wed, 8 Jun 2011 06:09:51 -0700 (PDT) Received: from ibm (dsl88-247-34762.ttnet.net.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MZl3O-1Q8mr91eqU-00LFCQ; Wed, 08 Jun 2011 09:09:41 -0400 From: "Alper Yegin" To: "'Sam Hartman'" References: <4DEC97D0.9080608@restena.lu> <003301cc2433$62e1f7d0$28a5e770$@yegin@yegin.org> <4DECC7D2.9000003@restena.lu> <01b101cc2513$622eeab0$268cc010$@yegin@yegin.org> In-Reply-To: Date: Wed, 8 Jun 2011 16:09:31 +0300 Message-ID: <009f01cc25dd$521798a0$f646c9e0$@yegin@yegin.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcwlFzdZObeuj1KoQqecDKNQpfXIAgAwmW4A Content-Language: en-us X-Provags-ID: V02:K0:3wLpiQw1T8em/t/0XwlmE2ME7s8VI9XE1PM0dKQkJPO 2Db0OGJiPvxr3nsk4RAhc6bBRN/hdRnTmbPCwUHa2l780ZKWqt pMndAW3B0k18RX797UDt+nr/yScoiqKyMsppTMrPmO5kUny+F2 eR6QB6GAlWrTXXAUqkKHIoioJCPzKKK9/6HszOOVNTcCI/kpdc 48Mzm6pohIeYHuL1/zJtH60w+vJ/kYzFaBGh76gGUQ= Cc: abfab@ietf.org Subject: Re: [abfab] Work Item: Update to the EAP Applicability Statement 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: Wed, 08 Jun 2011 13:09:52 -0000 > >> > "This limits the use of EAP > to transport layers which are on > >> top of IP, and provide their own > ordering guarantees." > >> > > >> > Sure thing. But neither IKEv2 nor PANA are "EAP naked over > >> IP". There > is UDP, and a UDP-based header in between which > >> ensures the EAP > requirements are satisfied. > >> > >> Well, the applicability statement should also provide limits on > >> what NOT to do. > > Alper> Here your I-D is sliding into talking about "EAP lower-layer > Alper> requirements" which is a different thing than "EAP > Alper> applicability statement". > > I believe that requirements of the domain of applicability--in this > case > lower layer requirements--are in scope for this draft. > My current position is that I support this discussion. I find this very confusing. As you might know, RFC 3748 already has a dedicated section "3.1 Lower Layer Requirements". Are you intending to add to that, or modify that too in this "applicability statement" I-D? > >> Consider user A who uses a NAS B to get network access, where B > >> authenticates the user credentials to EAP server C. A also > reads > >> his email via IMAP, but the IMAP server will do plain old PAP, > >> against server C (not speaking EAP though). > >> > >> B can't read the user's email because it doesn't know A's > >> credentials at C; it's just a pass-through. > >> > >> Now, the IMAP administrative personnel enables IMAP server > access > >> with abfab technology, i.e. GSSAPI and EAP, authenticating > >> against the same server C (now speaking EAP). > >> > >> B's operator would now love to read the user's email, and waits > >> for the user to login via B (network access!) next time. He then > >> triggers a GSSAPI-based EAP authentication at the IMAP server, > >> and relays the EAP conversation from A to the IMAP server, which > >> uses it to authenticate "A" at C. B (or, the sinister > >> administrator of B) now has access to A's mails without actually > >> being A - a successful impersonation. > >> > >> B will never learn the actual credential of A; that is hopefully > >> cryptographically secured inside the EAP mechanism, but it may > >> get access to another service in the name of the user. > >> > >> So, while B and IMAP are both part of the same AAA > >> infrastructure, they only have a per-service trust towards the > >> EAP server; the AAA infrastructure doesn't preclude the two from > >> cheating over each other. > > Alper> B is a NAS. It's not allowed to source AAA messages for > Alper> non-NAS related procedures (e.g., IMAP). Wouldn't this > simply > Alper> solution handle the issue? > > B is malicious. It doesn't care what you think it is allowed to do. > Something in the system needs to prevent B from acting improperly. > The logical place to enfore that is at the EAP server. > To do that, the EAP server needs to know what the user thought they > were > trying to do--it needs channel binding. C knows B is a "NAS", not an "IMAP server". Therefore C would not let an IMAP session be AAAed on the B. Equivalent of that is what is relied upon in order to prevent a WiFi NAS to pretend like a WiMAX NAS. I'm not saying channel binding is unnecessary. I'm saying the scenario you are providing does not require channel binding. > > Alper> I'm afraid this is mixing up requirements and applicability > Alper> discussions. Probably any transport protocol (including > Alper> pigeons) is fine as an EAP lower-layer as long as it > Alper> satisfies the EAP lower-layer requirements. But carrying > Alper> anything or doing anything with EAP is not fine, and that's > Alper> where the applicability statement comes into the picture. > > > > > Alper> On a more radical note, why EAP has applicability statement, > Alper> but no(?) other IETF protocol has one? What happens if we > get > Alper> rid of the applicability statement completely? > > Alper> Cheers, > > I would be strongly against removing the applicability statement > entirely. One of the main reasons for this is exactly because we have > found requirements such as channel binding that we need to place on > other uses of EAP. My concern with the applicability statement is that, it can be misused unless it is perfectly defined, which is not possible by definition. This is very tricky. Do we have good experience and examples with defining applicability statements in IETF? (The ones that I have seen so far have been bad experiences :-) Btw, can't we say the same thing for any authentication method/mechanism/protocol (not just EAP)? If I'm getting authenticated/authorized for Service X using method Y, there needs to be some way of ensuring that the other end-point of authentication also thinks I'm up for Service X. Does TLS, HTTP-digest, IKE, etc. all take care of that? I think not. So, we should think if they also need channel-binding, or if they have some substitute solutions. Any thoughts on that? Alper Alper From stefan.winter@restena.lu Thu Jun 9 02:25:54 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 20D5011E8093 for ; Thu, 9 Jun 2011 02:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 iQEeMHyyi8QH for ; Thu, 9 Jun 2011 02:25:53 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 502BC11E809C for ; Thu, 9 Jun 2011 02:25:50 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id A5D1110590; Thu, 9 Jun 2011 11:25:47 +0200 (CEST) Received: from [IPv6:2001:a18:1:8::155] (unknown [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 8D24B10584; Thu, 9 Jun 2011 11:25:47 +0200 (CEST) Message-ID: <4DF0919A.2030500@restena.lu> Date: Thu, 09 Jun 2011 11:25:46 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Alper Yegin References: <4DEC97D0.9080608@restena.lu> <003301cc2433$62e1f7d0$28a5e770$@yegin@yegin.org> <4DECC7D2.9000003@restena.lu> <01b101cc2513$622eeab0$268cc010$@yegin@yegin.org> <009f01cc25dd$521798a0$f646c9e0$@yegin@yegin.org> In-Reply-To: <009f01cc25dd$521798a0$f646c9e0$@yegin@yegin.org> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3D71C9BB9222CC288A49C1F8" X-Virus-Scanned: ClamAV Cc: abfab@ietf.org Subject: Re: [abfab] Work Item: Update to the EAP Applicability Statement 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: Thu, 09 Jun 2011 09:25:54 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3D71C9BB9222CC288A49C1F8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, (only replying to the impersonation part) >> >> So, while B and IMAP are both part of the same AAA >> >> infrastructure, they only have a per-service trust towards the >> >> EAP server; the AAA infrastructure doesn't preclude the two fro= m >> >> cheating over each other. >> >> Alper> B is a NAS. It's not allowed to source AAA messages for >> Alper> non-NAS related procedures (e.g., IMAP). Wouldn't this >> simply >> Alper> solution handle the issue? >> >> B is malicious. It doesn't care what you think it is allowed to do. >> Something in the system needs to prevent B from acting improperly. >> The logical place to enfore that is at the EAP server. >> To do that, the EAP server needs to know what the user thought they >> were >> trying to do--it needs channel binding. > C knows B is a "NAS", not an "IMAP server".=20 > Therefore C would not let an IMAP session be AAAed on the B. > > Equivalent of that is what is relied upon in order to prevent a WiFi NA= S to > pretend like a WiMAX NAS.=20 > > > I'm not saying channel binding is unnecessary. I'm saying the scenario = you > are providing does not require channel binding. C knows that B is a NAS. C knows that IMAP is a NAS. What C doesn't know is that B initiated a TCP connection on the IMAP4 port, started an IMAP conversation, and, when asked to authenticate via GSSAPI/EAP uses a carbon copy of the EAP authentication currently going on with A for network access. I hope that makes the attack scenario clearer... Stefan >> Alper> I'm afraid this is mixing up requirements and applicability= >> Alper> discussions. Probably any transport protocol (including >> Alper> pigeons) is fine as an EAP lower-layer as long as it >> Alper> satisfies the EAP lower-layer requirements. But carrying >> Alper> anything or doing anything with EAP is not fine, and that's= >> Alper> where the applicability statement comes into the picture. >> >> >> >> >> Alper> On a more radical note, why EAP has applicability statement= , >> Alper> but no(?) other IETF protocol has one? What happens if we >> get >> Alper> rid of the applicability statement completely? >> >> Alper> Cheers, >> >> I would be strongly against removing the applicability statement >> entirely. One of the main reasons for this is exactly because we have >> found requirements such as channel binding that we need to place on >> other uses of EAP. > My concern with the applicability statement is that, it can be misused > unless it is perfectly defined, which is not possible by definition. Th= is is > very tricky. Do we have good experience and examples with defining > applicability statements in IETF? (The ones that I have seen so far hav= e > been bad experiences :-) > > Btw, can't we say the same thing for any authentication > method/mechanism/protocol (not just EAP)? If I'm getting > authenticated/authorized for Service X using method Y, there needs to b= e > some way of ensuring that the other end-point of authentication also th= inks > I'm up for Service X. Does TLS, HTTP-digest, IKE, etc. all take care of= > that? I think not. So, we should think if they also need channel-bindin= g, or > if they have some substitute solutions. Any thoughts on that? > > Alper > > > > > Alper > > > > > --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig3D71C9BB9222CC288A49C1F8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3wkZoACgkQ+jm90f8eFWabLACfe9JWLS2Meiv8WxcRQch4et5v uJQAoITF6tjntiKhzTQDJO7zCPiUWK27 =ZsXo -----END PGP SIGNATURE----- --------------enig3D71C9BB9222CC288A49C1F8-- From nico@cryptonector.com Thu Jun 9 09:06:58 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 C63A021F84B1 for ; Thu, 9 Jun 2011 09:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.096 X-Spam-Level: X-Spam-Status: No, score=-3.096 tagged_above=-999 required=5 tests=[AWL=-1.119, 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 8yHIIU-xwAxd for ; Thu, 9 Jun 2011 09:06:58 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 1B71D21F84AF for ; Thu, 9 Jun 2011 09:06:58 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id E74C62F4057 for ; Thu, 9 Jun 2011 09:06:51 -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; q=dns; s=cryptonector.com; b=diKop2uS1Xygp1r2kplA0 rj1n2i+gPHjJfSNQ1WXfsLj+8VJ6T9/Fndb6/iAgKDSZoVcp2DtOUCD31fLnS4vB KMnIfPdc6KwIfSQv7U23E0BbvfnLst+zs0ULOeBXJQaO7n7nZB1wcPImJN/AgAX0 fr1to+5DmVU3O7dAVXn8VU= 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; s=cryptonector.com; bh=c1F/pT5JuCithI415fWZ MxGBo0o=; b=HZr+YPKHMC5HvRrB3Ms29rYmArLEGPrP1ss4XlDp+KPXl5iYIFff 0Ix+NQx6XC5/ej/GZoqjUkKWEcaXaPubsjWFasW/nHRUg7355KZo78UGdee65H4r DuHP6jAfG+JlNpaAvjrOOGUIyBh9vkSPs1UVY+S+/ZPZqh/i0lweKKE= Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id 877F12F4084 for ; Thu, 9 Jun 2011 09:05:28 -0700 (PDT) Received: by pwi5 with SMTP id 5so894167pwi.31 for ; Thu, 09 Jun 2011 09:05:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.37.3 with SMTP id u3mr405535pbj.456.1307635527716; Thu, 09 Jun 2011 09:05:27 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Thu, 9 Jun 2011 09:05:27 -0700 (PDT) In-Reply-To: <4DF0919A.2030500@restena.lu> References: <4DEC97D0.9080608@restena.lu> <4DECC7D2.9000003@restena.lu> <4DF0919A.2030500@restena.lu> Date: Thu, 9 Jun 2011 11:05:27 -0500 Message-ID: From: Nico Williams To: Stefan Winter Content-Type: text/plain; charset=UTF-8 Cc: abfab@ietf.org Subject: Re: [abfab] Work Item: Update to the EAP Applicability Statement 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: Thu, 09 Jun 2011 16:06:58 -0000 On Thu, Jun 9, 2011 at 4:25 AM, Stefan Winter wrote: > C knows that B is a NAS. C knows that IMAP is a NAS. What C doesn't know > is that B initiated a TCP connection on the IMAP4 port, started an IMAP > conversation, and, when asked to authenticate via GSSAPI/EAP uses a > carbon copy of the EAP authentication currently going on with A for > network access. > > I hope that makes the attack scenario clearer... Right, this is just a sort of MITM cut-n-paste attack. It's made feasible only by the addition of a new context from which authentication messages may be taken and played elsewhere. Another factor that makes this feasible is that in the original context there's either no additional confirmation of context establishment than that provided by the authentication message exchange, OR failure of that is often silently ignored. This is an example of a good reason for an applicability statement. Simply adding more contexts in which a technology might be used can render insecure. This is also a good reason to not design mechanisms with this sort of weakness built-in... We've faced similar problems in the GSS and Kerberos worlds before. The best example is SSHv2, where we used the same service name ('host') as in other kerberized and GSSified protocols (rsh, telnet, FTP), where some of those other protocols had options to not perform any confidentiality nor integrity protection after authentication. This EAP issue is the same sort of problem that we faced when adding GSS support to SSHv2. Nico -- From jsalowey@cisco.com Thu Jun 9 18:11:57 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 5C80A11E80A0 for ; Thu, 9 Jun 2011 18:11:57 -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 6YQSttMpYNX2 for ; Thu, 9 Jun 2011 18:11:56 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 6B57311E8095 for ; Thu, 9 Jun 2011 18:11:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=1488; q=dns/txt; s=iport; t=1307668316; x=1308877916; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=pdbnOWqmzHFv+LiuUZmGC6Uuz3T2/dzJZJinjqaB9yQ=; b=BVGw72nO17nShcFhpgtzMvuzbaBD30vNG+bagNmN904RJsW5S/PItdx5 E0wCq0oSJ06DdTNbdJig6387Flb0yjrScxhr+jJXfJUA2bI5PXx/6yV5f aO8S+iOCJ+vhOEKmJASODClD1iQd6yYs262QoLXYIlkXWCk3Z2md4UMAW I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAJv8U2rRDoG/2dsb2JhbABTpkJ3iHGgT54WhiMEhwiKI4ROiyg X-IronPort-AV: E=Sophos;i="4.65,344,1304294400"; d="scan'208";a="463032380" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 10 Jun 2011 01:11:56 +0000 Received: from [10.35.71.50] ([10.35.71.50]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5A1Budx019724; Fri, 10 Jun 2011 01:11:56 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Joe Salowey In-Reply-To: <4DEC97D0.9080608@restena.lu> Date: Thu, 9 Jun 2011 18:07:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DEC97D0.9080608@restena.lu> To: Stefan Winter X-Mailer: Apple Mail (2.1084) Cc: abfab@ietf.org Subject: Re: [abfab] Work Item: Update to the EAP Applicability Statement 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, 10 Jun 2011 01:11:57 -0000 Hi Stefan, Thanks for putting this together. I have some detailed comments on the = subsections in section 2 which I will provide under separate subjects. = In general I would like the draft to be more explanatory about when it = is a good idea to move beyond the applicability statement. I'll include = some of this in my comments on section 2, some of which may also be = incorporated into section 4. I do not think we should rename the = protocol as suggested in section 3. =20 Cheers, Joe On Jun 6, 2011, at 2:03 AM, Stefan Winter wrote: > Hello, >=20 > I foolishly volunteered to draft an update to the EAP applicability > statement. With the help of very knowledgable people, in particular = Joe > Salowey and Sam Hartman, I made an initial attempt: >=20 > http://tools.ietf.org/html/draft-winter-abfab-eapapplicability-00 >=20 > This obviously isn't perfect, and I would welcome comments of any sort > (including, but not limited to, offers for text and/or co-authorship = :-) ). >=20 > Greetings, >=20 > Stefan Winter >=20 > --=20 > Stefan WINTER > Ingenieur de Recherche > Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education = Nationale et de la Recherche > 6, rue Richard Coudenhove-Kalergi > L-1359 Luxembourg >=20 > Tel: +352 424409 1 > Fax: +352 422473 >=20 >=20 > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From jsalowey@cisco.com Thu Jun 9 18:11:58 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 4D56311E80A4 for ; Thu, 9 Jun 2011 18:11:58 -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 i1pVSpb68S4o for ; Thu, 9 Jun 2011 18:11:57 -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 A538C11E8095 for ; Thu, 9 Jun 2011 18:11:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=3925; q=dns/txt; s=iport; t=1307668317; x=1308877917; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=vCmsZf/qD1X8eIxOwQ5EgXQ7fGUR1BXlTFuvY/EVMUU=; b=m4Q27QNRfUNAdHymL4PZ1NdL2RGooitA34+reB2Meiou/a1Av6d+Pjrx oGyQZ7bf48tj2Pt3G5AnB3z4wxRa8G+R9zRn4RiHIc+WL0RqiC15D+CRC 8j1So0OPNalT9J2vWh64ZpkWBdzNrMkS7eh/yKofODvYWbGfiqz+hIDOz c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIBu8U2rRDoG/2dsb2JhbABGDaZCd6k/nhaDGoMJBIcIiiOEToso X-IronPort-AV: E=Sophos;i="4.65,344,1304294400"; d="scan'208";a="373887290" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 10 Jun 2011 01:11:57 +0000 Received: from [10.35.71.50] ([10.35.71.50]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5A1Bue0019724; Fri, 10 Jun 2011 01:11:57 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Salowey In-Reply-To: <4DEC97D0.9080608@restena.lu> Date: Thu, 9 Jun 2011 18:07:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8682DBB8-165B-4236-AB84-4AE26DD98105@cisco.com> References: <4DEC97D0.9080608@restena.lu> To: Stefan Winter X-Mailer: Apple Mail (2.1084) Cc: abfab@ietf.org Subject: [abfab] Comments on draft-winter-abfab-eapapplicability-00 Section 2.1 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, 10 Jun 2011 01:11:58 -0000 There are several cases where authorization data is carried in EAP. In = the case you site there is information about an authorization result = that is carried within EAP. There are also cases where more detailed = information is delivered to the peer. One example is the AT_TRUST_IND = attribute that has been defined by 3GPP within EAP-AKA/SIM. This = attribute allows the authentication server to signal to the peer whether = the access network is trusted. Unfortunately, EAP methods do not have = a generic way of carrying authorization information. Some methods will = not have the capability to carry specific attributes this so it will not = be possible to move to a different EAP type to support different = credentials in these deployments. This breaks the plug-ability of EAP = methods. Another potential issue here is that authorization = information is often deployment or technology specific, which breaks the = media independent properties of EAP. I would not recommend the = general addition of authorization information to EAP unless a generic = mechanism for communicating authorization information within EAP methods = is developed. =20 Here is a suggested revision for this section: "2.1. Communication of authorisation information In some cases EAP methods carry authorization information. An EAP-AKA = attribute, AT_TRUST_IND [3GPP TS 24.302], has been defined in 3GPP to = allow the authentication server to signal to the EAP peer if it is = attached to a trusted network. If the attribute indicates the network = is not trusted then the EAP peer would establish an IPSEC tunnel to its = home network to protect its communications. If the attribute indicates = a trusted network then the EAP Peer may send its traffic without = establishing an IPSEC tunnel since the network is authorized to handle = it. =20 It is also common for EAP methods to communicate information about = access control decisions beyond just success and failure. For example, = MSCHAPv2 signals (lack of) authorisation of an authenticated user to use = a service. An MSCHAPv2 failure packet as defined in section 6 of = [RFC2759] can indicate condition 646 "Restricted Logon hours". This = determination is an authorisation check which happens subsequent to the = authentication step (a user needs to be positively identified to = correlate his identity to a list of permitted logon hours). This use of EAP is not covered by the EAP applicability statement since = it goes beyond authentication. There are some potential issues that = can arise from carrying authorization data in EAP. First, there is no = generic mechanism for EAP methods to carry authorization data. In = order to make use of and communicate the authorization data the EAP = method will have to provide custom interfaces and capabilities. This = will inhibit the ability for different EAP methods to be used in a = pluggable fashion within deployments. It addition, if the authorization = information is specific to a particular media, then it will break the = media independent property of EAP. =20 Extending individual EAP methods to carry authorization data for a = specific deployment, technology, or media type is NOT RECOMMENDED. If = the authorization data is informative such that the system operation is = not significantly change if it is missing and if it is of a general = nature then authorization data MAY be carried. If there is significant = need for deployment specific, technology specific or media specific = authorization information to be carried within EAP methods then a well = defined mechanism and framework must be defined so the type of = authorization data can be independent of the EAP method. This would = allow the deployment of different EAP methods to support peers and = servers with different credential types. " From jsalowey@cisco.com Thu Jun 9 18:11: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 8563F11E80E6 for ; Thu, 9 Jun 2011 18:11:59 -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 5Cqq060UqNBn for ; Thu, 9 Jun 2011 18:11:59 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id E43CE11E80D2 for ; Thu, 9 Jun 2011 18:11:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=1900; q=dns/txt; s=iport; t=1307668318; x=1308877918; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Yq2MmZWxFObmbZ0SmURihZ3A2iILQdQUfknrHBEvIh8=; b=SnNVSUUesl1qgJ6gTGUz+eKuZz5vTdkROE7jAGGb5KIzckyd0YOMH1+p g9XgfS1zOSoBAWW8dLQgY65gRuV/kSpoPbRzvl5iIqJ0uNC98yfiu5or8 W95elFenggDfbh+6INBY6uaFbaQ2jBYEB1cGO42kkMBq1O1+uq0vRxf29 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAJv8U2rRDoG/2dsb2JhbABTpkJ3qUCeFoMsgncEhwiKI4ROiyg X-IronPort-AV: E=Sophos;i="4.65,344,1304294400"; d="scan'208";a="463032397" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 10 Jun 2011 01:11:58 +0000 Received: from [10.35.71.50] ([10.35.71.50]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5A1Bue3019724; Fri, 10 Jun 2011 01:11:58 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Salowey In-Reply-To: <4DEC97D0.9080608@restena.lu> Date: Thu, 9 Jun 2011 18:07:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <01184CD0-F0FE-4BAB-A68F-FE9C513E2D0E@cisco.com> References: <4DEC97D0.9080608@restena.lu> To: Stefan Winter X-Mailer: Apple Mail (2.1084) Cc: abfab@ietf.org Subject: [abfab] Comments on draft-winter-abfab-eapapplicability-00 section 2.4 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, 10 Jun 2011 01:11:59 -0000 I think any EAP lower layer should be required to implement validation = of the MSK between the EAP peer and EAP authenticator. If you are = going to mention re-ordering you might also mention fragmentation. Here = is some suggested text, but I don't think I captured all the information = from the thread on this topic.=20 "2.4. EAP over IP The original EAP applicability statement states that EAP is applicable = in cases where "IP layer connectivity may not be available". The = wording in the applicability statement leaves open whether the transport = of EAP over IP is in scope or not. Since protocols which carry EAP over = IP already exist and have been deployed, it is due to make this use case = explicit and reflect it in the revised applicability statement. = Examples of EAP over IP protocols include PANA protocol [RFC5191] and = IKEv2. Since protocols which carry EAP over IP already exist and have = been deployed, it is due to make this use case explicit and reflect it = in the revised applicability statement. =20 There are some considerations to consider when EAP is used over other = transports. The statement needs to take into account though that EAP = requires ordering guarantees from its lower layers, which are not = delivered by IP in itself. This limits the use of EAP to transport = layers which are on top of IP, and provide their own ordering = guarantees. In addition, many EAP methods do not provide fragmentation = so lower layers that limit the payload size may artificially constrain = the use of some EAP methods. Since it is common for the authentication = server to be separated by from the authenticator lower layer protocols = MUST provide a mechanism for the EAP Peer and EAP authenticator to = prove possession of the EAP MSK to ensure the EAP Peer and EAP = authenticator are authenticated to one another. " From jsalowey@cisco.com Thu Jun 9 18:12: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 15C9511E80D2 for ; Thu, 9 Jun 2011 18:12:00 -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 RQoAxl+BZSJW for ; Thu, 9 Jun 2011 18:11:59 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 28BE011E80DD for ; Thu, 9 Jun 2011 18:11:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=6093; q=dns/txt; s=iport; t=1307668319; x=1308877919; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=iuTeFcN78wVq3TWkkjsWpLzq54INzZtIkT1jgowPmwM=; b=KUTrjxBoTz8fwSvvZfIp3by1u5bJAOlJqz+Wc9y2RAlrhN2lc+432yAS 9C4hzwmXWqPGWrVlyt+108rUDW5D+LZjP0pRr71fyrMeFGxdH1DoEITc5 T4xmq4YAz8JT0SvWDurZXpEyRfhC4mbrZV3uZzdLjZkMucwgQeOogeXvK Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMNu8U2rRDoG/2dsb2JhbABOAQSmQneIcaBOnhaDNAGCbgSHCIojhE6LKA X-IronPort-AV: E=Sophos;i="4.65,344,1304294400"; d="scan'208";a="711298996" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-6.cisco.com with ESMTP; 10 Jun 2011 01:11:58 +0000 Received: from [10.35.71.50] ([10.35.71.50]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5A1Bue4019724; Fri, 10 Jun 2011 01:11:58 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Salowey In-Reply-To: <009f01cc25dd$521798a0$f646c9e0$@yegin@yegin.org> Date: Thu, 9 Jun 2011 18:08:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DEC97D0.9080608@restena.lu> <003301cc2433$62e1f7d0$28a5e770$@yegin@yegin.org> <4DECC7D2.9000003@restena.lu> <01b101cc2513$622eeab0$268cc010$@yegin@yegin.org> <009f01cc25dd$521798a0$f646c9e0$@yegin@yegin.org> To: "Alper Yegin" X-Mailer: Apple Mail (2.1084) Cc: abfab@ietf.org Subject: Re: [abfab] Work Item: Update to the EAP Applicability Statement 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, 10 Jun 2011 01:12:00 -0000 On Jun 8, 2011, at 6:09 AM, Alper Yegin wrote: >>>>> "This limits the use of EAP > to transport layers which are on >>>> top of IP, and provide their own > ordering guarantees." >>>>>=20 >>>>> Sure thing. But neither IKEv2 nor PANA are "EAP naked over >>>> IP". There > is UDP, and a UDP-based header in between which >>>> ensures the EAP > requirements are satisfied. >>>>=20 >>>> Well, the applicability statement should also provide limits on >>>> what NOT to do. >>=20 >> Alper> Here your I-D is sliding into talking about "EAP = lower-layer >> Alper> requirements" which is a different thing than "EAP >> Alper> applicability statement". >>=20 >> I believe that requirements of the domain of applicability--in this >> case >> lower layer requirements--are in scope for this draft. >> My current position is that I support this discussion. >=20 > I find this very confusing. As you might know, RFC 3748 already has a > dedicated section "3.1 Lower Layer Requirements". Are you intending to = add > to that, or modify that too in this "applicability statement" I-D?=20 >=20 [Joe] Perhaps. The applicability statement was not created without = reason. There are many cases where the environment where EAP is used, = including the lower layer, is an important consideration. In expanding = the applicability statement there may be additional requirements on the = environment for EAP to be used successfully for a particular = application.=20 >>>> Consider user A who uses a NAS B to get network access, where B >>>> authenticates the user credentials to EAP server C. A also >> reads >>>> his email via IMAP, but the IMAP server will do plain old PAP, >>>> against server C (not speaking EAP though). >>>>=20 >>>> B can't read the user's email because it doesn't know A's >>>> credentials at C; it's just a pass-through. >>>>=20 >>>> Now, the IMAP administrative personnel enables IMAP server >> access >>>> with abfab technology, i.e. GSSAPI and EAP, authenticating >>>> against the same server C (now speaking EAP). >>>>=20 >>>> B's operator would now love to read the user's email, and waits >>>> for the user to login via B (network access!) next time. He then >>>> triggers a GSSAPI-based EAP authentication at the IMAP server, >>>> and relays the EAP conversation from A to the IMAP server, which >>>> uses it to authenticate "A" at C. B (or, the sinister >>>> administrator of B) now has access to A's mails without actually >>>> being A - a successful impersonation. >>>>=20 >>>> B will never learn the actual credential of A; that is hopefully >>>> cryptographically secured inside the EAP mechanism, but it may >>>> get access to another service in the name of the user. >>>>=20 >>>> So, while B and IMAP are both part of the same AAA >>>> infrastructure, they only have a per-service trust towards the >>>> EAP server; the AAA infrastructure doesn't preclude the two from >>>> cheating over each other. >>=20 >> Alper> B is a NAS. It's not allowed to source AAA messages for >> Alper> non-NAS related procedures (e.g., IMAP). Wouldn't this >> simply >> Alper> solution handle the issue? >>=20 >> B is malicious. It doesn't care what you think it is allowed to do. >> Something in the system needs to prevent B from acting improperly. >> The logical place to enfore that is at the EAP server. >> To do that, the EAP server needs to know what the user thought they >> were >> trying to do--it needs channel binding. >=20 > C knows B is a "NAS", not an "IMAP server".=20 > Therefore C would not let an IMAP session be AAAed on the B. >=20 > Equivalent of that is what is relied upon in order to prevent a WiFi = NAS to > pretend like a WiMAX NAS.=20 >=20 >=20 > I'm not saying channel binding is unnecessary. I'm saying the scenario = you > are providing does not require channel binding. >=20 >>=20 >> Alper> I'm afraid this is mixing up requirements and applicability >> Alper> discussions. Probably any transport protocol (including >> Alper> pigeons) is fine as an EAP lower-layer as long as it >> Alper> satisfies the EAP lower-layer requirements. But carrying >> Alper> anything or doing anything with EAP is not fine, and that's >> Alper> where the applicability statement comes into the picture. >>=20 >>=20 >>=20 >>=20 >> Alper> On a more radical note, why EAP has applicability = statement, >> Alper> but no(?) other IETF protocol has one? What happens if we >> get >> Alper> rid of the applicability statement completely? >>=20 >> Alper> Cheers, >>=20 >> I would be strongly against removing the applicability statement >> entirely. One of the main reasons for this is exactly because we have >> found requirements such as channel binding that we need to place on >> other uses of EAP. >=20 > My concern with the applicability statement is that, it can be misused > unless it is perfectly defined, which is not possible by definition. = This is > very tricky. Do we have good experience and examples with defining > applicability statements in IETF? (The ones that I have seen so far = have > been bad experiences :-) >=20 [Joe] Perhaps, but we already have one. I think it would be good to = provide more explanation around why such statements are made. =20 > Btw, can't we say the same thing for any authentication > method/mechanism/protocol (not just EAP)? If I'm getting > authenticated/authorized for Service X using method Y, there needs to = be > some way of ensuring that the other end-point of authentication also = thinks > I'm up for Service X. Does TLS, HTTP-digest, IKE, etc. all take care = of > that? I think not. So, we should think if they also need = channel-binding, or > if they have some substitute solutions. Any thoughts on that? >=20 > Alper >=20 >=20 >=20 >=20 > Alper >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From jsalowey@cisco.com Thu Jun 9 18:12: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 7104411E8095 for ; Thu, 9 Jun 2011 18:12:18 -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 1CA5XKC3PT6E for ; Thu, 9 Jun 2011 18:12:18 -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 BB7D111E8120 for ; Thu, 9 Jun 2011 18:12:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=1375; q=dns/txt; s=iport; t=1307668337; x=1308877937; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=kDpItP4N9kRfS6SBQYJwAu9o/blRZdkHZe8UkgLOFLE=; b=Q5MMfH+Q9P0kREOO4oCU84rgIH3W5DwGSsUIwNjuP7nPvQiAYBfzwHtH SycX2mUKIPH4iwmtiiRsR08CLCYCThCZPnz1uK7WfPatBUO0PtFz5AhBL zhmoD0lKgNbqDEMbx3WOyHmgYhWaX89uBbwDrPcQhNkjpWiGjLpGQoVGn E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAJv8U2rRDoG/2dsb2JhbABQA6ZCd6lAnhaDLA2CagSHCIojhE6LKA X-IronPort-AV: E=Sophos;i="4.65,344,1304294400"; d="scan'208";a="333997630" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 10 Jun 2011 01:11:58 +0000 Received: from [10.35.71.50] ([10.35.71.50]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5A1Bue2019724; Fri, 10 Jun 2011 01:11:58 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Salowey In-Reply-To: <4DEC97D0.9080608@restena.lu> Date: Thu, 9 Jun 2011 18:07:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <22911B83-70C2-4F6B-880A-88204A1F99A5@cisco.com> References: <4DEC97D0.9080608@restena.lu> To: Stefan Winter X-Mailer: Apple Mail (2.1084) Cc: abfab@ietf.org Subject: [abfab] Comments on draft-winter-abfab-eapapplicability-00 section 2.3 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, 10 Jun 2011 01:12:18 -0000 Some aspects of account management, such as those associated with the = authentication credential seem like they may be a good fit. Others, = such as paying bills and adding services probably are not as these sorts = of tasks tend to be deployment specific. =20 Suggested text: "2.3. Credential Management Another enhancement to EAP is in the area of credential management. For = example, EAP-MSCHAPv2 includes limited support for user account = management, namely the possibility for a user to change his password, = should it have expired. This is defined in section 7 of [RFC2759]. This use of EAP is not covered by the EAP applicability statement since = it goes beyond authentication. In general, account management tasks = within EAP SHOULD be limited to tasks directly associated with the = credentials used for authentication. The renewal of a password or the = maintenance of a PIN code are examples of this type of task. Tasks that = are of a more general nature such as payment or service maintenance are = NOT RECOMMENDED since they are likely to be very deployment specific = leading to EAP methods that are not reusable in other environments. In = addition these more general tasks often involve extensive user = interaction and the exchange of additional data which can be dangerously = close to "bulk data transport". " From jsalowey@cisco.com Thu Jun 9 18:12: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 8C72511E8120 for ; Thu, 9 Jun 2011 18:12:18 -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 BKlVCTm+sLzC for ; Thu, 9 Jun 2011 18:12:17 -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 AA8BA11E80E6 for ; Thu, 9 Jun 2011 18:12:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=2968; q=dns/txt; s=iport; t=1307668337; x=1308877937; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=436kQ2aOoaEQkAs+uMqfJJTyxm1YFWzXe7DSpjdQvdg=; b=htee7cTio35TSnHvvg68aGCipcy9dSIMQtFIwzAfPuoZlsYvMszTY2PT oeodFf1vm6gubR8Hu3CgyMIkB3/HxLQxZEqR2Uz8nyldAJvpJo70/Dlo2 VZj7ol/YUPfV//ubqpHZZvTCgHoGCn5Q9rn9pbHNQzw0zfAAOVxetQwBs 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAJv8U2rRDoG/2dsb2JhbABTpkJ3qUCeFoYjBIcIiiOEToso X-IronPort-AV: E=Sophos;i="4.65,344,1304294400"; d="scan'208";a="333997626" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 10 Jun 2011 01:11:57 +0000 Received: from [10.35.71.50] ([10.35.71.50]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5A1Bue1019724; Fri, 10 Jun 2011 01:11:57 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Salowey In-Reply-To: <4DEC97D0.9080608@restena.lu> Date: Thu, 9 Jun 2011 18:07:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <54543717-39AA-4FE5-8C01-28B21AF3E36B@cisco.com> References: <4DEC97D0.9080608@restena.lu> To: Stefan Winter X-Mailer: Apple Mail (2.1084) Cc: abfab@ietf.org Subject: [abfab] Comments on draft-winter-abfab-eapapplicability-00 section 2.2 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, 10 Jun 2011 01:12:18 -0000 There are definite advantages to doing endpoint assessment checks at the = time of network access, however this use of EAP is not covered by the = EAP applicability statement since it is not authentication. EAP has = was designed for user authentication. Many deployments rely upon the = EAP method to authenticate the EAP Peer and EAP Server and generate a = Peer Name and Server Name for authorization and accounting purposes. = Endpoint assessment techniques do not always provide this type of = authentication and naming. In addition, if the assessment data is = tightly coupled with a specific EAP authentication method it will = restrict the plug-ability of EAP methods in different deployments. The = draft should RECOMMEND that endpoint assessment data be incorporated = into an EAP exchange along with existing peer and sever authentication = as an enhancement to the authorization process. One mechanism to = achieve this is to exchange the NEA data within an EAP tunnel method = that can also provide the peer and server authentication.=20 Here is some suggested text for section 2.2 "2.2. Endpoint Assessment Recently, EAP methods have been used to carry endpoint posture = information to assess the health of an endpoint. This is the topic of = the the IETF "Network Endpoint Assessment" NEA working group. This = working group is developing mechanisms for carrying posture data over = EAP. =20 The information exchanged is unrelated to user authentication - the = information covers the state of the computing device only, independently = of the user who is using it. Implementations of this technology have = been developed that embed the posture data within another EAP method or = within a stand alone method. =20 This use of EAP is not covered by the EAP applicability statement since = it is not authentication, which is what EAP was designed to do. Many = deployments rely upon the EAP method to authenticate and generate an EAP = Peer Name and EAP Server Name which are then used for authorization and = accounting purposes. Endpoint assessment techniques do not always = provide the type of authenticated name used for authorization and = accounting. It is RECOMMENDED that endpoint assessment data be = incorporated into an EAP exchange along with existing peer and sever = authentication as an enhancement to the authorization process. One = mechanism to achieve this is to exchange the NEA data within an EAP = tunnel method that can also provide the peer and server authentication.=20= The size of the posture data may also be a concern when performing = endpoint assessment. Care should be taken to limit the amount and type = of data communicated in the assessment process. For example, it is = inappropriate to transfer software patches to be applied on the endpoint = over the EAP channel since this would fall into the category of "bulk = data transport". " From yoshihiro.ohba@toshiba.co.jp Thu Jun 9 20:48:43 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 0985E11E8134 for ; Thu, 9 Jun 2011 20:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.956 X-Spam-Level: X-Spam-Status: No, score=-3.956 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 sR0D5P0x-IFc for ; Thu, 9 Jun 2011 20:48:42 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id E94A311E8076 for ; Thu, 9 Jun 2011 20:48:41 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id p5A3meZv019077 for ; Fri, 10 Jun 2011 12:48:40 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id p5A3meT5014090 for abfab@ietf.org; Fri, 10 Jun 2011 12:48:40 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id NAA14087; Fri, 10 Jun 2011 12:48:40 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id p5A3meYt019805 for ; Fri, 10 Jun 2011 12:48:40 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id p5A3mdBs001568; Fri, 10 Jun 2011 12:48:39 +0900 (JST) Received: from [133.199.16.227] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0LMK00CGG2L2GA60@mail.po.toshiba.co.jp> for abfab@ietf.org; Fri, 10 Jun 2011 12:48:39 +0900 (JST) Date: Fri, 10 Jun 2011 12:48:29 +0900 From: Yoshihiro Ohba In-reply-to: To: abfab@ietf.org Message-id: <4DF1940D.1060604@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 8BIT References: <4DEC97D0.9080608@restena.lu> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 Subject: Re: [abfab] Work Item: Update to the EAP Applicability Statement 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, 10 Jun 2011 03:48:43 -0000 I agree with Joe that we don't need to rename the protocol name. Extensible Authentication Protocol is good enough. Yoshihiro Ohba (2011/06/10 10:07), Joe Salowey wrote: > Hi Stefan, > > Thanks for putting this together. I have some detailed comments on the subsections in section 2 which I will provide under separate subjects. In general I would like the draft to be more explanatory about when it is a good idea to move beyond the applicability statement. I'll include some of this in my comments on section 2, some of which may also be incorporated into section 4. I do not think we should rename the protocol as suggested in section 3. > > Cheers, > > Joe > > > On Jun 6, 2011, at 2:03 AM, Stefan Winter wrote: > >> Hello, >> >> I foolishly volunteered to draft an update to the EAP applicability >> statement. With the help of very knowledgable people, in particular Joe >> Salowey and Sam Hartman, I made an initial attempt: >> >> http://tools.ietf.org/html/draft-winter-abfab-eapapplicability-00 >> >> This obviously isn't perfect, and I would welcome comments of any sort >> (including, but not limited to, offers for text and/or co-authorship :-) ). >> >> Greetings, >> >> Stefan Winter >> >> -- >> Stefan WINTER >> Ingenieur de Recherche >> Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche >> 6, rue Richard Coudenhove-Kalergi >> L-1359 Luxembourg >> >> Tel: +352 424409 1 >> Fax: +352 422473 >> >> >> _______________________________________________ >> abfab mailing list >> abfab@ietf.org >> https://www.ietf.org/mailman/listinfo/abfab > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab > From hartmans@painless-security.com Fri Jun 10 07:25:04 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 059AD1F0C5E for ; Fri, 10 Jun 2011 07:25:04 -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 Qh9INkk6ackH for ; Fri, 10 Jun 2011 07:25:03 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3D21F0C59 for ; Fri, 10 Jun 2011 07:25:03 -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 2EA1A20424; Fri, 10 Jun 2011 10:20:31 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 38AB64426; Fri, 10 Jun 2011 10:24:50 -0400 (EDT) From: Sam Hartman To: Joe Salowey References: <4DEC97D0.9080608@restena.lu> <8682DBB8-165B-4236-AB84-4AE26DD98105@cisco.com> Date: Fri, 10 Jun 2011 10:24:50 -0400 In-Reply-To: <8682DBB8-165B-4236-AB84-4AE26DD98105@cisco.com> (Joe Salowey's message of "Thu, 9 Jun 2011 18:07:32 -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-winter-abfab-eapapplicability-00 Section 2.1 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, 10 Jun 2011 14:25:04 -0000 I support Joe's proposed revision to authorization data. From hartmans@painless-security.com Fri Jun 10 07:42:50 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 260F411E80C7 for ; Fri, 10 Jun 2011 07:42:50 -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 K26NUjE9DSbK for ; Fri, 10 Jun 2011 07:42:49 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2D011E80B7 for ; Fri, 10 Jun 2011 07:42:49 -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 684A720424; Fri, 10 Jun 2011 10:38:19 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D17A34426; Fri, 10 Jun 2011 10:42:40 -0400 (EDT) From: Sam Hartman To: Joe Salowey References: <4DEC97D0.9080608@restena.lu> <01184CD0-F0FE-4BAB-A68F-FE9C513E2D0E@cisco.com> Date: Fri, 10 Jun 2011 10:42:40 -0400 In-Reply-To: <01184CD0-F0FE-4BAB-A68F-FE9C513E2D0E@cisco.com> (Joe Salowey's message of "Thu, 9 Jun 2011 18:07:57 -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-winter-abfab-eapapplicability-00 section 2.4 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, 10 Jun 2011 14:42:50 -0000 >>>>> "Joe" == Joe Salowey writes: Joe> I think any EAP lower layer should be required to implement Joe> validation of the MSK between the EAP peer and EAP Joe> authenticator. If you are going to mention re-ordering you Joe> might also mention fragmentation. Here is some suggested text, Joe> but I don't think I captured all the information from the Joe> thread on this topic. "2.4. EAP over IP I agree with this. I'm actually kind of uncomfortable though casting this all in terms of EAP over IP. I think that's the wrong focus for the discussion. I'm not objecting to your text--it improves the document--I just wonder whether we could take another pass and de-emphasize the over IP issue. --Sam From hartmans@painless-security.com Fri Jun 10 07:44:03 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 5C6DB11E81D7 for ; Fri, 10 Jun 2011 07:44:03 -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 0MSbZfEE2zQ0 for ; Fri, 10 Jun 2011 07:44:03 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id E20CD11E818D for ; Fri, 10 Jun 2011 07:44:02 -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 16FE52043E; Fri, 10 Jun 2011 10:39:33 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 838144426; Fri, 10 Jun 2011 10:43:54 -0400 (EDT) From: Sam Hartman To: Joe Salowey References: <4DEC97D0.9080608@restena.lu> <54543717-39AA-4FE5-8C01-28B21AF3E36B@cisco.com> Date: Fri, 10 Jun 2011 10:43:54 -0400 In-Reply-To: <54543717-39AA-4FE5-8C01-28B21AF3E36B@cisco.com> (Joe Salowey's message of "Thu, 9 Jun 2011 18:07:39 -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-winter-abfab-eapapplicability-00 section 2.2 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, 10 Jun 2011 14:44:03 -0000 Do we want to discuss NEA at all in this document? I kind of thought we were tasked with expanding the EAP applicability statement to cover application authentication, not to having open season on revising core EAP applicability. --Sam From smith@Cardiff.ac.uk Mon Jun 13 08:39:31 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 8D6EE21F8517 for ; Mon, 13 Jun 2011 08:39:31 -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 8W4+M13ANJZz for ; Mon, 13 Jun 2011 08:39:30 -0700 (PDT) Received: from smtpout1.cf.ac.uk (smtpout1.cf.ac.uk [131.251.137.125]) by ietfa.amsl.com (Postfix) with ESMTP id 76E4B21F8512 for ; Mon, 13 Jun 2011 08:39:29 -0700 (PDT) Received: from smtpauth.cf.ac.uk ([131.251.248.19]) by smtpout1.cf.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1QW9Ed-000800-SE for abfab@ietf.org; Mon, 13 Jun 2011 16:39:27 +0100 Received: from [10.224.0.45] (helo=dangermouse.insrv.cf.ac.uk) by smtpauth.cf.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1QW9Ed-0000vf-Pc for abfab@ietf.org; Mon, 13 Jun 2011 16:39:27 +0100 From: Rhys Smith Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Jun 2011 16:39:27 +0100 Message-Id: <1885B701-77AB-408E-B2F4-5CC4A9FA02A6@cardiff.ac.uk> To: abfab@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Sender: smith@Cardiff.ac.uk X-Virus-Scanned: Cardiff University Virus Scanner X-Virus-Scanned: Cardiff University Virus Scanner Subject: [abfab] Work Item: OID registry 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, 13 Jun 2011 15:39:31 -0000 Hi All, I volunteered to look after the OID registry for ABFAB related = shenanigans. I've made an outline doc and submitted as as -00 draft: http://tools.ietf.org/html/draft-smith-abfab-oidregistry-00 Obviously it's a little sparse at the moment as we don't actually have = any usage of it yet. I've included the private OID arc of Luke's in = there for reference (but will be deleting that section before the final = draft). The main reason for submitting it as it is to get a bit of discussion = going around the two major topics: 1) What structure should the arc have? Should we follow Luke's structure = and have mechanisms, nameTypes, and apiExtensions sub-arcs? Do we need = more? Or not need those at all? And what values should be going in there = - are we ready / is it necessary yet to start shifting some over from = the private arcs in use today to the more standards-based aims of the = ABFAB arc? 2) What should the process be to maintain this arc once we hand it over = to IANA? Do we think we should be quite strict (e.g. the Expert Review / = Specification Required models) or a bit less strict (e.g. the First Come = FIrst Served model)? Or split the namespace up into a few categories = with each maintained separately (i.e a strictly managed globally = applicable set of OIDs and set of OIDs dedicated to being free-for-all = "site specific"? Thoughts? Opinions? It'd be good to come to some kind of consensus for the structure and = overall maintenance process model, documented in a -01 draft, in time = for the cut-off for IETF81... Kind Regards, Rhys. -- ---------------------------------------------------------------------- Dr Rhys Smith e: smith@cardiff.ac.uk Engineering Consultant: Identity & Access Management (GPG:0xDE2F024C) Information Services, Cardiff University, t: +44 (0) 29 2087 0126 39-41 Park Place, Cardiff, f: +44 (0) 29 2087 4285 CF10 3BB, United Kingdom. m: +44 (0) 7968 087 821 ---------------------------------------------------------------------- From alex@um.es Tue Jun 14 02:13:25 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 B1DC911E8075 for ; Tue, 14 Jun 2011 02:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 Nfd5RqcXHDaF for ; Tue, 14 Jun 2011 02:13:25 -0700 (PDT) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id D51F211E8083 for ; Tue, 14 Jun 2011 02:13:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id A70344BCC2 for ; Tue, 14 Jun 2011 11:13:21 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Giy1lWgLJbiu for ; Tue, 14 Jun 2011 11:13:21 +0200 (CEST) Received: from [155.54.205.224] (inf-205-224.inf.um.es [155.54.205.224]) (Authenticated sender: alex) by xenon12.um.es (Postfix) with ESMTPA id 2F0234BCDC for ; Tue, 14 Jun 2011 11:13:20 +0200 (CEST) Message-ID: <4DF7262F.5000507@um.es> Date: Tue, 14 Jun 2011 11:13:19 +0200 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: abfab@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [abfab] FYI: New draft for Kerberos pre-authentication based on EAP-GSS 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, 14 Jun 2011 09:13:25 -0000 FYI >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > Title : GSS-EAP pre-authentication for Kerberos > Author(s) : Alejandro Perez-Mendez > Rafa Marin-Lopez > Fernando Pereniguez-Garcia > Gabriel Lopez-Millan > Filename : draft-perez-abfab-eap-gss-preauth-00.txt > Pages : 14 > Date : 2011-06-14 > > This draft defines an alternative to the standard cross-realm > operation in Kerberos, to allow users from an organization can obtain > a TGT from the KDC of a different one, both belonging to the same > AAA-based federation. This proposal makes use of the GSS-API pre- > authentication for Kerberos and the GSS-API Mechanism for the > Extensible Authentication Protocol to carry out the required > functionality. > > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-perez-abfab-eap-gss-preauth-00.t >xt > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >This Internet-Draft can be retrieved at: >ftp://ftp.ietf.org/internet-drafts/draft-perez-abfab-eap-gss-preauth-00.tx >t From stefan.winter@restena.lu Fri Jun 17 06:52:05 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 2FFB511E817C for ; Fri, 17 Jun 2011 06:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 3bfbN40AwBNp for ; Fri, 17 Jun 2011 06:52:04 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 48DF411E8179 for ; Fri, 17 Jun 2011 06:52:03 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 467AE10584; Fri, 17 Jun 2011 15:51:59 +0200 (CEST) Received: from [IPv6:2001:a18:1:8::155] (unknown [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 37D9B10581; Fri, 17 Jun 2011 15:51:59 +0200 (CEST) Message-ID: <4DFB5BFB.6040001@restena.lu> Date: Fri, 17 Jun 2011 15:51:55 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Sam Hartman References: <4DEC97D0.9080608@restena.lu> <54543717-39AA-4FE5-8C01-28B21AF3E36B@cisco.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF6FDBA314C605B8E100B439F" X-Virus-Scanned: ClamAV Cc: abfab@ietf.org Subject: Re: [abfab] Comments on draft-winter-abfab-eapapplicability-00 section 2.2 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, 17 Jun 2011 13:52:05 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF6FDBA314C605B8E100B439F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > Do we want to discuss NEA at all in this document? I kind of thought w= e > were tasked with expanding the EAP applicability statement to cover > application authentication, not to having open season on revising core > EAP applicability. Well, the chance to update the EAP applicability statement doesn't come along every day. I think that while we're at it, we should work to cover all ground that is currently going on in the IETF. NEA is doing new chartered work that goes beyond the EAP applicability statement - and we are changing that same statement simultaneously. IMHO, it would be a shame not to incorporate that work into the applicability considerations.= Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enigF6FDBA314C605B8E100B439F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk37W/8ACgkQ+jm90f8eFWZQ5wCghiRz5AJAWSTlsexj+daFO+mi T0YAnReWB5APYGKuh10IaOHBMM1oTska =UDoq -----END PGP SIGNATURE----- --------------enigF6FDBA314C605B8E100B439F-- From steve@hannas.com Fri Jun 17 14:52:25 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 A65EB11E8110 for ; Fri, 17 Jun 2011 14:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 QbCT7nhi69wQ for ; Fri, 17 Jun 2011 14:52:24 -0700 (PDT) Received: from hannas.com (hannas.com [206.130.122.62]) by ietfa.amsl.com (Postfix) with ESMTP id CBA1F11E80EF for ; Fri, 17 Jun 2011 14:52:24 -0700 (PDT) Received: from [172.28.130.90] (westford-nat.juniper.net [66.129.232.2]) (authenticated bits=0) by hannas.com (8.13.1/8.13.1) with ESMTP id p5HLq71t028674 for ; Fri, 17 Jun 2011 15:52:09 -0600 Message-ID: <4DFBCC87.1010702@hannas.com> Date: Fri, 17 Jun 2011 17:52:07 -0400 From: Steve Hanna User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: abfab@ietf.org References: <4DEC97D0.9080608@restena.lu> <54543717-39AA-4FE5-8C01-28B21AF3E36B@cisco.com> <4DFB5BFB.6040001@restena.lu> In-Reply-To: <4DFB5BFB.6040001@restena.lu> Content-Type: multipart/alternative; boundary="------------030008030705000007060702" Subject: Re: [abfab] Comments on draft-winter-abfab-eapapplicability-00 section 2.2 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, 17 Jun 2011 21:52:25 -0000 This is a multi-part message in MIME format. --------------030008030705000007060702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I agree. No point in revising the EAP applicability statement twice! If you want a NEA expert to help on the project, count me in. Thanks, Steve Hanna NEA WG co-chair On 6/17/2011 9:51 AM, Stefan Winter wrote: > Hi, > >> Do we want to discuss NEA at all in this document? I kind of thought we >> were tasked with expanding the EAP applicability statement to cover >> application authentication, not to having open season on revising core >> EAP applicability. > Well, the chance to update the EAP applicability statement doesn't come > along every day. I think that while we're at it, we should work to cover > all ground that is currently going on in the IETF. NEA is doing new > chartered work that goes beyond the EAP applicability statement - and we > are changing that same statement simultaneously. IMHO, it would be a > shame not to incorporate that work into the applicability considerations. > > Greetings, > > Stefan Winter > > > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab --------------030008030705000007060702 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I agree. No point in revising the EAP applicability statement twice! If you want a NEA expert to help on the project, count me in.

Thanks,

Steve Hanna
NEA WG co-chair

On 6/17/2011 9:51 AM, Stefan Winter wrote: 
Hi,


Do we want to discuss NEA at all in this document?  I kind of thought we
were tasked with expanding the EAP applicability statement to cover
application authentication, not to having open season on revising core
EAP applicability.

Well, the chance to update the EAP applicability statement doesn't come
along every day. I think that while we're at it, we should work to cover
all ground that is currently going on in the IETF. NEA is doing new
chartered work that goes beyond the EAP applicability statement - and we
are changing that same statement simultaneously. IMHO, it would be a
shame not to incorporate that work into the applicability considerations.

Greetings,

Stefan Winter



_______________________________________________
abfab mailing list
abfab@ietf.org
https://www.ietf.org/mailman/listinfo/abfab
--------------030008030705000007060702-- From klaas@cisco.com Fri Jun 24 02:56:34 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 CCEC611E81C3 for ; Fri, 24 Jun 2011 02:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 gWs3DIjdzcZl for ; Fri, 24 Jun 2011 02:56:34 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id C2D5E11E81BB for ; Fri, 24 Jun 2011 02:56:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=522; q=dns/txt; s=iport; t=1308909393; x=1310118993; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=EHvau2LGaNU5iyW5+hhVmimkeWaWrBRm4oY8fQdWGwc=; b=Kqc6tbB7YzZcmYc+zL70YMOOBZyxKcw9psp1cqtb7pmEr5x7jf17wfZi rrPWy0s2xfEEmM9fHQZRelGynmz9dKXB2E9p8BsLLea5GH1adOJaTkz1Q K2VIbu34Qj6UzVUWLp6AqJEzmKKm9h3Tw/46saMcRD066gcQgpe+D9SSi E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkGAA9fBE6Q/khL/2dsb2JhbABSpzVwB6togR2eFoYtBJF7kBQ X-IronPort-AV: E=Sophos;i="4.65,418,1304294400"; d="scan'208";a="97665485" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 24 Jun 2011 09:56:22 +0000 Received: from macmini.wierenga.net (ams-kwiereng-8712.cisco.com [10.55.220.243]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5O9uMqe013625 for ; Fri, 24 Jun 2011 09:56:22 GMT Message-ID: <4E045F46.6040003@cisco.com> Date: Fri, 24 Jun 2011 11:56:22 +0200 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "abfab@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [abfab] call for presentations @IETF81 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, 24 Jun 2011 09:56:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Our preliminary slot at IETF81 is: ABFAB Session 1 (2.5 hours) Friday, Morning Session I 0900-1130 Room Name: 204 B Please let Leif and myself know if you want to present. Klaas -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4EX0YACgkQH2Wy/p4XeFK1gACbBYxb9oRkDR5J6NW8veUZ+KKj 6wIAoJmIYAU4xrIYs11/w1eUWGgx47am =1myM -----END PGP SIGNATURE----- From lukeh@padl.com Wed Jun 29 03:15:23 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 D0BD49E8034 for ; Wed, 29 Jun 2011 03:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 V++H2I5RM7sC for ; Wed, 29 Jun 2011 03:15:23 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 18EAE9E8032 for ; Wed, 29 Jun 2011 03:15:22 -0700 (PDT) Received: by us.padl.com with ESMTP id p5TAFGS6028668; Wed, 29 Jun 2011 06:15:19 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: Date: Wed, 29 Jun 2011 10:15:15 +0000 Content-Transfer-Encoding: 7bit Message-Id: <5FF8869A-D7BA-435E-88CA-03CD6DA5B791@padl.com> 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_00, RCVD_IN_PBL, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC, USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.1 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: Wed, 29 Jun 2011 10:15:23 -0000 Any progress on this? -- Luke On 31/05/2011, at 9:13 PM, Luke Howard wrote: > > 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 > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab -- Luke Howard / lukeh@padl.com www.padl.com / www.lukehoward.com From hartmans@painless-security.com Wed Jun 29 06:18:11 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 ADBB711E8079 for ; Wed, 29 Jun 2011 06:18:11 -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 meNGAipu5TO9 for ; Wed, 29 Jun 2011 06:18:11 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 0889111E8095 for ; Wed, 29 Jun 2011 06:18:08 -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 641742016A; Wed, 29 Jun 2011 09:13:16 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 63DBB4307; Wed, 29 Jun 2011 09:17:59 -0400 (EDT) From: Sam Hartman To: Luke Howard References: <79AA0F35-87D1-426C-9C1D-03C8BEE9F6CE@padl.com> <5FF8869A-D7BA-435E-88CA-03CD6DA5B791@padl.com> Date: Wed, 29 Jun 2011 09:17:59 -0400 In-Reply-To: <5FF8869A-D7BA-435E-88CA-03CD6DA5B791@padl.com> (Luke Howard's message of "Wed, 29 Jun 2011 10:15:15 +0000") 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: Wed, 29 Jun 2011 13:18:11 -0000 >>>>> "Luke" == Luke Howard writes: Luke> Any progress on this? Yes. I just spent this morning going through your code and deriving my understanding of what gets spit out and am starting to write it up. I understand you've written things down in e-mail; I have that mail and will go back and check against it. However I thought it would be good to have an independent analysis so when you read my write-up you can see if my understanding matches what you expect.