From nobody Sun Nov 2 23:54:09 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA0CC1A6FBE for ; Sun, 2 Nov 2014 23:54:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.795 X-Spam-Level: X-Spam-Status: No, score=-6.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4M2BYOYYQ-L for ; Sun, 2 Nov 2014 23:54:06 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31BB31A0410 for ; Sun, 2 Nov 2014 23:54:06 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOI64067; Mon, 03 Nov 2014 07:54:04 +0000 (GMT) Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml403-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Mon, 3 Nov 2014 07:54:03 +0000 From: Hosnieh Rafiee To: "secauth@ietf.org" Thread-Topic: Reminder: Telco today at 3 PM Berlin time Thread-Index: AQHP9ztVCdbmSNRDmUu0ZJ8XRKvbaw== Date: Mon, 3 Nov 2014 07:54:03 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A4F517@lhreml513-mbb.china.huawei.com> References: <814D0BFB77D95844A01CA29B44CBF8A7A4F071@lhreml513-mbb.china.huawei.com> In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A7A4F071@lhreml513-mbb.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/k1dSPq9YbW-fv1d_pmt3PlBXbGQ Subject: [Secauth] Reminder: Telco today at 3 PM Berlin time X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 07:54:07 -0000 All, According to doodle poll, today at 3 PM Berlin time. Please check it here. I will send conference call invitations to the list of attendees. Thanks, Best, Hosnieh From nobody Tue Nov 4 02:02:25 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B96F51A6F8F for ; Tue, 4 Nov 2014 02:02:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Mc5yTsOJwbd for ; Tue, 4 Nov 2014 02:02:20 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F97F1A8935 for ; Tue, 4 Nov 2014 02:02:20 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOJ91753; Tue, 04 Nov 2014 10:02:19 +0000 (GMT) Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml402-hub.china.huawei.com ([10.201.5.241]) with mapi id 14.03.0158.001; Tue, 4 Nov 2014 10:02:13 +0000 From: Hosnieh Rafiee To: "secauth@ietf.org" Thread-Topic: Summary of telco meeting on 3 Nov. Thread-Index: AQHP+BZnvbhQA4SO20q024+UszKPvA== Date: Tue, 4 Nov 2014 10:02:12 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A4FCB3@lhreml513-mbb.china.huawei.com> References: <814D0BFB77D95844A01CA29B44CBF8A7A4F071@lhreml513-mbb.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A4F517@lhreml513-mbb.china.huawei.com> In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A7A4F517@lhreml513-mbb.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/Qc2PrGN9Zw8FxG_BJiYkofzo6zM Subject: [Secauth] Summary of telco meeting on 3 Nov. X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 10:02:23 -0000 All, Here is the suggestions provided by attendees during the Telco yesterday. - Writing a short gap analysis for secauth (doesn't need to be a complete g= ap analysis but only to identify the scope) - Modify the charter to address the following use case User 1 enters gives its information to hotspot A so that it can use interne= t (or some services). User 1 moves to location B where hotspot B exists. He= disconnected from the service and again needs to give its information to h= otspot B so that it can continue using Internet (or other services). User 1= needs a mechanisms that his information automatically submitted to the new= hotspot as soon as this user moves to new location and his computer regist= ers it. This is like hand over in mobile networks but now we are talking ab= out WAN or different public networks (possibly from different ISPs). There is a need for a mechanism to submit the user's information from hotsp= ot A to hotspot B so that hotspot B can authenticate this user and let this= user continue using its service (internet). This process should be all aut= omatic except the first time user gives its information to the first hotspo= t. (hotspot should be considered as logical devices in virtualized environm= ent) - Submit the above result to both IETF discussion lists and also secauth li= st so that folks who are not aware of this group also join to discuss. Any thoughts? Please also share your opinion about the date for bar meeting at IETF. I am= going to schedule this on doodle. Thanks, Best, Hosnieh From nobody Tue Nov 4 02:34:27 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 648361A0861 for ; Tue, 4 Nov 2014 02:34:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J64WVrMf6jt6 for ; Tue, 4 Nov 2014 02:34:24 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07B831A0191 for ; Tue, 4 Nov 2014 02:34:23 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id sA4AXlAW025748; Tue, 4 Nov 2014 11:33:47 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id CF207202348; Tue, 4 Nov 2014 11:33:53 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C3393202301; Tue, 4 Nov 2014 11:33:53 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id sA4AXfKP005622; Tue, 4 Nov 2014 11:33:47 +0100 Message-ID: <5458AB84.4040005@gmail.com> Date: Tue, 04 Nov 2014 11:33:40 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Hosnieh Rafiee References: <814D0BFB77D95844A01CA29B44CBF8A7A4F071@lhreml513-mbb.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A4F517@lhreml513-mbb.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A4FCB3@lhreml513-mbb.china.huawei.com> In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A7A4FCB3@lhreml513-mbb.china.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/oeBE5MzNVFBOEaX8sUsDelm5t0g Cc: "secauth@ietf.org" Subject: Re: [Secauth] Summary of telco meeting on 3 Nov. X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 10:34:26 -0000 Le 04/11/2014 11:02, Hosnieh Rafiee a écrit : > All, > > Here is the suggestions provided by attendees during the Telco > yesterday. - Writing a short gap analysis for secauth (doesn't need > to be a complete gap analysis but only to identify the scope) - > Modify the charter to address the following use case > > User 1 enters gives its information to hotspot A so that it can use > internet (or some services). User 1 moves to location B where hotspot > B exists. He disconnected from the service and again needs to give > its information to hotspot B so that it can continue using Internet > (or other services). User 1 needs a mechanisms that his information > automatically submitted to the new hotspot as soon as this user moves > to new location and his computer registers it. This is like hand over > in mobile networks but now we are talking about WAN or different > public networks (possibly from different ISPs). There is a need for a > mechanism to submit the user's information from hotspot A to hotspot > B so that hotspot B can authenticate this user and let this user > continue using its service (internet). This process should be all > automatic except the first time user gives its information to the > first hotspot. (hotspot should be considered as logical devices in > virtualized environment) > > > - Submit the above result to both IETF discussion lists and also > secauth list so that folks who are not aware of this group also join > to discuss. > > Any thoughts? Hi Hosnieh, The mobility scenario that may be relevant is that the user provides the credentials automatically to each hotspot. It may not be the same credentials for each hotspot, but it should be automated. It may not be just credentials but some simple info some times. Think when one connects a laptop to a hotspot: some times user/password is required, some times the creditcard, or the skype id, other times just an email address, some other times just check to agree on the usage conditions. There is a huge number of different ways in which the hotspots allow one to connect to it. Some use link-layer auth, others use web capturing portals and firewalling rules. Some allow for only 15minutes free, others 15minutes free renewable. If all this were automated then the connection experience would be more 'smooth' to the end user. It would allow also connections of devices w/o screen/kbd (IoT). I don't know whether a mechanism/protocol is needed or possible, or maybe just some hints from the network about that hotspot be scriptable or not. AS an example, where I live there is this WiFi Connect 2.0 application on smartphones on which one enters complicated credentials of several ISPs and then the app attaches automatically to each of them when available. It works with these particular hotspots operated by large ISPs but does not work with many other hotspots operated by other craftsmen. Is there a way to turn this into an SDN feature? (send an openflow message to add a firewall rule open the access). Is it a pure software-only issue? (no protocol involved). Other places at IETF where this scenario may have been discussed? Alex > > Please also share your opinion about the date for bar meeting at > IETF. I am going to schedule this on doodle. > > > Thanks, Best, Hosnieh > > > _______________________________________________ Secauth mailing list > Secauth@ietf.org https://www.ietf.org/mailman/listinfo/secauth > > From nobody Tue Nov 4 04:58:38 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0EB21A1B0F for ; Tue, 4 Nov 2014 04:58:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtBcHd9csF-7 for ; Tue, 4 Nov 2014 04:58:32 -0800 (PST) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C1221A1B06 for ; Tue, 4 Nov 2014 04:58:32 -0800 (PST) Received: by mail-qc0-f169.google.com with SMTP id i17so10937453qcy.14 for ; Tue, 04 Nov 2014 04:58:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Zz/PY1zFRwcTyWXaEUBmqcDq3mNoHINc3V5SFUrYHBg=; b=IqLMsoPokWYk/5kUmghGdxJGt47lThXBRYtjevCWyPWnjhQY20kG8yLgTInEk4yZ82 yC32PMiHCnfQ5sU63nZrExQLZZsZTKrYjVBChQdwbkeh4PvZcXHZnN2GSPcpr8VEsfzA vChRonTRPeS42U0J9P3CMGofmaaW6ROiX8qfvopq/HFeCUr501U+ufx62hbksjRb1KWy mtyHDVlFgNSuEnRpUxwTnLk6Kdu/XwxSRytfXwHnsEHINGdXMEZ4Ne4D/al3HLy3kIh8 Ep/Vv+Ev8rQzRXD6kYtlFuQtMUpdmlVuSbdZg87KuEVqAT54mDRFbeCzpL/fugP9C+ZB ECmg== X-Received: by 10.229.120.198 with SMTP id e6mr68965571qcr.25.1415105911559; Tue, 04 Nov 2014 04:58:31 -0800 (PST) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id d32sm294148qge.20.2014.11.04.04.58.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Nov 2014 04:58:29 -0800 (PST) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: <5458AB84.4040005@gmail.com> Date: Tue, 4 Nov 2014 07:58:29 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <082764AC-A44F-4E15-9DAB-714E90FD7B99@gmail.com> References: <814D0BFB77D95844A01CA29B44CBF8A7A4F071@lhreml513-mbb.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A4F517@lhreml513-mbb.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A4FCB3@lhreml513-mbb.china.huawei.com> <5458AB84.4040005@gmail.com> To: Alexandru Petrescu Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/9Oe6nencRhKM9osPjEWk1qeEri4 Cc: Hosnieh Rafiee , "secauth@ietf.org" Subject: Re: [Secauth] Summary of telco meeting on 3 Nov. X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 12:58:35 -0000 Sent from my iPhone > On Nov 4, 2014, at 5:33 AM, Alexandru Petrescu wrote: >=20 > Le 04/11/2014 11:02, Hosnieh Rafiee a =C3=A9crit : >> All, >>=20 >> Here is the suggestions provided by attendees during the Telco >> yesterday. - Writing a short gap analysis for secauth (doesn't need >> to be a complete gap analysis but only to identify the scope) - >> Modify the charter to address the following use case >>=20 >> User 1 enters gives its information to hotspot A so that it can use >> internet (or some services). User 1 moves to location B where hotspot >> B exists. He disconnected from the service and again needs to give >> its information to hotspot B so that it can continue using Internet >> (or other services). User 1 needs a mechanisms that his information >> automatically submitted to the new hotspot as soon as this user moves >> to new location and his computer registers it. This is like hand over >> in mobile networks but now we are talking about WAN or different >> public networks (possibly from different ISPs). There is a need for a >> mechanism to submit the user's information from hotspot A to hotspot >> B so that hotspot B can authenticate this user and let this user >> continue using its service (internet). This process should be all >> automatic except the first time user gives its information to the >> first hotspot. (hotspot should be considered as logical devices in >> virtualized environment) >>=20 >>=20 >> - Submit the above result to both IETF discussion lists and also >> secauth list so that folks who are not aware of this group also join >> to discuss. >>=20 >> Any thoughts? >=20 > Hi Hosnieh, >=20 > The mobility scenario that may be relevant is that the user provides the c= redentials automatically to each hotspot. It may not be the same credential= s for each hotspot, but it should be automated. It may not be just credenti= als but some simple info some times. >=20 > Think when one connects a laptop to a hotspot: some times user/password is= required, some times the creditcard, or the skype id, other times just an e= mail address, some other times just check to agree on the usage conditions. = There is a huge number of different ways in which the hotspots allow one to= connect to it. >=20 > Some use link-layer auth, others use web capturing portals and firewalling= rules. >=20 > Some allow for only 15minutes free, others 15minutes free renewable. >=20 > If all this were automated then the connection experience would be more 's= mooth' to the end user. It would allow also connections of devices w/o scre= en/kbd (IoT). >=20 > I don't know whether a mechanism/protocol is needed or possible, or maybe j= ust some hints from the network about that hotspot be scriptable or not. >=20 > AS an example, where I live there is this WiFi Connect 2.0 application on s= martphones on which one enters complicated credentials of several ISPs and t= hen the app attaches automatically to each of them when available. >=20 > It works with these particular hotspots operated by large ISPs but does no= t work with many other hotspots operated by other craftsmen. >=20 > Is there a way to turn this into an SDN feature? (send an openflow messag= e to add a firewall rule open the access). >=20 > Is it a pure software-only issue? (no protocol involved). >=20 > Other places at IETF where this scenario may have been discussed? >=20 Yes, take a look at the IP Mobility WG publications. http://www.ietf.org/wg/concluded/mobileip.html Best regards, Kathleen > Alex >=20 >>=20 >> Please also share your opinion about the date for bar meeting at >> IETF. I am going to schedule this on doodle. >>=20 >>=20 >> Thanks, Best, Hosnieh >>=20 >>=20 >> _______________________________________________ Secauth mailing list >> Secauth@ietf.org https://www.ietf.org/mailman/listinfo/secauth >=20 >=20 > _______________________________________________ > Secauth mailing list > Secauth@ietf.org > https://www.ietf.org/mailman/listinfo/secauth From nobody Tue Nov 4 05:38:55 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD1D91A012D for ; Tue, 4 Nov 2014 05:38:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXfX2bM49XOz for ; Tue, 4 Nov 2014 05:38:48 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EC371A1B2F for ; Tue, 4 Nov 2014 05:38:47 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id sA4DcXaQ026790; Tue, 4 Nov 2014 14:38:33 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C2F7F2024CA; Tue, 4 Nov 2014 14:38:39 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id B45B5202437; Tue, 4 Nov 2014 14:38:39 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id sA4DcWl8018203; Tue, 4 Nov 2014 14:38:33 +0100 Message-ID: <5458D6D8.5090703@gmail.com> Date: Tue, 04 Nov 2014 14:38:32 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Kathleen Moriarty References: <814D0BFB77D95844A01CA29B44CBF8A7A4F071@lhreml513-mbb.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A4F517@lhreml513-mbb.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A4FCB3@lhreml513-mbb.china.huawei.com> <5458AB84.4040005@gmail.com> <082764AC-A44F-4E15-9DAB-714E90FD7B99@gmail.com> In-Reply-To: <082764AC-A44F-4E15-9DAB-714E90FD7B99@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/shVuOpIUEYIez2LpI8PIUmkfwts Cc: Hosnieh Rafiee , "secauth@ietf.org" Subject: Re: [Secauth] Summary of telco meeting on 3 Nov. X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 13:38:51 -0000 Le 04/11/2014 13:58, Kathleen Moriarty a écrit : > > > Sent from my iPhone > >> On Nov 4, 2014, at 5:33 AM, Alexandru Petrescu wrote: >> >> Le 04/11/2014 11:02, Hosnieh Rafiee a écrit : >>> All, >>> >>> Here is the suggestions provided by attendees during the Telco >>> yesterday. - Writing a short gap analysis for secauth (doesn't need >>> to be a complete gap analysis but only to identify the scope) - >>> Modify the charter to address the following use case >>> >>> User 1 enters gives its information to hotspot A so that it can use >>> internet (or some services). User 1 moves to location B where hotspot >>> B exists. He disconnected from the service and again needs to give >>> its information to hotspot B so that it can continue using Internet >>> (or other services). User 1 needs a mechanisms that his information >>> automatically submitted to the new hotspot as soon as this user moves >>> to new location and his computer registers it. This is like hand over >>> in mobile networks but now we are talking about WAN or different >>> public networks (possibly from different ISPs). There is a need for a >>> mechanism to submit the user's information from hotspot A to hotspot >>> B so that hotspot B can authenticate this user and let this user >>> continue using its service (internet). This process should be all >>> automatic except the first time user gives its information to the >>> first hotspot. (hotspot should be considered as logical devices in >>> virtualized environment) >>> >>> >>> - Submit the above result to both IETF discussion lists and also >>> secauth list so that folks who are not aware of this group also join >>> to discuss. >>> >>> Any thoughts? >> >> Hi Hosnieh, >> >> The mobility scenario that may be relevant is that the user provides the credentials automatically to each hotspot. It may not be the same credentials for each hotspot, but it should be automated. It may not be just credentials but some simple info some times. >> >> Think when one connects a laptop to a hotspot: some times user/password is required, some times the creditcard, or the skype id, other times just an email address, some other times just check to agree on the usage conditions. There is a huge number of different ways in which the hotspots allow one to connect to it. >> >> Some use link-layer auth, others use web capturing portals and firewalling rules. >> >> Some allow for only 15minutes free, others 15minutes free renewable. >> >> If all this were automated then the connection experience would be more 'smooth' to the end user. It would allow also connections of devices w/o screen/kbd (IoT). >> >> I don't know whether a mechanism/protocol is needed or possible, or maybe just some hints from the network about that hotspot be scriptable or not. >> >> AS an example, where I live there is this WiFi Connect 2.0 application on smartphones on which one enters complicated credentials of several ISPs and then the app attaches automatically to each of them when available. >> >> It works with these particular hotspots operated by large ISPs but does not work with many other hotspots operated by other craftsmen. >> >> Is there a way to turn this into an SDN feature? (send an openflow message to add a firewall rule open the access). >> >> Is it a pure software-only issue? (no protocol involved). >> >> Other places at IETF where this scenario may have been discussed? >> > > Yes, take a look at the IP Mobility WG publications. > > http://www.ietf.org/wg/concluded/mobileip.html Well I think the Mobile IP related RFCs do not deal with this particular case. Not sure whether you have one particular document in mind? Alex > > Best regards, > Kathleen > >> Alex >> >>> >>> Please also share your opinion about the date for bar meeting at >>> IETF. I am going to schedule this on doodle. >>> >>> >>> Thanks, Best, Hosnieh >>> >>> >>> _______________________________________________ Secauth mailing list >>> Secauth@ietf.org https://www.ietf.org/mailman/listinfo/secauth >> >> >> _______________________________________________ >> Secauth mailing list >> Secauth@ietf.org >> https://www.ietf.org/mailman/listinfo/secauth > > From nobody Tue Nov 4 05:40:44 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD8E1A1B46 for ; Tue, 4 Nov 2014 05:40:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkh0qgLeppgw for ; Tue, 4 Nov 2014 05:40:39 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C6701A1B32 for ; Tue, 4 Nov 2014 05:40:38 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOK15584; Tue, 04 Nov 2014 13:40:37 +0000 (GMT) Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml406-hub.china.huawei.com ([10.201.5.243]) with mapi id 14.03.0158.001; Tue, 4 Nov 2014 13:40:35 +0000 From: Hosnieh Rafiee To: Alexandru Petrescu Thread-Topic: [Secauth] Summary of telco meeting on 3 Nov. Thread-Index: AQHP+BrnVpP1Sct5R0OZk6XU2MO2CJxQRp4g Date: Tue, 4 Nov 2014 13:40:34 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A4FDC2@lhreml513-mbb.china.huawei.com> References: <814D0BFB77D95844A01CA29B44CBF8A7A4F071@lhreml513-mbb.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A4F517@lhreml513-mbb.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A4FCB3@lhreml513-mbb.china.huawei.com> <5458AB84.4040005@gmail.com> In-Reply-To: <5458AB84.4040005@gmail.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.97.237] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/VDz1gMydE389Mt7YXZOiUrsju1c Cc: Kathleen Moriarty , "secauth@ietf.org" Subject: Re: [Secauth] Summary of telco meeting on 3 Nov. X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 13:40:41 -0000 Hi Alex, Thanks alot for your message and the clarification of the use case. Maybe we can divide the problem into two sub-problems * information requires by hotspots *=20 > The mobility scenario that may be relevant is that the user provides > the credentials automatically to each hotspot. It may not be the same > credentials for each hotspot, but it should be automated. It may not > be just credentials but some simple info some times. When we want to assume that information needs to exchange among hotspots ar= e not always the same then we might have the following scenarios:=20 1- we probably need to have a resource server where keeps information about= all users who want to use such service (the information that usually are t= aken by hotspots) How? This can be solve via different ways (we can keep it open to solution = space and let people to contribute) What the problem is: - Access control for this resource server - Users' privacy since these information should be available somewhere o= n data centers and all hotspots need to access to the information they woul= d request. - Security issue: resource server is hacked. Advantage:=20 - automation without or with minimal user involvements For privacy issue, the possible solution would be the use of non accurate d= ata for users and store them in this resource server or use some algorithms= to remove sensitive data and then store it. Then secauth can be the framew= ork for providing access control. 2- Something similar to the idea of Open ID is needed to be used and hotspo= t needs to implement such idea=20 User securely provides his authentication value to the hotspot and all hots= pot use the same value=20 In this case no framework is needed since the application can itself re-reg= ister the same authentication value automatically to new hotspot as soon as= it lost its connection.=20 Problem:=20 - backward compatibility - Security issue: an attacker can claim to be a hotspot and receive this sh= ared authentication value! If impersonating others is not a big issue (that= in most cases it is) > Think when one connects a laptop to a hotspot: some times user/password > is required, some times the creditcard, or the skype id, other times > just an email address, some other times just check to agree on the > usage conditions. There is a huge number of different ways in which > the hotspots allow one to connect to it. >=20 > Some use link-layer auth, others use web capturing portals and > firewalling rules. >=20 > Some allow for only 15minutes free, others 15minutes free renewable. >=20 > If all this were automated then the connection experience would be more > 'smooth' to the end user. It would allow also connections of devices > w/o screen/kbd (IoT). >=20 > I don't know whether a mechanism/protocol is needed or possible, or > maybe just some hints from the network about that hotspot be scriptable > or not. >=20 > AS an example, where I live there is this WiFi Connect 2.0 application > on smartphones on which one enters complicated credentials of several > ISPs and then the app attaches automatically to each of them when > available. >=20 > It works with these particular hotspots operated by large ISPs but does > not work with many other hotspots operated by other craftsmen. >=20 > Is there a way to turn this into an SDN feature? (send an openflow > message to add a firewall rule open the access). This is possible but needs a very secure and restricted authentication and = authorization model. Because like a normal user, the attacker can also regi= ster a new rule on firewall. > Is it a pure software-only issue? (no protocol involved). >=20 > Other places at IETF where this scenario may have been discussed? As Kathleen also mentioned, this is like mobile IPv6 however, they did not = expect to have any SDN/NFV or virtualization aspects. For example, having = hotspots controlled by a SDN controller or similar scenarios.=20 Mobile IPv6 has a limitation for security configuration because it depends = on IPsec for security. Therefore automation for each hotspot would be an is= sue but probably if we think about combining it with SDN solutions then.. I= guess we need a mechanisms. Any thoughts? Thanks again, Best, Hosnieh From nobody Tue Nov 4 06:04:23 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1231A01A8 for ; Tue, 4 Nov 2014 06:04:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uP-T3_rb9Yyc for ; Tue, 4 Nov 2014 06:04:18 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D8CD1A212A for ; Tue, 4 Nov 2014 06:04:18 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id sA4E49Ct001016; Tue, 4 Nov 2014 15:04:09 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9DE0A202310; Tue, 4 Nov 2014 15:04:15 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 8D346202287; Tue, 4 Nov 2014 15:04:15 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id sA4E3omx003285; Tue, 4 Nov 2014 15:04:09 +0100 Message-ID: <5458DCC6.7030003@gmail.com> Date: Tue, 04 Nov 2014 15:03:50 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Hosnieh Rafiee References: <814D0BFB77D95844A01CA29B44CBF8A7A4F071@lhreml513-mbb.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A4F517@lhreml513-mbb.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A4FCB3@lhreml513-mbb.china.huawei.com> <5458AB84.4040005@gmail.com> <814D0BFB77D95844A01CA29B44CBF8A7A4FDC2@lhreml513-mbb.china.huawei.com> In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A7A4FDC2@lhreml513-mbb.china.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/QFR8l1yA5yKa5k-1Xw9ZXvCA2SM Cc: Kathleen Moriarty , "secauth@ietf.org" Subject: Re: [Secauth] Summary of telco meeting on 3 Nov. X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 14:04:21 -0000 Le 04/11/2014 14:40, Hosnieh Rafiee a écrit : > Hi Alex, Thanks alot for your message and the clarification of the > use case. > > Maybe we can divide the problem into two sub-problems * information > requires by hotspots * Maybe yes the problem may be divided into info required by the hotspots and hotspot readiness to accept automation. Is this what you meant? >> The mobility scenario that may be relevant is that the user >> provides the credentials automatically to each hotspot. It may not >> be the same credentials for each hotspot, but it should be >> automated. It may not be just credentials but some simple info >> some times. > > When we want to assume that information needs to exchange among > hotspots are not always the same then we might have the following > scenarios: Well I didnt mean the hotspots to exchange information among themselves. I think the hotspots are managed by entities that differ largely in their interest and as such wouldn't send data to each other (e.g. McDonald's hotspot will not talk to nearby Starbucks hotspot). And yes, the information a laptop sends to a hotspot in order to obtain Internet connectivity is often very different depending on which hotspot the laptop connects to. > 1- we probably need to have a resource server where keeps information > about all users who want to use such service (the information that > usually are taken by hotspots) Well yes, that is a possibility. It has the advantage of ability to better control everything, perhaps by using a single 'super' identifier. But the requirements for solutions could also include mechanisms that do not require a central server. There could be requirements for: solutions involving a 'super' server, solutions not involving any additional server, solutions requiring modifications of the hotspot Controllers, solutions _not_ requiring so. Maybe _minimal_ modifications to Controllers. > How? This can be solve via different ways (we can keep it open to > solution space and let people to contribute) > > What the problem is: - Access control for this resource server > > - Users' privacy since these information should be available > somewhere on data centers and all hotspots need to access to the > information they would request. > > - Security issue: resource server is hacked. I agree. > Advantage: > > - automation without or with minimal user involvements > > For privacy issue, the possible solution would be the use of non > accurate data for users and store them in this resource server or use > some algorithms to remove sensitive data and then store it. Then > secauth can be the framework for providing access control. > > 2- Something similar to the idea of Open ID is needed to be used and > hotspot needs to implement such idea User securely provides his > authentication value to the hotspot and all hotspot use the same > value In this case no framework is needed since the application can > itself re-register the same authentication value automatically to new > hotspot as soon as it lost its connection. > > Problem: - backward compatibility I agree. I think in addition to OpenID there are also SkypeIDs, and maybe others? > - Security issue: an attacker can claim to be a hotspot and receive > this shared authentication value! If impersonating others is not a > big issue (that in most cases it is) I agree. >> Think when one connects a laptop to a hotspot: some times >> user/password is required, some times the creditcard, or the skype >> id, other times just an email address, some other times just check >> to agree on the usage conditions. There is a huge number of >> different ways in which the hotspots allow one to connect to it. >> >> Some use link-layer auth, others use web capturing portals and >> firewalling rules. >> >> Some allow for only 15minutes free, others 15minutes free >> renewable. >> >> If all this were automated then the connection experience would be >> more 'smooth' to the end user. It would allow also connections of >> devices w/o screen/kbd (IoT). >> >> I don't know whether a mechanism/protocol is needed or possible, >> or maybe just some hints from the network about that hotspot be >> scriptable or not. >> >> AS an example, where I live there is this WiFi Connect 2.0 >> application on smartphones on which one enters complicated >> credentials of several ISPs and then the app attaches automatically >> to each of them when available. >> >> It works with these particular hotspots operated by large ISPs but >> does not work with many other hotspots operated by other >> craftsmen. >> >> Is there a way to turn this into an SDN feature? (send an >> openflow message to add a firewall rule open the access). > > This is possible but needs a very secure and restricted > authentication and authorization model. Because like a normal user, > the attacker can also register a new rule on firewall. I agree. >> Is it a pure software-only issue? (no protocol involved). >> >> Other places at IETF where this scenario may have been discussed? > > > As Kathleen also mentioned, this is like mobile IPv6 however, they > did not expect to have any SDN/NFV or virtualization aspects. For > example, having hotspots controlled by a SDN controller or similar > scenarios. > > > Mobile IPv6 has a limitation for security configuration because it > depends on IPsec for security. Therefore automation for each hotspot > would be an issue but probably if we think about combining it with > SDN solutions then.. I guess we need a mechanisms. > > Any thoughts? I think that Mobile IPv6 normal working is hampered by the lack of automated connectivity to wifi hotspots. Mobile IPv6 is designed and implemented to work standalone - much effort went into automated handover management: when in controlled WiFi environments the MIP implementations hand over very smoothly. But when connecting to real-world hotspots the entire magnificence of Mobile IPv6 smooth handoverrs is lost because of this need of user intervention to the capturing web portals. Were this automated hotspot security connection be in place then Mobile IP would work better. Listening... Alex > > Thanks again, Best, Hosnieh > > > From nobody Tue Nov 4 11:42:38 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3B8E1A6FCC for ; Tue, 4 Nov 2014 11:42:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.094 X-Spam-Level: X-Spam-Status: No, score=-1.094 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOvhl2CwmVmc for ; Tue, 4 Nov 2014 11:42:31 -0800 (PST) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8FD81A1BBE for ; Tue, 4 Nov 2014 11:42:30 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id EBE8125CA024; Tue, 4 Nov 2014 19:42:27 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8SwI7NGQcLa; Tue, 4 Nov 2014 20:41:58 +0100 (CET) Received: from kopoli (p5B34173C.dip0.t-ipconnect.de [91.52.23.60]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id A86EB25CA001; Tue, 4 Nov 2014 20:41:57 +0100 (CET) From: "Hosnieh Rafiee" To: References: <814D0BFB77D95844A01CA29B44CBF8A7A4F071@lhreml513-mbb.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A4F517@lhreml513-mbb.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A4FCB3@lhreml513-mbb.china.huawei.com> <5458AB84.4040005@gmail.com> <814D0BFB77D95844A01CA29B44CBF8A7A4FDC2@lhreml513-mbb.china.huawei.com> <5458DCC6.7030003@gmail.com> <814D0BFB77D95844A01CA29B44CBF8A7A4FE9D@lhreml513-mbb.china.huawei.com> In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A7A4FE9D@lhreml513-mbb.china.huawei.com> Date: Tue, 4 Nov 2014 20:41:54 +0100 Message-ID: <009c01cff867$6462a4e0$2d27eea0$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQC90B7QYxgWio9VAiOusOw9Q8inGgMp9RMCAiGev4MCM7rXQQG1+vJhAbvvTnwCyHO2GJ4HWAeg Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/vmALDUbc3yT-5VmPuaEMa-HKDjA Cc: secauth@ietf.org Subject: Re: [Secauth] Summary of telco meeting on 3 Nov. X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 19:42:37 -0000 > > Maybe we can divide the problem into two sub-problems * information > > requires by hotspots * > > Maybe yes the problem may be divided into info required by the > hotspots and hotspot readiness to accept automation. Is this what you meant? Yes, In other word, mechanism to handle these steps for hotspots. (sorry that I missed the second sub-problem..) > And yes, the information a laptop sends to a hotspot in order to > obtain Internet connectivity is often very different depending on > which hotspot the laptop connects to. agree > > 1- we probably need to have a resource server where keeps > > information about all users who want to use such service (the > > information that usually are taken by hotspots) > > Well yes, that is a possibility. It has the advantage of ability to > better control everything, perhaps by using a single 'super' identifier. > > But the requirements for solutions could also include mechanisms that > do not require a central server. Agree. > There could be requirements for: solutions involving a 'super' server, > solutions not involving any additional server, solutions requiring > modifications of the hotspot Controllers, solutions _not_ requiring so. Agree > > I think in addition to OpenID there are also SkypeIDs, and maybe others? Yes true. I guess for secauth, we only need a unique credential. It can be hash of something like HIT or any other values. > I think that Mobile IPv6 normal working is hampered by the lack of > automated connectivity to wifi hotspots. Mobile IPv6 is designed and > implemented to work standalone - much effort went into automated > handover management: when in controlled WiFi environments the MIP > implementations hand over very smoothly. agree > But when connecting to real-world hotspots the entire magnificence of > Mobile IPv6 smooth handoverrs is lost because of this need of user > intervention to the capturing web portals. True > Were this automated hotspot security connection be in place then > Mobile IP would work better. > agree. If I summarize our discussion: - A use case for secauth : To assist mobile node (end user) to move from one hotspot to another one without having interruption in its service. - The scope of secauth: automatic registration of mobile node to new hotspot (protocols to send authentication information when this mobile node changes its location) In detail: * Detection of changing location (we might be able to use the same mechanism used for MIP for this detection) * Secure exchange of authentication information * Authentication of hotspot to controller for one of the following solution scope: - Accessing centralized/one of distributed resource server/s for user information - Modifying hotspot controller (e.g. open a port on firewall, etc.) This access should be very limited and monitored - Exchange of user information without the need of resource server - Accessing services without the need for running any rules on hotspot controller. Anything missed? Thanks Best, Hosnieh From nobody Tue Nov 4 13:47:07 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9DC91A0149 for ; Tue, 4 Nov 2014 13:47:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qf3PygudPs39 for ; Tue, 4 Nov 2014 13:47:01 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85AF51A0147 for ; Tue, 4 Nov 2014 13:47:01 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 68CA120098; Tue, 4 Nov 2014 16:48:40 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 2AA71637F4; Tue, 4 Nov 2014 16:47:00 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 1208C63740; Tue, 4 Nov 2014 16:47:00 -0500 (EST) From: Michael Richardson To: Hosnieh Rafiee In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A7A4FCB3@lhreml513-mbb.china.huawei.com> References: <814D0BFB77D95844A01CA29B44CBF8A7A4F071@lhreml513-mbb.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A4F517@lhreml513-mbb.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A4FCB3@lhreml513-mbb.china.huawei.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/7BvbF6GBnCMcJ1v4C8Z1R2wmubM Cc: "secauth@ietf.org" Subject: Re: [Secauth] Summary of telco meeting on 3 Nov. X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 21:47:04 -0000 --=-=-= Hosnieh Rafiee wrote: > User 1 enters gives its information to hotspot A so that it can use > internet (or some services). User 1 moves to location B where hotspot B > exists. He disconnected from the service and again needs to give its > information to hotspot B so that it can continue using Internet (or > other services). User 1 needs a mechanisms that his information > automatically submitted to the new hotspot as soon as this user moves > to new location and his computer registers it. This is like hand over > in mobile networks but now we are talking about WAN or different public > networks (possibly from different ISPs). > There is a need for a mechanism to submit the user's information from > hotspot A to hotspot B so that hotspot B can authenticate this user and > let this user continue using its service (internet). This process > should be all automatic except the first time user gives its > information to the first hotspot. (hotspot should be considered as > logical devices in virtualized environment) This completely sounds like moonshot and ABFAB. This kind of mechanism that you describe occurs regularly in the eduroam community: https://www.eduroam.org/ eduroam allows students, researchers and staff from participating institutions to obtain Internet connectivity across campus and when visiting other participating institutions by simply opening their laptop. http://datatracker.ietf.org/doc/draft-ietf-abfab-usecases/ section 3.7. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVFlJUICLcPvd0N1lAQK4MAf9Gn56xrHxRBV64RyCPK5fItTvt4QT2ZMI 5+dLT4ElbjGZ9yHIlwxOcV7JzRKOlOGIf2WRmSy1qFmUhTq2a/OpoCDz7Xn7mEV/ W5tEATldryPyntrXbGC6VB688R0SZn+ZPuSmPH2HYw3AKhI4cmEqgQ5uewgTn1Gp jGfYpdBU4/d9skZSRvUd5m0S+h8BbKtWS5+gdcC0LtgjNlu5K/VfmlZ6HvQRWM79 Tsn6h01nkIasxQqL0T+j9JfmBPzaTp1cf2u3FvOE7dwNyFC7/x+vOpqvT8sYm9R0 2w6zxLBAGbqOJiHWJpjF/tpflLjRS3qpNOc9Wd/8T5Ow3Buq1TC6Uw== =WQ4Q -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 5 01:44:57 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBBE71A8845 for ; Wed, 5 Nov 2014 01:44:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bsa_rGjShdh for ; Wed, 5 Nov 2014 01:44:54 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D6141A8842 for ; Wed, 5 Nov 2014 01:44:53 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLH67538; Wed, 05 Nov 2014 09:44:52 +0000 (GMT) Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml406-hub.china.huawei.com ([10.201.5.243]) with mapi id 14.03.0158.001; Wed, 5 Nov 2014 09:44:47 +0000 From: Hosnieh Rafiee To: Michael Richardson Thread-Topic: [Secauth] Summary of telco meeting on 3 Nov. Thread-Index: AQHP+B6W4pMmZUz1jU+yjtBZAebSB5xRAXwAgACzRAA= Date: Wed, 5 Nov 2014 09:44:46 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A5016F@lhreml513-mbb.china.huawei.com> References: <814D0BFB77D95844A01CA29B44CBF8A7A4F071@lhreml513-mbb.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A4F517@lhreml513-mbb.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A4FCB3@lhreml513-mbb.china.huawei.com> <19817.1415137620@sandelman.ca> In-Reply-To: <19817.1415137620@sandelman.ca> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/qoc_GFenA3VCeY1lKzT8831zdNY Cc: "secauth@ietf.org" Subject: Re: [Secauth] Summary of telco meeting on 3 Nov. X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 09:44:56 -0000 Hi Michael, Thanks a lot for your message and informing us about the conflict scope of = secauth with other WG(s). >=20 > This completely sounds like moonshot and ABFAB. >=20 > This kind of mechanism that you describe occurs regularly in the > eduroam > community: https://www.eduroam.org/ > eduroam allows students, researchers and staff from participating > institutions to obtain Internet connectivity across campus and when > visiting > other participating institutions by simply opening their laptop. >=20 >=20 > http://datatracker.ietf.org/doc/draft-ietf-abfab-usecases/ section 3.7. I checked this use case. I think the main difference of secauth with abfab = is that 1- They focused on cloud based infrastructure but not about SDN/NFV related= infrastructure and handling the complexity of authentication and authoriza= tion in such infrastructure.=20 There might be requirement to run any rules on switches or so to support th= is scope. But abfab is only about application based communication and not l= ower layer while secauth also cares about handling authorization in Vswitch= es and Vrouters in SDN based infrastructure. 2- Their scope is organizational domains. In other word, their assumption i= s that a user wants to use services from a wifi that he/she already have an= y other services from the same provider. In other word, they did not cover = all the scope of eduroam.=20 I actually didn't aware of eduroam or moonshot projects. I think those proj= ects are is general and can be used by any place that installed and suppo= rt it. Eduroam can be what I discussed in my last message =20 eduroam covers the following: - Accessing centralized/one of distributed resource server/s for user Information But not:=20 - Modifying hotspot controller (e.g. open a port on firewall, etc.) This access should be very limited and monitored - Exchange of user information without the need of resource server - Accessing services without the need for running any rules on hotspot controller. During my telco discussion I provided a general gap analysis however, I gue= ss we need more explanation of current work items. I am in the process of= preparing a brief gap analysis @Folks: Any volunteers to help me for this gap analysis to provide it fast= er?=20 This is the current list of groups for access control abfab, ace, httpauth, kitten, oauth, softwire This is the list of current WG for SDN/NFV i2rs, nvo3, spring RGs: sdnrg, cfrg, nwcrg, nfvrg Non-WG SUPA, I2NSF Any thoughts? Thanks, Best, Hosnieh From nobody Wed Nov 5 03:31:07 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC7271A885F for ; Wed, 5 Nov 2014 03:31:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.895 X-Spam-Level: X-Spam-Status: No, score=-2.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hlMfvDJdZNQ for ; Wed, 5 Nov 2014 03:31:00 -0800 (PST) Received: from xenon21.um.es (xenon21.um.es [155.54.212.161]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5861A8874 for ; Wed, 5 Nov 2014 03:31:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon21.um.es (Postfix) with ESMTP id E625B3FC2F for ; Wed, 5 Nov 2014 12:30:58 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon21.um.es Received: from xenon21.um.es ([127.0.0.1]) by localhost (xenon21.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nSNnpfa8uujs for ; Wed, 5 Nov 2014 12:30:58 +0100 (CET) Received: from eduroam_um-7-145.inf.um.es (eduroam_um-7-145.inf.um.es [155.54.7.145]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: gabilm) by xenon21.um.es (Postfix) with ESMTPSA id CB81B3FBE5 for ; Wed, 5 Nov 2014 12:30:55 +0100 (CET) Message-ID: <545A0A6F.4000201@um.es> Date: Wed, 05 Nov 2014 12:30:55 +0100 From: =?ISO-8859-1?Q?Gabriel_L=F3pez?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: secauth@ietf.org References: <814D0BFB77D95844A01CA29B44CBF8A7A4F071@lhreml513-mbb.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A4F517@lhreml513-mbb.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A4FCB3@lhreml513-mbb.china.huawei.com> <19817.1415137620@sandelman.ca> <814D0BFB77D95844A01CA29B44CBF8A7A5016F@lhreml513-mbb.china.huawei.com> In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A7A5016F@lhreml513-mbb.china.huawei.com> OpenPGP: id=8D119153 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tV168v1e9q3EdCLo4invM65eRsUhsiW5U" Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/xO73sUH59Y4vbCczd2Ate_dgjW8 Subject: Re: [Secauth] Summary of telco meeting on 3 Nov. X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 11:31:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tV168v1e9q3EdCLo4invM65eRsUhsiW5U Content-Type: multipart/mixed; boundary="------------060602050002040402040308" This is a multi-part message in MIME format. --------------060602050002040402040308 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Hosneih, Just a minor, but important, point. El 05/11/14 10:44, Hosnieh Rafiee escribi=F3: > Hi Michael, > > Thanks a lot for your message and informing us about the conflict scope= of secauth with other WG(s). > >> This completely sounds like moonshot and ABFAB. >> >> This kind of mechanism that you describe occurs regularly in the >> eduroam >> community: https://www.eduroam.org/ >> eduroam allows students, researchers and staff from participating >> institutions to obtain Internet connectivity across campus and whe= n >> visiting >> other participating institutions by simply opening their laptop. >> >> >> http://datatracker.ietf.org/doc/draft-ietf-abfab-usecases/ section 3.7= =2E > I checked this use case. I think the main difference of secauth with ab= fab is that > 1- They focused on cloud based infrastructure=20 Application services (Non-web) in general, cloud is one of the use cases Regards, Gabi. > but not about SDN/NFV related infrastructure and handling the complexit= y of authentication and authorization in such infrastructure.=20 > > There might be requirement to run any rules on switches or so to suppor= t this scope. But abfab is only about application based communication and= not lower layer while secauth also cares about handling authorization in= Vswitches and Vrouters in SDN based infrastructure. > > 2- Their scope is organizational domains. In other word, their assumpti= on is that a user wants to use services from a wifi that he/she already h= ave any other services from the same provider. In other word, they did no= t cover all the scope of eduroam.=20 > I actually didn't aware of eduroam or moonshot projects. I think those = projects are is general and can be used by any place that installed and= support it. Eduroam can be what I discussed in my last message > > =20 > > eduroam covers the following: > - Accessing centralized/one of distributed resource server/s for user > Information > But not:=20 > - Modifying hotspot controller (e.g. open a port on firewall, etc.) Thi= s > access should be very limited and monitored > - Exchange of user information without the need of resource server > - Accessing services without the need for running any rules on hotspot > controller. > > During my telco discussion I provided a general gap analysis however, I= guess we need more explanation of current work items. I am in the proc= ess of preparing a brief gap analysis > > > @Folks: Any volunteers to help me for this gap analysis to provide it = faster?=20 > This is the current list of groups for access control > abfab, ace, httpauth, kitten, oauth, softwire > > This is the list of current WG for SDN/NFV > i2rs, nvo3, spring > > RGs: > sdnrg, cfrg, nwcrg, nfvrg > > Non-WG > SUPA, I2NSF > > Any thoughts? > > Thanks, > Best, > Hosnieh > > _______________________________________________ > Secauth mailing list > Secauth@ietf.org > https://www.ietf.org/mailman/listinfo/secauth --=20 -------------------------------------------------------------- Gabriel L=F3pez Mill=E1n Departamento de Ingenier=EDa de la Informaci=F3n y las Comunicaciones University of Murcia Spain Tel: +34 868888504 Fax: +34 868884151 email: gabilm@um.es --------------060602050002040402040308 Content-Type: application/pgp-keys; name="0x8D119153.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8D119153.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.9 (Darwin) Comment: GPGTools - http://gpgtools.org mQENBE2eyEgBCADqNVu4SRFBENGp+qgXlziaoIQsCfZGQvh7MyWY1cZRI6PTUUGC 7FSYbFkOhQCGZ+/ARAc8zNoIVuywWBN/rtB1pHVXwqd1xDIDfoTIkE6nXc54hCvo umv4oI4XsqHpLzlmJYJCfcB17RV6HmcgxZY3d+z+Oy7cegt5NHW0a2f2JeTcmfsG B0yqI/oThsvwJ3+8Ys54q4JD8BNulHDYA18rPAqBSm3T0S+E01GF55pGLriEUrbA gKNxmPzIyYkgMUKqtSAALn/TXBkQECIiB+yr1pz7nnM9R457KYO8rmQl45rAw71+ SXvHIf1PCM0TNtBEw7ZR9cZzYrJl6PB3w0uPABEBAAG0I0p1YW4gc2luIG1pZWRv IDxqdWFuc2lubWllZG9AdW0uZXM+iQE+BBMBAgAoBQJQtLmZAhsvBQkSz/eABgsJ CAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRDFGKqEjRGRU1cIB/9x8aaGHHrPAebJ rWDJq6ojFayTN5DgDMkhUJUqmgSx1aNrHHk48YMJI/6CNZGnxMPXpuOxfU48H6Ks whCzo5l0Wp+c1L0gdnPmr3Sn5KZbOV6v4yUi64fIYXMnyHeIHCroGaRlsgY4H3C9 vncxMS+VbWPSC07D79ewiUlnzHux+b/cgww0TiKL+KhhRmTZcUcAqYvjKn/j9ZDZ nsu4q8k58q+WaZc4i3sgKPMDVEGCH6/9ZS2bdHqG0gTeetGGCcZo+lMwPuwW1JoL S/kc24WWGOM8C8I1hCZ1MI3+2YblIS3aD0SKf+YlJoZienMhSYQrS1mf5IQHT9f+ PnwpNF5ZiQEcBBMBAgAGBQJUO7U8AAoJEMlz8at1W7biDCcH/RBmC3KCb9BbOcgQ dEumixClH0AXcyQwtMFqQKtk4uZ1+55xQrL12yLaZJRn94+hBdwGwyhHds5XPDQ1 4CRRjVYhMWE7x+CVcsX4fA7YPs4S/UGfLt1HeCrprgnHBgNC+OmNU5l+nbWAoLTo ACXNSsZ3S+66l4UPL6lcQHnNTWbRf9GOIwV+/V2gPgLODmj+b0760aXEZuCfjMVQ Arfkec1U+OZLkwzqeSuy/pW8FQdJfOxh3Bn1Q9KOHQhrW96oNTxcZk/gOtgCQr2R LMQYzqr3hCAsQpMyIiYNnJU0GNwnZNoe1l7Nr5pKZRPGUOPkut6VxsMhpJVA4lmq HvWBmpW0KEdhYnJpZWwgTG9wZXogKENsYXZlIFBHUCkgPGdhYmlsbUB1bS5lcz6J AUEEEwECACsCGy8FCRLP94AGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJQtLmd AhkBAAoJEMUYqoSNEZFTpTMH/ju+yfYTrCWk6fLMIlEh8Kb6jyMQidpa409RJ8eh F0b9t0mdSe/hRooJAsoNbFvXqO2ngPzwd1jFFgtQO8rn7CmLgpjLjCo8TuPyPL1r /C2+v26NRsgN7iJ+3KXsxJOjBTrTOidF9XQc0xks0gtNpfjpB2bckC87CVxszgOD mclNMsRq0UtGfiUrNeC+z5wosYXwAskTS3H5fimXXlO8akUM+YID2bDUZZjqVoNx 2B2VSCnMT3JY9+tGOqgFx+5b6yorM9PacCPpg9TM6sH43rzZnG3ixbdVhrJIWip9 xfIkAer09MCf+ixfp0gfJ9FiUCD//j44y4CniwLLvFEmpfOJARwEEwECAAYFAlQ7 tTwACgkQyXPxq3VbtuL9WQf9Gs6tIYCQ0xh4glPFuTw6cK2LXrhg9JQTLqSPWtwW Y3h42QI8sWtT64OCHDoLtiHJzkZ/3HmAD3rLKLU8FM/mIqzYFMMG2qH9n93I82Zh Ful7CEbBqAwJvvvGgnSiG8MNEVTSDdhxz6HHeB+2qFvJZA18fjCTUMQBwuDXdqic dg6ORo/aFmo0yWvVlz13hE3+AhEfdy+1gosK7XuzsOUmYljX4mIvUpX3TSKI8Wbz CH06vNxImj4QqGLwF5O2K6bnV90Wbly9OKFkxXqlSZvmdaxsa1iVlXBBSFCHk6Ln ciPzPfhe8p2BraQqE70Zaa1eI6TQWenxZFWeq+cc2JDnDLkBDQRNpqglAQgA0i6O YF2wZEv3a7QH95xFTmlcuenJq7j35Yv3mYRGU+byjXVvubda1FGvMAk04qr9Moix 8JJ1NGXkIZCuuYsUG+jY6hJwtQjnxOTQUwPoamp6FAUk/3SLVjwdn54YNehJr9Y0 lsXtfSu44Mhsdgo+epdG/03t7sUYcl56ppRfV9ls/p7W7wz8+zrUmg4jG9YWsHVy xsVhNAHT5mRLxRwF8BFEHyM1vouzk3TyQqOXoiAvjrGU2wTbNqc7JerOf9svtf4J 8bcReRKegVZO+LSiQAX0PJ7a8xmPO7ka3aGfwbWBnrfIxWUFBHrFI+KzaI149CHG 6Zd96GAd1SW4o9Y8cQARAQABiQElBBgBAgAPBQJNpqglAhsMBQkSz/eAAAoJEMUY qoSNEZFTmoAIAOd09CcEmrTmNotgqhjyRmc7POaB4wUxaxAyfgMXNSYbBGfGD3m4 zDjx6eTp/wYHqAck3z5wNw1PSfc+LcKt516SXhi3AdvqxjwjORzwHd2oW8I/0t8S ek9RFEQnSDaB2iWyoPB7tNfEuVZEju+kfJ/HRSzzGNBHeTCatUnckiUkMo7aDiXu QQoE3B2W6QQzVxiKiLPq/FG5CwnAeIogEtpdwLmjB4odMD5OUf4wza0M3wiq/KYX TT1zP/a6/JnZjJUAYfPgJ5RnGcl22i5pPmjUcfBNqJUVWtIpZ59CWV7G1rGn48Ea /+1Dm+guixyuXLUxyzDlLYLwbPmLx0zN+ss=3D =3DebMe -----END PGP PUBLIC KEY BLOCK----- --------------060602050002040402040308-- --tV168v1e9q3EdCLo4invM65eRsUhsiW5U Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJUWgpvAAoJEMUYqoSNEZFTjq8H/3UnAz4LQ9Pt41mWQ4zLozTg JURKZIDs1Vl965Tp4ptN1IkIYtTfhYA2wgzJYaqk87xkNYKoqVEh3IoN08mjkSUp oEMXiuThfbve467OFenQ/6G9BPCgxQDZwxqW50xFD6qW0MB6zODS2W7xDnGrWo1x o3RdtSdMU6O42gFGTngEB9jt37h9/ST8tFOuBmG8xKcfEA4VJ+p5uzUZ6JO632KG VmD1yq4+omuQuDYug60rBV7BezFLbBChCEcjej271DeUPvF9Db98wMNYe6l6BvAp Dzo70J9yzGoa+niTaEG0znxbGrS9EF1NR64UP4lNzHAeiwnupL8cckiHSsm6uwk= =JBGi -----END PGP SIGNATURE----- --tV168v1e9q3EdCLo4invM65eRsUhsiW5U-- From nobody Wed Nov 5 07:12:48 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 765541A889F for ; Wed, 5 Nov 2014 07:12:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oCmOrrrkGsir for ; Wed, 5 Nov 2014 07:12:45 -0800 (PST) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 793EB1A1B36 for ; Wed, 5 Nov 2014 07:12:45 -0800 (PST) Received: from 172.18.9.243 (EHLO lhreml402-hub.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CHR78785; Wed, 05 Nov 2014 09:12:41 -0600 (CST) Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml402-hub.china.huawei.com ([10.201.5.241]) with mapi id 14.03.0158.001; Wed, 5 Nov 2014 15:12:38 +0000 From: Hosnieh Rafiee To: =?iso-8859-1?Q?Gabriel_L=F3pez?= Thread-Topic: [Secauth] Summary of telco meeting on 3 Nov. Thread-Index: AQHP+B6W4pMmZUz1jU+yjtBZAebSB5xRAXwAgACzRACAADLvgIAAOt+Q Date: Wed, 5 Nov 2014 15:12:38 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A5025F@lhreml513-mbb.china.huawei.com> References: <814D0BFB77D95844A01CA29B44CBF8A7A4F071@lhreml513-mbb.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A4F517@lhreml513-mbb.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A4FCB3@lhreml513-mbb.china.huawei.com> <19817.1415137620@sandelman.ca> <814D0BFB77D95844A01CA29B44CBF8A7A5016F@lhreml513-mbb.china.huawei.com> <545A0A6F.4000201@um.es> In-Reply-To: <545A0A6F.4000201@um.es> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.100] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/Em4Qpxu3VT_j0nBeTiCIL5qt1VY Cc: "secauth@ietf.org" Subject: Re: [Secauth] Summary of telco meeting on 3 Nov. X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 15:12:46 -0000 Hi Gabriel, Thanks for clarification :-).=20 @folks: Anything else that I missed? Best, Hosnieh From nobody Wed Nov 5 07:15:43 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 987BA1A88FC for ; Wed, 5 Nov 2014 07:15:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0xZyzOhlrP0 for ; Wed, 5 Nov 2014 07:15:40 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0417E1A889F for ; Wed, 5 Nov 2014 07:15:40 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 8BECE2002A; Wed, 5 Nov 2014 10:17:21 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id C665D637F4; Wed, 5 Nov 2014 10:15:38 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id ADF5F637F2; Wed, 5 Nov 2014 10:15:38 -0500 (EST) From: Michael Richardson To: Hosnieh Rafiee In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A7A5016F@lhreml513-mbb.china.huawei.com> References: <814D0BFB77D95844A01CA29B44CBF8A7A4F071@lhreml513-mbb.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A4F517@lhreml513-mbb.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A4FCB3@lhreml513-mbb.china.huawei.com> <19817.1415137620@sandelman.ca> <814D0BFB77D95844A01CA29B44CBF8A7A5016F@lhreml513-mbb.china.huawei.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/lXLBAcA85_ZOb0Uk6SgO-90SYyA Cc: "secauth@ietf.org" Subject: Re: [Secauth] Summary of telco meeting on 3 Nov. X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 15:15:41 -0000 --=-=-= Hosnieh Rafiee wrote: >> This completely sounds like moonshot and ABFAB. >> >> This kind of mechanism that you describe occurs regularly in the >> eduroam >> community: https://www.eduroam.org/ >> eduroam allows students, researchers and staff from participating >> institutions to obtain Internet connectivity across campus and when >> visiting >> other participating institutions by simply opening their laptop. >> >> >> http://datatracker.ietf.org/doc/draft-ietf-abfab-usecases/ section 3.7. > I checked this use case. I think the main difference of secauth with abfab is that > 1- They focused on cloud based infrastructure but not about SDN/NFV > related infrastructure and handling the complexity of authentication > and authorization in such infrastructure. Not the case, their goal is to extend credentials that people have, which are sometimes used for web things, to things beyond web. > There might be requirement to run any rules on switches or so to > support this scope. But abfab is only about application based > communication and not lower layer while secauth also cares about > handling authorization in Vswitches and Vrouters in SDN based > infrastructure. Not true at all, the original set of credentials are network access credentials. ABFAB is eduroam+++. > 2- Their scope is organizational domains. In other word, their > assumption is that a user wants to use services from a wifi that he/she > already have any other services from the same provider. In other word, > they did not cover all the scope of eduroam. Not the case at all. > I actually didn't aware of eduroam or moonshot projects. I think those > projects are is general and can be used by any place that installed > and support it. Eduroam can be what I discussed in my last message this is existing deployed, running code that does exactly what you talked about in your message. > eduroam covers the following: > - Accessing centralized/one of distributed resource server/s for user > Information > But not: > - Modifying hotspot controller (e.g. open a port on firewall, etc.) This > access should be very limited and monitored Huh? How was that part of your message. Now you are getting into i2nsf or something.... does the user get to open ports, or does the network controller, based upon the authorization of the user, do it for them? > - Exchange of user information without the need of resource server Not even sure what this means. > - Accessing services without the need for running any rules on hotspot > controller. what's a "hotspot controller"? Please use 802.1X terms for me... since they spent the effort to make all those terms up. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVFo/F4CLcPvd0N1lAQKZIAf7BGVJ+G5QEcqah0gqgKcDuhXMD+OZASCa 1henWnaL+6Nrrd+Gk6oBTxY1Q2qUifswiz21cjtZ3MJke5Lr8M1XTlIueVJBck1D MBSJ015JxncK2uZP8cNGjn5SEYP0q1eCwa/Fx9TTDBrxst9VXPdCFw0vMb9XQDDc Pw7Qi1ttMaUmNayLII8+q6n2+VRXvnkCFo/Y0UNWp/VrOJHJEwcZua4UHgI10o4y r73zdnHo08Ug9rnT2HbF40A8IuuiBo6uiwv+DaD94x3BWa8QMKAIlS9v1+7Inkkm FFfeoiOiwMea51NQihR8iC8nFzBxvm1WVFHDxAvlX/QBSOPE6keyHA== =KwF4 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 5 07:29:50 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A62401A8947 for ; Wed, 5 Nov 2014 07:29:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.195 X-Spam-Level: X-Spam-Status: No, score=-3.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvjqTXupCf1v for ; Wed, 5 Nov 2014 07:29:47 -0800 (PST) Received: from xenon21.um.es (xenon21.um.es [155.54.212.161]) by ietfa.amsl.com (Postfix) with ESMTP id D33151A894B for ; Wed, 5 Nov 2014 07:29:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon21.um.es (Postfix) with ESMTP id 016903FC33; Wed, 5 Nov 2014 16:29:44 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon21.um.es Received: from xenon21.um.es ([127.0.0.1]) by localhost (xenon21.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id TI4jOmC5rS97; Wed, 5 Nov 2014 16:29:43 +0100 (CET) Received: from inf-205-227.inf.um.es (inf-205-227.inf.um.es [155.54.205.227]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon21.um.es (Postfix) with ESMTPSA id A65413FC2F; Wed, 5 Nov 2014 16:29:39 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Rafa Marin Lopez In-Reply-To: <8158.1415200538@sandelman.ca> Date: Wed, 5 Nov 2014 16:29:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5548CDAC-D6BB-43C3-A579-DF3BB1C97029@um.es> References: <814D0BFB77D95844A01CA29B44CBF8A7A4F071@lhreml513-mbb.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A4F517@lhreml513-mbb.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A4FCB3@lhreml513-mbb.china.huawei.com> <19817.1415137620@sandelman.ca> <814D0BFB77D95844A01CA29B44CBF8A7A5016F@lhreml513-mbb.china.huawei.com> <8158.1415200538@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/7_lh6SV0lWzTT7AnOMJN8M8tBl4 Cc: Hosnieh Rafiee , "secauth@ietf.org" Subject: Re: [Secauth] Summary of telco meeting on 3 Nov. X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 15:29:49 -0000 Hi Michael: El 05/11/2014, a las 16:15, Michael Richardson = escribi=F3: >=20 > Hosnieh Rafiee wrote: >>> This completely sounds like moonshot and ABFAB. >>>=20 >>> This kind of mechanism that you describe occurs regularly in the >>> eduroam >>> community: https://www.eduroam.org/ >>> eduroam allows students, researchers and staff from participating >>> institutions to obtain Internet connectivity across campus and when >>> visiting >>> other participating institutions by simply opening their laptop. >>>=20 >>>=20 >>> http://datatracker.ietf.org/doc/draft-ietf-abfab-usecases/ section = 3.7. >=20 >> I checked this use case. I think the main difference of secauth with = abfab is that >=20 >> 1- They focused on cloud based infrastructure but not about SDN/NFV >> related infrastructure and handling the complexity of authentication >> and authorization in such infrastructure. >=20 > Not the case, their goal is to extend credentials that people have, = which are > sometimes used for web things, to things beyond web. >=20 >> There might be requirement to run any rules on switches or so to >> support this scope. But abfab is only about application based >> communication and not lower layer while secauth also cares about >> handling authorization in Vswitches and Vrouters in SDN based >> infrastructure. >=20 > Not true at all, the original set of credentials are network access > credentials. ABFAB is eduroam+++. [Rafa] Michael I don't think this sentence is accurate. ABFAB is not = eduroam+++. The scope of ABFAB is clear "This working group will specify a federated identity mechanism for use by other Internet protocols not based on = HTML/HTTP, such as for instance IMAP, XMPP, SSH and NFS." In general, credentials may differ from the network access ones. If = there is a case where credentials are the same to those used for network = access is ok but it is not mandatory. The thing is, since ABFAB uses EAP = and AAA and eduroam also uses EAP and AAA for network access, then ABFAB = may use the eduroam infrastructure and associated technologies for = authenticating and authorizing application services as well.=20 Best Regards. >=20 >> 2- Their scope is organizational domains. In other word, their >> assumption is that a user wants to use services from a wifi that = he/she >> already have any other services from the same provider. In other = word, >> they did not cover all the scope of eduroam. >=20 > Not the case at all. >=20 >> I actually didn't aware of eduroam or moonshot projects. I think = those >> projects are is general and can be used by any place that installed >> and support it. Eduroam can be what I discussed in my last message >=20 > this is existing deployed, running code that does exactly what you = talked > about in your message. >=20 >> eduroam covers the following: >> - Accessing centralized/one of distributed resource server/s for user >> Information >=20 >> But not: >> - Modifying hotspot controller (e.g. open a port on firewall, etc.) = This >> access should be very limited and monitored >=20 > Huh? How was that part of your message. > Now you are getting into i2nsf or something.... does the user get to = open > ports, or does the network controller, based upon the authorization of = the > user, do it for them? >=20 >> - Exchange of user information without the need of resource server >=20 > Not even sure what this means. >=20 >> - Accessing services without the need for running any rules on = hotspot >> controller. >=20 > what's a "hotspot controller"? > Please use 802.1X terms for me... since they spent the effort to make = all > those terms up. >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > _______________________________________________ > Secauth mailing list > Secauth@ietf.org > https://www.ietf.org/mailman/listinfo/secauth ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From nobody Wed Nov 5 09:34:13 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 151221A8AE3 for ; Wed, 5 Nov 2014 09:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOJrT00okwZw for ; Wed, 5 Nov 2014 09:34:09 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86E9B1A8AE7 for ; Wed, 5 Nov 2014 09:34:08 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id sA5HY59N014200 for ; Wed, 5 Nov 2014 18:34:05 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8AE942031DE for ; Wed, 5 Nov 2014 18:34:13 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 838B32031BA for ; Wed, 5 Nov 2014 18:34:13 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id sA5HXxWX012526 for ; Wed, 5 Nov 2014 18:34:05 +0100 Message-ID: <545A5F88.8030102@gmail.com> Date: Wed, 05 Nov 2014 18:34:00 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: secauth@ietf.org References: <814D0BFB77D95844A01CA29B44CBF8A7A4F071@lhreml513-mbb.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A4F517@lhreml513-mbb.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A4FCB3@lhreml513-mbb.china.huawei.com> <19817.1415137620@sandelman.ca> In-Reply-To: <19817.1415137620@sandelman.ca> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/Vx0DNkBUcAWZ9vZA5Er4VteBs9E Subject: Re: [Secauth] eduroam X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 17:34:11 -0000 Le 04/11/2014 22:47, Michael Richardson a écrit : > > Hosnieh Rafiee wrote: > > User 1 enters gives its information to hotspot A so that it can use > > internet (or some services). User 1 moves to location B where hotspot B > > exists. He disconnected from the service and again needs to give its > > information to hotspot B so that it can continue using Internet (or > > other services). User 1 needs a mechanisms that his information > > automatically submitted to the new hotspot as soon as this user moves > > to new location and his computer registers it. This is like hand over > > in mobile networks but now we are talking about WAN or different public > > networks (possibly from different ISPs). > > > There is a need for a mechanism to submit the user's information from > > hotspot A to hotspot B so that hotspot B can authenticate this user and > > let this user continue using its service (internet). This process > > should be all automatic except the first time user gives its > > information to the first hotspot. (hotspot should be considered as > > logical devices in virtualized environment) > > This completely sounds like moonshot and ABFAB. > > This kind of mechanism that you describe occurs regularly in the eduroam > community: https://www.eduroam.org/ > eduroam allows students, researchers and staff from participating > institutions to obtain Internet connectivity across campus and when visiting > other participating institutions by simply opening their laptop. Well, eduroam is a great achievement. I am not an user, but the firsthand users I hear is very positive. On another hand, eduroam is just another operator of hotspots, as well as operating other bigger networks of course. As such, one could realize smooth handovers between that operator's hotspots but not outside of it. The seeked functionality would be one offering ability to roam between an eduroam Access Point and an e.g. orange Access Point, without having to fill in forms on a web page at each handover. A keyboard-less client connecting to a webforms-mandatory hotspot authentication. Something like that. Alex > > > http://datatracker.ietf.org/doc/draft-ietf-abfab-usecases/ section 3.7. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > > _______________________________________________ > Secauth mailing list > Secauth@ietf.org > https://www.ietf.org/mailman/listinfo/secauth > From nobody Thu Nov 6 00:32:28 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 133AD1A1A9B for ; Thu, 6 Nov 2014 00:32:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d49qXGnTfF9a for ; Thu, 6 Nov 2014 00:32:25 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 547041A1A85 for ; Thu, 6 Nov 2014 00:32:21 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOL63671; Thu, 06 Nov 2014 08:32:20 +0000 (GMT) Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml403-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Thu, 6 Nov 2014 08:32:10 +0000 From: Hosnieh Rafiee To: "secauth@ietf.org" Thread-Topic: Date and time of bar meeting Thread-Index: Ac/5nCd54F61B9ZqTJ2dXizwUN9Kug== Date: Thu, 6 Nov 2014 08:32:09 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A5054C@lhreml513-mbb.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/dFgZvBfUowL6T7pSRxvuiAssfjo Cc: Linda Dunbar , "Liushucheng \(Will\)" , Ralph Droms Subject: [Secauth] Date and time of bar meeting X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 08:32:27 -0000 All, We plan to organize a bar meeting at upcoming IETF. Will has graciously agr= eed to organize this meeting in Honolulu. We plan to get support from IETF = secretaries for remote participants but if this does not happen then our on= ly option is to use one computer to hear remote participants. I hope that w= e can get this support. Date and time: Thursday 13 November 2014 at 7 PM - 9 PM HST (6 AM - 8 AM B= erlin time). Where? I will announce it to you later Since we need to know the list of participants beforehand so that we can pl= an for the place, please check your availability on doodle and indicate whe= ther you will be remote or onsite. < http://doodle.com/83y95p8aby7tw6s5 > The agenda for this bar meeting: - presentation of gap analysis - Discussion about proposed charter and its use cases and agree on the exac= t scope of proposed charter=20 - Discussion about next steps - Your contribution to this work (Discussion about general solutions) - Any other theme that comes up I would ask you please review the secauth requirement and use case document= and the previous discussions about the proposed charter so that we can hav= e a fruitful discussion. Thank you again, Have a safe trip to Honolulu! Best, Hosnieh From nobody Thu Nov 6 02:19:43 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2BC91A1AC8 for ; Thu, 6 Nov 2014 02:19:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IvshvbHoR8Qa for ; Thu, 6 Nov 2014 02:19:40 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9D921A1AB5 for ; Thu, 6 Nov 2014 02:19:39 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOL77099; Thu, 06 Nov 2014 10:19:38 +0000 (GMT) Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml405-hub.china.huawei.com ([10.201.5.242]) with mapi id 14.03.0158.001; Thu, 6 Nov 2014 10:19:27 +0000 From: Hosnieh Rafiee To: Michael Richardson Thread-Topic: [Secauth] Summary of telco meeting on 3 Nov. Thread-Index: AQHP+B6W4pMmZUz1jU+yjtBZAebSB5xRAXwAgACzRACAAHG4AIABLgwg Date: Thu, 6 Nov 2014 10:19:26 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A505D4@lhreml513-mbb.china.huawei.com> References: <814D0BFB77D95844A01CA29B44CBF8A7A4F071@lhreml513-mbb.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A4F517@lhreml513-mbb.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A4FCB3@lhreml513-mbb.china.huawei.com> <19817.1415137620@sandelman.ca> <814D0BFB77D95844A01CA29B44CBF8A7A5016F@lhreml513-mbb.china.huawei.com> <8158.1415200538@sandelman.ca> In-Reply-To: <8158.1415200538@sandelman.ca> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/nE0P4B8rbkgx__kxzopK5jotpD8 Cc: "secauth@ietf.org" , Linda Dunbar Subject: Re: [Secauth] Summary of telco meeting on 3 Nov. X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 10:19:42 -0000 Hi Michael, I think Rafa already answered some of your concerned that you raised in thi= s group. > Huh? How was that part of your message. It was my previous message to the list. I guess I included the link here.=20 > Now you are getting into i2nsf or something.... does the user get to > open ports, or does the network controller, based upon the > authorization of the user, do it for them? I2nsf scope is NFV and the protocols needed for the customers to request se= curity services from different service providers. For example you want to r= equest a firewall to include it to your network. In other word, you accepte= d to be a customer of this service provider and you want to request a servi= ce from them.=20 - secauth considers mobility (the scope is interdomain authentication and a= uthorization during this mobility) =20 - secauth only needs to modify a rule to fulfill customer's request but it = is not interested to let the customers to request a new security function.= =20 - secauth focused on SDN cases and might also cover only a few communicatio= ns with security services in the network just to fullfil customer's request Yes this SDN controller is based upon authorization of the user in previous= network and the SLAs in a new network. > what's a "hotspot controller"? > Please use 802.1X terms for me... since they spent the effort to make > all those terms up. Physical hotspot device only receives information via standard defined in 8= 02.1x and submits them to data centers where the requests are processed. In= other word, hotspot device is only like forwarder and doesn't process any= request and it only forwards all requests to the data center where everyth= ing controls by a centralized controller. Thanks, Best, Hosnieh From nobody Fri Nov 7 03:44:38 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD011ACFAC for ; Fri, 7 Nov 2014 03:44:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-QmcKYj_H-X for ; Fri, 7 Nov 2014 03:44:34 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9A361ACFAB for ; Fri, 7 Nov 2014 03:44:33 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLJ43998; Fri, 07 Nov 2014 11:44:32 +0000 (GMT) Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml403-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Fri, 7 Nov 2014 11:44:29 +0000 From: Hosnieh Rafiee To: "secauth@ietf.org" Thread-Topic: Gentle Reminder: Bar BoF availability check Thread-Index: AQHP+oAwgN/LS5t9HUi1Fki1/GoZ6w== Date: Fri, 7 Nov 2014 11:44:29 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A50B21@lhreml513-mbb.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/Wdz_CFnECz8Sh590shjfRtu-fL0 Subject: [Secauth] Gentle Reminder: Bar BoF availability check X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 11:44:36 -0000 All, Please do not forget to check your availability either as remote or onsite = on doodle poll. < http://doodle.com/83y95p8aby7tw6s5 > The agenda for this bar meeting: - presentation of gap analysis - Discussion about proposed charter and its use cases and agree on the exac= t scope of proposed charter=20 - Discussion about next steps - Your contribution to this work (Discussion about general solutions) - Any other theme that comes up Thanks, Best, Hosnieh From nobody Mon Nov 10 05:53:41 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A9B1A8ABA; Mon, 10 Nov 2014 05:53:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4zS5ho0U2sN; Mon, 10 Nov 2014 05:53:36 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBC071A8BB1; Mon, 10 Nov 2014 05:53:35 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOP57177; Mon, 10 Nov 2014 13:53:34 +0000 (GMT) Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml402-hub.china.huawei.com ([10.201.5.241]) with mapi id 14.03.0158.001; Mon, 10 Nov 2014 13:53:29 +0000 From: Hosnieh Rafiee To: IETF Discussion Thread-Topic: Bar BoF meeting for secauth on 13 Nov at 7 PM - Gentle reminder Thread-Index: AQHP/O204cAvRYhVEE2cjaEIa2nJ/Q== Date: Mon, 10 Nov 2014 13:53:28 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A516EB@lhreml513-mbb.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/7BCHsmJBA6TAYm-wKi4fvKTCnNs Cc: "secauth@ietf.org" Subject: [Secauth] Bar BoF meeting for secauth on 13 Nov at 7 PM - Gentle reminder X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 13:53:38 -0000 All, For those who are not aware of the activities of secauth, here is a short d= escription (the scope of secauth changed from the first version due to disc= ussion) If you are interested, please join the list and share your comments or inpu= ts to secauth list (IETF discussion list is only for announcment) Secuath is about supporting mobility and inter-domain authentication & auth= orization during the movement (considering both security and data confident= iality). It considers this use case where hotspots are controlled via SDN = solution or mobile node needs especial authorization on virtualized devices= such as firewall, etc. Defining the whole policy of firewall and letting t= he end user to request a virtualized firewall or other security functions a= re out of the scope of secauth but authentication & authorization of a user= in different domains during movement is in the scope of secauth. You can find the discussion about proposed charter and first versions of re= quirement and use case document here: < http://www.ietf.org/mail-archive/web/secauth/current/maillist.html> The agenda for this bar meeting is as following: - presentation of gap analysis=20 - Discussion about proposed charter and its use cases and agree on the exac= t scope of proposed charter=20 - Discussion about next steps - Your contribution to this work (Discussion about general solutions) - Any other theme that comes up If you are interested and would like to attend secauth bar meeting, please = do not forget to check your availability either as remote or onsite on dood= le poll. This is because we need the number of onsite participants so that = we can find a suitable place for them. < http://doodle.com/83y95p8aby7tw6s5 > Thanks, Best, Hosnieh From nobody Wed Nov 12 05:39:33 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8030F1A1B39; Wed, 12 Nov 2014 05:39:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hX5Eib92obvU; Wed, 12 Nov 2014 05:39:29 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5C571A802F; Wed, 12 Nov 2014 05:39:28 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOR92075; Wed, 12 Nov 2014 13:39:26 +0000 (GMT) Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml404-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Wed, 12 Nov 2014 13:39:20 +0000 From: Hosnieh Rafiee To: "secauth@ietf.org" , IETF Discussion Thread-Topic: Gentle Reminder: Tomorrow (13 Nov. 7 PM) in front of IETF registration Desk Thread-Index: AQHP/n4PV5hqLfj4QUWIOpQJBnfmIQ== Date: Wed, 12 Nov 2014 13:39:19 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A5C315@lhreml513-mbb.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/CjBsqQfQABgp2tq62zyV8PhFN4k Cc: "Liushucheng \(Will\)" Subject: [Secauth] Gentle Reminder: Tomorrow (13 Nov. 7 PM) in front of IETF registration Desk X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 13:39:32 -0000 All, According to doodle poll, until now, there are 6 people who shows their int= erest to attend secauth bar BoF. I ask you please come to IETF registration desk around 7 PM. Will (CC) is t= he onsite organizer of this meeting.=20 If you have any question, please do not hesitate to contact us. Thanks, See you! Best, Hosnieh From nobody Wed Nov 12 06:03:52 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F30701A1B3D for ; Wed, 12 Nov 2014 06:03:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9cTtU-bMax0 for ; Wed, 12 Nov 2014 06:03:47 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93AF61A8A3A for ; Wed, 12 Nov 2014 06:03:45 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOR94722; Wed, 12 Nov 2014 14:03:44 +0000 (GMT) Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml405-hub.china.huawei.com ([10.201.5.242]) with mapi id 14.03.0158.001; Wed, 12 Nov 2014 14:03:35 +0000 From: Hosnieh Rafiee To: "secauth@ietf.org" Thread-Topic: Followup: Tomorrow (13 Nov. 7 PM) in front of IETF registration Desk Thread-Index: AQHP/oFyQSUYhNJf3EqqnPuID1HD4Q== Date: Wed, 12 Nov 2014 14:03:34 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A5C356@lhreml513-mbb.china.huawei.com> References: <814D0BFB77D95844A01CA29B44CBF8A7A5C315@lhreml513-mbb.china.huawei.com> In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A7A5C315@lhreml513-mbb.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/R1O0a6So80yNTjo_Xvc6y6KoT7g Cc: "Liushucheng \(Will\)" Subject: [Secauth] Followup: Tomorrow (13 Nov. 7 PM) in front of IETF registration Desk X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 14:03:50 -0000 Follow up, I forgot to tell you that I have asked for a room reservation and waiting f= or the response of IETF secretary. If the result is positive, from registra= tion desk we can go to that reserved room otherwise we have to find any ava= ilable place. Thanks, Best, Hosnieh From nobody Wed Nov 12 11:55:56 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2021A19EA for ; Wed, 12 Nov 2014 11:55:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpww4_cZZq5x for ; Wed, 12 Nov 2014 11:55:34 -0800 (PST) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B3B01A19E5 for ; Wed, 12 Nov 2014 11:55:34 -0800 (PST) Received: by mail-lb0-f178.google.com with SMTP id f15so11147392lbj.9 for ; Wed, 12 Nov 2014 11:55:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8541kL/4fWcDTsgd8zRt9EC+3jblFGDv4vBcmTqJdOg=; b=W0pwdEdWF2LLbHRRK8MwmJEvD9dmEK6uiYQDtll2x0z0e4ZKKq42lm3N6GKXO1uwLJ getQrUk7UkPdyOrTe7Ocs758MraN7oADU03/mVvD9JS9Bw+C+jEsTQWG1CSWXLFwOM36 aAHs+1FGdqTgsEKeYOM47TkLaLIEpUrzmLzJwM8923cIrm/JBY6ByvaeDS04Hw3D3tnl 8pJPQgYnUxhGaW5SBGCf7gfxaCxaWmJ5FN+8ZCa2jmIxUjMTZufj8ThL6o4GTbUGtqVX ZafBa0SMpk7k5L9hry3Zl2LMNdMCBYJkghqyBsQbM6eMDye8TxmhF5Dd5g8OIR/RDUDc lNZA== MIME-Version: 1.0 X-Received: by 10.112.135.229 with SMTP id pv5mr44048881lbb.52.1415822132609; Wed, 12 Nov 2014 11:55:32 -0800 (PST) Received: by 10.112.49.52 with HTTP; Wed, 12 Nov 2014 11:55:32 -0800 (PST) In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A7A5C356@lhreml513-mbb.china.huawei.com> References: <814D0BFB77D95844A01CA29B44CBF8A7A5C315@lhreml513-mbb.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A5C356@lhreml513-mbb.china.huawei.com> Date: Wed, 12 Nov 2014 14:55:32 -0500 Message-ID: From: Kathleen Moriarty To: Hosnieh Rafiee Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/9-mlrDn5Iou6CvCsWMwMnU-3UBg Cc: "secauth@ietf.org" , "Liushucheng \(Will\)" Subject: Re: [Secauth] Followup: Tomorrow (13 Nov. 7 PM) in front of IETF registration Desk X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 19:55:39 -0000 On Wed, Nov 12, 2014 at 9:03 AM, Hosnieh Rafiee wrote: > Follow up, > > I forgot to tell you that I have asked for a room reservation and waiting for the response of IETF secretary. If the result is positive, from registration desk we can go to that reserved room otherwise we have to find any available place. Hosnieh, As you are well aware, your request from a room was denied several times already, including yesterday. Both Stephen and I have explained this decision multiple times, so the secretariat will not be allocating resources for your gathering. Your initial request for a side meeting was denied when the window was open for BoF and Side Meeting requests. We go through a formal review process several weeks in advance of the IETF as scheduling can be very challenging for a large meeting like the IETF. As we explained, you are welcome to gather with interested folks to further develop your efforts, however this would be in a space that is not allocated by the IETF. Since this is not an approved BoF or side meeting, you could have a dinner gathering or meet at a bar or at some other non-IETF issued room. I believe the time you are meeting is during the plenary, so if this were a side meeting, that time would not be available either for a room. Regards, Kathleen > > Thanks, > Best, > Hosnieh > > _______________________________________________ > Secauth mailing list > Secauth@ietf.org > https://www.ietf.org/mailman/listinfo/secauth -- Best regards, Kathleen From nobody Wed Nov 12 12:10:46 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDD11AD0B0 for ; Wed, 12 Nov 2014 12:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WsUpWmAb_5E0 for ; Wed, 12 Nov 2014 12:10:33 -0800 (PST) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F7D41A8781 for ; Wed, 12 Nov 2014 12:08:53 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id D124F25CA0C2; Wed, 12 Nov 2014 20:08:48 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2gISNGWpE54; Wed, 12 Nov 2014 21:08:17 +0100 (CET) Received: from kopoli (p5B34173C.dip0.t-ipconnect.de [91.52.23.60]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id EF23025CA06F; Wed, 12 Nov 2014 21:08:16 +0100 (CET) From: "Hosnieh Rafiee" To: "'Kathleen Moriarty'" References: <814D0BFB77D95844A01CA29B44CBF8A7A5C315@lhreml513-mbb.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A5C356@lhreml513-mbb.china.huawei.com> In-Reply-To: Date: Wed, 12 Nov 2014 21:08:14 +0100 Message-ID: <009501cffeb4$65598e10$300caa30$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHinqkZS63F/dt4yAJiro5aQllfdAIR/avaASoshjacHkfr4A== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/MCbXJhOKC8pV1rnsvAlWfuU-A4s Cc: secauth@ietf.org, "'Liushucheng \(Will\)'" Subject: Re: [Secauth] Followup: Tomorrow (13 Nov. 7 PM) in front of IETF registration Desk X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 20:10:36 -0000 Hi Kathleen, I understand that before applying for BoF, we were still working on scope and so on and it was not ready and when we were ready it was already too late. Therefore my second request for room reservation was not in the scope of IETF and it was "non-profit" (paid) meeting room with speaker. Since it is out of time of IETF and plenary is today, I think there might be many possibilities for empty rooms. Thanks, Best, Hosnieh > -----Original Message----- > From: Secauth [mailto:secauth-bounces@ietf.org] On Behalf Of Kathleen > Moriarty > Sent: Wednesday, November 12, 2014 8:56 PM > To: Hosnieh Rafiee > Cc: secauth@ietf.org; Liushucheng (Will) > Subject: Re: [Secauth] Followup: Tomorrow (13 Nov. 7 PM) in front of IETF > registration Desk > > On Wed, Nov 12, 2014 at 9:03 AM, Hosnieh Rafiee > wrote: > > Follow up, > > > > I forgot to tell you that I have asked for a room reservation and waiting for > the response of IETF secretary. If the result is positive, from registration desk > we can go to that reserved room otherwise we have to find any available > place. > > Hosnieh, > > As you are well aware, your request from a room was denied several times > already, including yesterday. Both Stephen and I have explained this decision > multiple times, so the secretariat will not be allocating resources for your > gathering. Your initial request for a side meeting was denied when the > window was open for BoF and Side Meeting requests. We go through a > formal review process several weeks in advance of the IETF as scheduling can > be very challenging for a large meeting like the IETF. As we explained, you are > welcome to gather with interested folks to further develop your efforts, > however this would be in a space that is not allocated by the IETF. Since this is > not an approved BoF or side meeting, you could have a dinner gathering or > meet at a bar or at some other non-IETF issued room. > > I believe the time you are meeting is during the plenary, so if this were a side > meeting, that time would not be available either for a room. > > Regards, > Kathleen > > > > > Thanks, > > Best, > > Hosnieh > > > > _______________________________________________ > > Secauth mailing list > > Secauth@ietf.org > > https://www.ietf.org/mailman/listinfo/secauth > > > > -- > > Best regards, > Kathleen > > _______________________________________________ > Secauth mailing list > Secauth@ietf.org > https://www.ietf.org/mailman/listinfo/secauth From nobody Wed Nov 12 14:27:47 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6AD31ACEAD for ; Wed, 12 Nov 2014 14:27:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5AQv0Tpykzn0 for ; Wed, 12 Nov 2014 14:27:36 -0800 (PST) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B6E01ACEB1 for ; Wed, 12 Nov 2014 14:27:36 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id BC2CA25CA0C2 for ; Wed, 12 Nov 2014 22:27:34 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJOgR-Q3Vs9f for ; Wed, 12 Nov 2014 23:27:05 +0100 (CET) Received: from kopoli (p5B34173C.dip0.t-ipconnect.de [91.52.23.60]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id BD02925CA06F for ; Wed, 12 Nov 2014 23:27:05 +0100 (CET) From: "Hosnieh Rafiee" To: Date: Wed, 12 Nov 2014 23:27:03 +0100 Message-ID: <00cf01cffec7$c9af9c70$5d0ed550$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac/+x8bRYQTUsiGSR6y8tO/WzX0YSQ== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/QByyUhQ1H0-kpB4k6JWBV5a0X3g Subject: [Secauth] Clarification of the scope of bar meeting tomorrow X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 22:27:40 -0000 Folks, I have asked for this side meeting in order to discuss the topic outside of the official IETF meetings, and to prepare for a possible official BoF in Dallas. Best, Hosnieh See you tomorrow at 7 PM. From nobody Thu Nov 13 20:47:37 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0521A00C0; Thu, 13 Nov 2014 20:47:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0T_krzLusqL; Thu, 13 Nov 2014 20:47:24 -0800 (PST) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 632901A0065; Thu, 13 Nov 2014 20:47:24 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id A466E25CA0C2; Fri, 14 Nov 2014 04:47:21 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyohmcQoovwX; Fri, 14 Nov 2014 05:46:50 +0100 (CET) Received: from kopoli (p5B34173C.dip0.t-ipconnect.de [91.52.23.60]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id AFE8D25CA067; Fri, 14 Nov 2014 05:46:49 +0100 (CET) From: "Hosnieh Rafiee" To: "'Yoav Nir'" , , Date: Fri, 14 Nov 2014 05:46:44 +0100 Message-ID: <007501cfffc5$ff511da0$fdf358e0$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: Ac//xf2j1eR24cpgSs6HJALdh6A6jQ== Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/a9voFjuN2eSwTNJWFafkxYVcC6g Cc: 'IETF Discussion' Subject: Re: [Secauth] Gentle Reminder: in front of IETF registration Desk at 7:15 X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 04:47:28 -0000 All, Please note that the session would be started with 15 minutes delay at = 7:15 PM. The meeting point is at IETF registration desk.=20 Thanks, Best, Hosnieh > Let=E2=80=99s make it 7:15, because sessions run until 7:10. Ok > > On Nov 12, 2014, at 3:39 AM, Hosnieh Rafiee > wrote: > > > > All, > > > > According to doodle poll, until now, there are 6 people who shows = their > interest to attend secauth bar BoF. > > > > I ask you please come to IETF registration desk around 7 PM. Will = (CC) is the > onsite organizer of this meeting. > > > > > > If you have any question, please do not hesitate to contact us. > > > > > > Thanks, > > See you! > > Best, > > Hosnieh > > > > From nobody Thu Nov 13 21:21:23 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2479E1A6F5B for ; Thu, 13 Nov 2014 21:21:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594, T_REMOTE_IMAGE=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CfQRhNJ0QkNN for ; Thu, 13 Nov 2014 21:21:10 -0800 (PST) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 195CA1A6F52 for ; Thu, 13 Nov 2014 21:21:10 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 7032C25CA0C2; Fri, 14 Nov 2014 05:21:07 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THeon--IhMCW; Fri, 14 Nov 2014 06:20:36 +0100 (CET) Received: from kopoli (p5B34173C.dip0.t-ipconnect.de [91.52.23.60]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 987B725CA067; Fri, 14 Nov 2014 06:20:35 +0100 (CET) From: "Hosnieh Rafiee" To: Date: Fri, 14 Nov 2014 06:20:31 +0100 Message-ID: <008201cfffca$b6d78cd0$2486a670$@rozanak.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0083_01CFFFD3.18A6A330" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: Ac//yrS+oX5iSrHSTviyBK18KdFC6Q== Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/xRCgh_qkUM6uv9D1VCXiDpoQSm8 Subject: [Secauth] webex info X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 05:21:13 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0083_01CFFFD3.18A6A330 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Meeting info =20 From: Cisco WebEx [mailto:admin@webex.com]=20 Sent: Friday, November 14, 2014 5:56 AM To: ietf@rozanak.com Subject: WebEx meeting scheduled: Hosnieh Ra's WebEx Meeting =20 =09 =09 =09 Cisco WebEx = logo =20 =09 =20 Hi =09 You are scheduled to host this WebEx meeting. =09 Here are the details for your meeting. To edit the meeting or add files = and comments, visit your meeting space by selecting the meeting name = below. =09 =20 = =20 =20 Freitag, 14. Nov., 6:00 | 3 hr Amsterdam (Europe Time, GMT+01:00) Host: Hosnieh Ra =20 =09 = Start=20 =09 =20 =09 =20 = =20 =20 Add the attached iCalendar (.ics) file to your calendar.=20 =20 =09 =20 = =20 =20 Agenda This meeting does not have an agenda.=20 =20 =09 =20 = =20 =20 Access Information Where: =20 WebEx Online Meeting number: =20 236 960 928 Password: =20 secauth =20 =20 =20 =20 =09 =20 = =20 =20 Audio Connection +44-203-478-5289 UK Domestic Toll =09 Access code: 236 960 928 =09 =20 =09 =20 =09 =20 =09 Need more numbers or information? Check out = global call-in numbers. =20 =09 =20 =09 Can't access your meeting? = Get help. =09 Delivering the power of collaboration Cisco WebEx Team=20 =09 Footer = =20 =09 IMPORTANT NOTICE: This WebEx service includes a feature that allows = audio and any documents and other materials exchanged or viewed during = the meeting to be recorded. You should inform all meeting attendees = prior to recording if you intend to record the meeting. Please note that = any such recordings may be subject to discovery in the event of = litigation.=20 =C2=A92014 Cisco and/or its affiliates. All rights reserved. MT-A-015=20 Cisco = =20 =09 =20 ------=_NextPart_000_0083_01CFFFD3.18A6A330 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Meeting = info

 

From:= = Cisco WebEx [mailto:admin@webex.com]
Sent: Friday, November = 14, 2014 5:56 AM
To: ietf@rozanak.com
Subject: WebEx = meeting scheduled: Hosnieh Ra's WebEx = Meeting

 

3D"Cisco

 =

Hi=

You are = scheduled to host this WebEx meeting.

Here are the = details for your meeting. To edit the meeting or add files and comments, = visit your meeting space by selecting the meeting name = below.

 

  

= Freitag, 14. Nov., 6:00= | 3 hr

= Amsterdam (Europe Time, GMT+01:00)

= Host: Hosnieh Ra

  

=

 

 

 

= Add the attached iCalendar (.ics) file to your calendar. =

 

 

 

Agenda

This mee= ting does not have an agenda. =

 

 

 

 

Access = Information

Where:

 

WebEx = Online

Meeting = number:

 

236 960 = 928

Password:

 

secauth<= /o:p>

 

 

 

 

 

Audio = Connection

+44-203-478-5= 289 UK Domestic = Toll

Access code: = 236 960 = 928

=  

=  

=  

Need more = numbers or information? Check out global call-in = numbers.

 

 

Can't access = your meeting? Get = help.

Delivering the power of collaboration
Cisco WebEx Team =

3DFooter

= IMPORTANT NOTICE: This WebEx service includes a feature that allows = audio and any documents and other materials exchanged or viewed during = the meeting to be recorded. You should inform all meeting attendees = prior to recording if you intend to record the meeting. Please note that = any such recordings may be subject to discovery in the event of = litigation.

= =C2=A92014 Cisco and/or its affiliates. All rights reserved.
MT-A-015 =

3DCisco

 

------=_NextPart_000_0083_01CFFFD3.18A6A330-- From nobody Sat Nov 15 21:21:52 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D83711A6F59 for ; Sat, 15 Nov 2014 21:21:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_NO_TEXT=1.997, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8V3CwdCtl4jh for ; Sat, 15 Nov 2014 21:21:48 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 288641A1AB5 for ; Sat, 15 Nov 2014 21:21:48 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id EAA5C20012 for ; Sun, 16 Nov 2014 00:24:05 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 559B5637F4; Sun, 16 Nov 2014 00:21:46 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3C9FE637EA for ; Sun, 16 Nov 2014 00:21:46 -0500 (EST) From: Michael Richardson To: secauth@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/zKeLFAFfmKQk-Qj9K9RNzap7q1Y Subject: [Secauth] side meeting -- portal BCP X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Nov 2014 05:21:50 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Between the NOMCOM office hours and the IPv6-Scotch, I stopped into the side meeting for secauth. I admit that I know little about what Hosniah is proposing, but it seems like a solution looking for a problem... I don't understand any of the SDN involvements at all.=20 We did come to believe that it would be SO NICE if we could have hotel/airport/etc. wifi-portals which did not suck: the bad ones rely on DNS poisioning, the really really bad ones rely on your device USING the DNS search path... the better ones just hijack port-80, which HTTP2.0 will like= ly break.=20=20 Tero suggested some kind of assertion that would at least say, "I've already agreed to your terms and conditions" which one could put in... I guess a DHCP* request.=20 In the hotel (I had to switch hotels Friday night, so I was in a little airport motel) van today, on the way to the airfort, the driver asked what = I=20 do, and I explained briefly what the IETF was. He mentioned that on the shaka.net hotel wifi they have, that Android phones get on no delays, but that iPhones always need to be prodded. I don't know what is up; but my guess is that the hotel portal software whitelists by MAC address. And new= er iPhone builds are doing MAC address randomization, while Android ROMs in the field always (sadly) old... This is a place where privacy improvements are going to suck for a lot of people, I think. I don't think we can write a useful/deployable BCP on portals without participation of at least some of: AOSP/CyangogenMod, Apple/iPhone, and some large portal users. I'm thinking Starbucks... maybe we could use our IAOC connections to the Hilton to suck them in. The operators have to be at t= he table, because most of the public facing portals are internally built. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVGg0ZoCLcPvd0N1lAQLKrQf+KRmGbWbo/hrPriMmJih3rrNjyhd0PohJ EgvNEoIFk17wziMGNwB1tyG8SwfOuc4RF7IraGqtrmxVLugLhW/5w3RCQ+okgWa4 5O53hZxMJpmBGXgxI15Q0z9J9JvDRDLNfC96JRgipfYf+CB9XNYxzAo2+ftElpf5 FoqqwTSzqXPcHyUYDHJN4/LJvC4113vBh6FS2PYln2Y91URGziYbUQZRwactn1ie oGW5Hj19OCPVW+xfk/nQfE6vrmf8CC/JXC5TSKawf7Hrs1atpO/6yleIhqQlnjMl 692lqCP7YCDtkDoEKeSKD9QYYPlJ6Vj8n2xOl04Mvb6quTyO94WAVQ== =//FP -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Nov 16 08:12:41 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5084D1A1A25; Thu, 13 Nov 2014 20:32:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41P7GyYGjBW6; Thu, 13 Nov 2014 20:32:56 -0800 (PST) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C91421A1A4F; Thu, 13 Nov 2014 20:32:55 -0800 (PST) Received: by mail-wg0-f52.google.com with SMTP id b13so18295805wgh.25 for ; Thu, 13 Nov 2014 20:32:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bAb5j5Hc54hwqoa3iOwyCdEQ4TaUTSrlO9PgeHQkdX8=; b=aeQZWMXVtiuxOdPtcMoFYTZP6MTLkCsEkSXwf0liNfHtwDCbRiF33+2RY+KmHTVV6B 69zE5BHXblHqM67cr9i1OLpeEVzoVHP3aibXuMlhZexjzigmmnDBJfyptGkmd1Na3G1A huKSHspFVT/UFUZIxGwR2qm6I0+eb7c/pQ62bSTgNPaGFmE+xXNB1xZAG+b45XAPDfIc 0cmOv2xDKbw3VR44vOQgg4lOku8BSM+ZPLuAicB93gEy5vtv8m4FUl8O3ISebcFgjUaB uOr3Ui/r+4dAfl3rO2qKW0PaLAtzKU16lio9juK+cIx16SJmX6sknModFz0yNUbVPlSP zWLA== X-Received: by 10.180.103.1 with SMTP id fs1mr3899983wib.62.1415939574625; Thu, 13 Nov 2014 20:32:54 -0800 (PST) Received: from dhcp-a75f.meeting.ietf.org (dhcp-a75f.meeting.ietf.org. [31.133.167.95]) by mx.google.com with ESMTPSA id p1sm38024747wjy.22.2014.11.13.20.32.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Nov 2014 20:32:54 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Yoav Nir In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A7A5C315@lhreml513-mbb.china.huawei.com> Date: Thu, 13 Nov 2014 18:32:51 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <814D0BFB77D95844A01CA29B44CBF8A7A5C315@lhreml513-mbb.china.huawei.com> To: "secauth@ietf.org" X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/la_trlki-JQQP1d7H18P7n1XDQc X-Mailman-Approved-At: Sun, 16 Nov 2014 08:12:39 -0800 Cc: IETF Discussion Subject: Re: [Secauth] Gentle Reminder: Tomorrow (13 Nov. 7 PM) in front of IETF registration Desk X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 04:32:57 -0000 Let=E2=80=99s make it 7:15, because sessions run until 7:10. > On Nov 12, 2014, at 3:39 AM, Hosnieh Rafiee = wrote: >=20 > All, >=20 > According to doodle poll, until now, there are 6 people who shows = their interest to attend secauth bar BoF. >=20 > I ask you please come to IETF registration desk around 7 PM. Will (CC) = is the onsite organizer of this meeting.=20 >=20 >=20 > If you have any question, please do not hesitate to contact us. >=20 >=20 > Thanks, > See you! > Best, > Hosnieh >=20 >=20 From nobody Mon Nov 17 00:42:09 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 115761A19F1 for ; Mon, 17 Nov 2014 00:42:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.184 X-Spam-Level: X-Spam-Status: No, score=0.184 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.594, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZvHDvYTM6et for ; Mon, 17 Nov 2014 00:42:05 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41B3C1A0AF7 for ; Mon, 17 Nov 2014 00:42:05 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id sAH8g1lp006278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 17 Nov 2014 10:42:01 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id sAH8g0T8023505; Mon, 17 Nov 2014 10:42:00 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21609.46296.642010.426288@fireball.kivinen.iki.fi> Date: Mon, 17 Nov 2014 10:42:00 +0200 From: Tero Kivinen To: Michael Richardson In-Reply-To: <22000.1416115306@sandelman.ca> References: <22000.1416115306@sandelman.ca> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 8 min X-Total-Time: 8 min Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/-T5LFjp29NHyoCbCq19mufsn3VQ Cc: secauth@ietf.org Subject: [Secauth] side meeting -- portal BCP X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 08:42:08 -0000 Michael Richardson writes: > Tero suggested some kind of assertion that would at least say, "I've already > agreed to your terms and conditions" which one could put in... I guess a > DHCP* request. That was not me, that was someone else. I think there is no way we are going to be able to do anything, as if the hotel staff do not care that the portals are bad for the customers, and operators want to show all kind of advertisments and ask all kind of questions from you (your email address, whatever, or just to agree on their terms and conditions, which usally include all kind of junk), why should they want to change. I mean it will only help users, and none of those people seam to care. Actually in some hotels they just know the system is stupid, but they cannot do anything, as it is provided by third party and there is "nothing" the hotel can do to fix situations. In one hotel in argentina the travel info page told us that the wifi is broken (the review was 2 years old), and it still was broken, and when we asked the reception, they said that yes, they know it is broken, but it is provided by 3rd party and they have not been able to fix it, but we have put one adsl line and wlan modem in the reception, you can use that :-) So the hotel had few dozen useless wifi access points around the hotel, and only one working that was put there most likely without approval, that actually worked... Unfortunately that meant we had to sit in the hotel lobby quite close to the reception... > connections to the Hilton to suck them in. The operators have to be at the > table, because most of the public facing portals are internally built. The internal built portals would be the ones that could be fixed, as they might have way to fix things. The 3rd party portals provided by telecom, isps etc are the ones which are impossible to fix, as hotels most likely have multiyear contracts with them, and those 3rd party operators have no interest of fixing anything, and if they can show you few more ads while you log in, they might get more money. So as the owners of the network do not care, I think this is problem that we (the IETF) cannot fix... -- kivinen@iki.fi From nobody Mon Nov 17 10:30:48 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB781A8790 for ; Mon, 17 Nov 2014 10:30:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F17--hAQMXyA for ; Mon, 17 Nov 2014 10:30:45 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 465FE1A8792 for ; Mon, 17 Nov 2014 10:30:43 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1B39520012; Mon, 17 Nov 2014 13:33:07 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 2F7FB637F5; Mon, 17 Nov 2014 13:30:42 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 1868063745; Mon, 17 Nov 2014 13:30:42 -0500 (EST) From: Michael Richardson To: secauth@ietf.org, Crocker Steve , Dan York In-Reply-To: <21609.46296.642010.426288@fireball.kivinen.iki.fi> References: <22000.1416115306@sandelman.ca> <21609.46296.642010.426288@fireball.kivinen.iki.fi> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/U8LNIvPEsgJuv-_3N3YCEJTnH4c Subject: Re: [Secauth] side meeting -- portal BCP X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 18:30:47 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable for those CC'ed: http://mailarchive.ietf.org/arch/msg/secauth/-T5LFjp29NHyoCbCq19mufsn3VQ Tero Kivinen wrote: > I mean it will only help users, and none of those people seam to care. > Actually in some hotels they just know the system is stupid, but they > cannot do anything, as it is provided by third party and there is > "nothing" the hotel can do to fix situations. I agree with you in practice. In principle, educated customers could ask if the hotel wireless was BCPXXX compliant. This would include no molesting one's DNSSEC queries, and I was lead to believe that this could wind up in a government procurement request, if only there was a specification they could point to. > So the hotel had few dozen useless wifi access points around the hote= l, > and only one working that was put there most likely without approval, > that actually worked... Unfortunately that meant we had to sit in the > hotel lobby quite close to the reception... So the hotel has a contract and managemenet problem, and somehow this is not affecting the hotel's ability to get business... did you consider just unplugging the broken system for them? >> connections to the Hilton to suck them in. The operators have to be >> at the table, because most of the public facing portals are internal= ly >> built. > The internal built portals would be the ones that could be fixed, as > they might have way to fix things. The 3rd party portals provided by > telecom, isps etc are the ones which are impossible to fix, as hotels > most likely have multiyear contracts with them, and those 3rd party > operators have no interest of fixing anything, and if they can show y= ou > few more ads while you log in, they might get more money. > So as the owners of the network do not care, I think this is problem > that we (the IETF) cannot fix... well, I can't disagree with you; there seems to be an opportunity for someo= ne. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVGo+zoCLcPvd0N1lAQLqxAgAkcPJoVmV3EL4ISBeghVO1xwC84PDG052 hRvIsEPNplWTwTFOqk2bm4t1wYUAl9Mqa3mgGUEqIXHwJo7zJuvrdikw/6Yn8zdj 74XXQMUWldo5KtK52o3aX9k+SwXb1lJ2jRC+I2XuAQVVS1G/eciO9ToIld1otbzp Qby5fIE3LvNvCBNE90qw4kodHQQwWZWHIGImJPkmZoQ+MDH3ABRByStec4k7HmSI uMTiC2LoR/lN2Qh5xtrtTbGKrkriNlCBKaDBFTNx/069PcBShex4VBJ3QyQ0lkaS tWqBZlBuGzftVkycMZMLA7rNyheOEKMey7URuK+JW7nG+lz2ftfdYQ== =HRsT -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Nov 17 11:22:24 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 702901A8A0C for ; Mon, 17 Nov 2014 11:22:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hesMJEySxBX for ; Mon, 17 Nov 2014 11:22:20 -0800 (PST) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E1341A8A01 for ; Mon, 17 Nov 2014 11:22:20 -0800 (PST) Received: by mail-pa0-f48.google.com with SMTP id rd3so9203794pab.7 for ; Mon, 17 Nov 2014 11:22:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=QzS/9SDpyHvUkGcUM4lDulsGC8spT2KS/w69fzOrEks=; b=WUE+WLUqJxOGEmz07uJfYrwCWv5+jtRqccpK4AW3Xj5glMp/9V5HnNvLlTVA+j0Ndo RwDLr/cSL4x72x1v3WiDNepYcjgNzUbJkmCGzZ53l1YBfKe5r5D5T2K050ofylbmOdYx OeVPW78XuQ7FqhVFcMRLVO8CT5yfNaT3sghjMT+uGb14aKu8b8h5wgJ2RMTykunQ1lym 2ZknpsLBXZtW7yQm2Bc3V6IwzmeWqjn0vDIqHR7NiuQRQJtRYNkV8B+4ku0+qwWkK5Ys EPuosE5CJZjtONbruE4obMMad2b4FC31M9IZorcng4XC5wgaNtFBae5j6tRFust9V5jF r6Ow== X-Gm-Message-State: ALoCoQl5y86BvK0L0c1b1+8pg0dZbUGLUj164TKzWdo6Fm2BGIszN1W+xuETkxo10/Z+KqWWZINM X-Received: by 10.70.42.98 with SMTP id n2mr5962263pdl.139.1416252139647; Mon, 17 Nov 2014 11:22:19 -0800 (PST) Received: from [192.168.1.95] (75-37-193-167.lightspeed.lsatca.sbcglobal.net. [75.37.193.167]) by mx.google.com with ESMTPSA id he5sm35703317pbb.53.2014.11.17.11.22.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Nov 2014 11:22:19 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Paul Lambert In-Reply-To: <7423.1416249042@sandelman.ca> Date: Mon, 17 Nov 2014 11:22:17 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <22000.1416115306@sandelman.ca> <21609.46296.642010.426288@fireball.kivinen.iki.fi> <7423.1416249042@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/RUEknNbgp4lzAV1UfzYAmaw-8c8 Cc: Crocker Steve , secauth@ietf.org, Dan York Subject: Re: [Secauth] side meeting -- portal BCP X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 19:22:22 -0000 > On Nov 17, 2014, at 10:30 AM, Michael Richardson = wrote: >=20 >=20 > for those CC'ed: > = http://mailarchive.ietf.org/arch/msg/secauth/-T5LFjp29NHyoCbCq19mufsn3VQ >=20 >=20 > Tero Kivinen wrote: >> I mean it will only help users, and none of those people seam to = care. >> Actually in some hotels they just know the system is stupid, but they >> cannot do anything, as it is provided by third party and there is >> "nothing" the hotel can do to fix situations. >=20 > I agree with you in practice. > In principle, educated customers could ask if the hotel wireless was = BCPXXX > compliant. This would include no molesting one's DNSSEC queries, and = I > was lead to believe that this could wind up in a government = procurement > request, if only there was a specification they could point to. >=20 >> So the hotel had few dozen useless wifi access points around the = hotel, >> and only one working that was put there most likely without approval, >> that actually worked... Unfortunately that meant we had to sit in the >> hotel lobby quite close to the reception... >=20 > So the hotel has a contract and managemenet problem, and somehow this = is not > affecting the hotel's ability to get business... did you consider just > unplugging the broken system for them? >=20 >>> connections to the Hilton to suck them in. The operators have to be >>> at the table, because most of the public facing portals are = internally >>> built. >=20 >> The internal built portals would be the ones that could be fixed, as >> they might have way to fix things. The 3rd party portals provided by >> telecom, isps etc are the ones which are impossible to fix, as hotels >> most likely have multiyear contracts with them, and those 3rd party >> operators have no interest of fixing anything, and if they can show = you >> few more ads while you log in, they might get more money. >=20 >> So as the owners of the network do not care, I think this is problem >> that we (the IETF) cannot fix=E2=80=A6 Other forums are working on the problem: = https://www.wi-fi.org/passpoint-release-2-operator-best-practices-for-aaa-= interface-deployment-v200 (sorry =E2=80=A6 not a free spec :-( =20 Paul >=20 > well, I can't disagree with you; there seems to be an opportunity for = someone. >=20 > --=20 > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > _______________________________________________ > Secauth mailing list > Secauth@ietf.org > https://www.ietf.org/mailman/listinfo/secauth From nobody Mon Nov 17 14:34:55 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D15341ACDBB for ; Mon, 17 Nov 2014 14:34:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPKloDxj09QE for ; Mon, 17 Nov 2014 14:34:50 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F6411ACDBA for ; Mon, 17 Nov 2014 14:34:49 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id sAHMYmAB002870 for ; Mon, 17 Nov 2014 23:34:48 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 569A420830D for ; Mon, 17 Nov 2014 23:35:14 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 4E9B8207F50 for ; Mon, 17 Nov 2014 23:35:14 +0100 (CET) Received: from [127.0.0.1] ([132.166.84.25]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id sAHMYRhe024784 for ; Mon, 17 Nov 2014 23:34:45 +0100 Message-ID: <546A77F2.4050800@gmail.com> Date: Mon, 17 Nov 2014 23:34:26 +0100 From: Alexandre Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: secauth@ietf.org References: <22000.1416115306@sandelman.ca> <21609.46296.642010.426288@fireball.kivinen.iki.fi> <7423.1416249042@sandelman.ca> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/dMgYLPcdOZU_tTEqzUN7VmKZRQk Subject: Re: [Secauth] side meeting -- portal BCP X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 22:34:53 -0000 Le 17/11/2014 20:22, Paul Lambert a écrit : > >> On Nov 17, 2014, at 10:30 AM, Michael Richardson wrote: >> >> >> for those CC'ed: >> http://mailarchive.ietf.org/arch/msg/secauth/-T5LFjp29NHyoCbCq19mufsn3VQ >> >> >> Tero Kivinen wrote: >>> I mean it will only help users, and none of those people seam to care. >>> Actually in some hotels they just know the system is stupid, but they >>> cannot do anything, as it is provided by third party and there is >>> "nothing" the hotel can do to fix situations. >> >> I agree with you in practice. >> In principle, educated customers could ask if the hotel wireless was BCPXXX >> compliant. This would include no molesting one's DNSSEC queries, and I >> was lead to believe that this could wind up in a government procurement >> request, if only there was a specification they could point to. >> >>> So the hotel had few dozen useless wifi access points around the hotel, >>> and only one working that was put there most likely without approval, >>> that actually worked... Unfortunately that meant we had to sit in the >>> hotel lobby quite close to the reception... >> >> So the hotel has a contract and managemenet problem, and somehow this is not >> affecting the hotel's ability to get business... did you consider just >> unplugging the broken system for them? >> >>>> connections to the Hilton to suck them in. The operators have to be >>>> at the table, because most of the public facing portals are internally >>>> built. >> >>> The internal built portals would be the ones that could be fixed, as >>> they might have way to fix things. The 3rd party portals provided by >>> telecom, isps etc are the ones which are impossible to fix, as hotels >>> most likely have multiyear contracts with them, and those 3rd party >>> operators have no interest of fixing anything, and if they can show you >>> few more ads while you log in, they might get more money. >> >>> So as the owners of the network do not care, I think this is problem >>> that we (the IETF) cannot fix… > > Other forums are working on the problem: https://www.wi-fi.org/passpoint-release-2-operator-best-practices-for-aaa-interface-deployment-v200 > (sorry … not a free spec :-( So we are not alone to think something could be done about it. I think we could try to list the un-features of portals making them hard to automate through: i.e. the way it gets into DNS resolution path, the capture and change of IP packets, the http features helping with it. And the features which may help - cookies were mentioned at the meeting, SDN-based firewall opening rules which may be triggered by an automated pass-through, scripting portal messaging, etc. Total automation of portal get-through may not be achievable in all cases, but maybe a few goals could be imagined. For example, ISPs with subscribed users may offer automated WiFi to them only, whereas other uses get the forms and the ad screens. Another goal for simple automation may be the airport lounge hotspot providers who force into every-15minute ack the conditions. Too, maybe a common recipe for Computers to automatically identify the presence of a capturing portal based on the kind of replies it receives (e.g. a DNS resolve of two different TLDs resolving into the same non-routable IP address) could be an achievable goal. Alex > > Paul > > > >> >> well, I can't disagree with you; there seems to be an opportunity for someone. >> >> -- >> Michael Richardson , Sandelman Software Works >> -= IPv6 IoT consulting =- >> >> >> >> _______________________________________________ >> Secauth mailing list >> Secauth@ietf.org >> https://www.ietf.org/mailman/listinfo/secauth > > _______________________________________________ > Secauth mailing list > Secauth@ietf.org > https://www.ietf.org/mailman/listinfo/secauth > From nobody Mon Nov 17 16:59:10 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB79B1AD02D for ; Mon, 17 Nov 2014 16:59:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jK2aCqGS8lGG for ; Mon, 17 Nov 2014 16:59:03 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 187DF1AD02C for ; Mon, 17 Nov 2014 16:59:03 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4A20C2002A; Mon, 17 Nov 2014 20:01:27 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 679E0637F5; Mon, 17 Nov 2014 19:59:01 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 508B763745; Mon, 17 Nov 2014 19:59:01 -0500 (EST) From: Michael Richardson To: Paul Lambert In-Reply-To: References: <22000.1416115306@sandelman.ca> <21609.46296.642010.426288@fireball.kivinen.iki.fi> <7423.1416249042@sandelman.ca> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/TZhAKMBUl0lnbRtduzwtlmYKsFQ Cc: Crocker Steve , secauth@ietf.org, Dan York Subject: Re: [Secauth] side meeting -- portal BCP X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 00:59:07 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Paul Lambert wrote: >>> The internal built portals would be the ones that could be fixed, as >>> they might have way to fix things. The 3rd party portals provided by >>> telecom, isps etc are the ones which are impossible to fix, as hote= ls >>> most likely have multiyear contracts with them, and those 3rd party >>> operators have no interest of fixing anything, and if they can show >>> you few more ads while you log in, they might get more money. >>> So as the owners of the network do not care, I think this is problem >>> that we (the IETF) cannot fix=E2=80=A6 > Other forums are working on the problem: > https://www.wi-fi.org/passpoint-release-2-operator-best-practices-for= -aaa-interface-deployment-v200 > (sorry =E2=80=A6 not a free spec :-( Thanks for the pointer. will it be public once finished? If not, then they are completely wasting their time, as it just won't get implemented, because nobody will know it exists.=20 Does wi-fi.org think they have some actual customers involved who will be able to drive adoption? =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVGqZ0oCLcPvd0N1lAQLRdgf/WjdljV5L6YcyFTQByge8rGelHwQXzP0y Me1fm4xEqtpRUJdTXJBbN6FjM51tX0EdS1umYg5xSbNWXiRnnhmrcvTj+zKHACTP W3Mk1yFiqQuseGc92EDTCZWlnbr5bVCOfR+gMT4vokEJ9Txv26WLzE9WCig9wYxr R22uLLxVl19B5Mq7Xw4U+zathphhrf7RzHCH06lreF7Ui4lb/ewVwQlwy2n3YBAc HquVxC9H3i+uJJBokRcCvcMMYLuFWViRYhszL35gBGHnGJTRNfH/A2mioKa1vk1I h0aa4jNVpKY4hnoE6hGtZfG1fFkgERTODhV2tviZnSWHXkJJBfZNHQ== =o1gQ -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Nov 18 08:40:06 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6181A8798 for ; Mon, 17 Nov 2014 10:32:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1npOJ3hslUC for ; Mon, 17 Nov 2014 10:32:54 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D147D1A8792 for ; Mon, 17 Nov 2014 10:32:54 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0F20F20012; Mon, 17 Nov 2014 13:35:19 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 28454637F5; Mon, 17 Nov 2014 13:32:54 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 1198763745; Mon, 17 Nov 2014 13:32:54 -0500 (EST) From: Michael Richardson To: Yoav Nir In-Reply-To: References: <22000.1416115306@sandelman.ca> <21609.46296.642010.426288@fireball.kivinen.iki.fi> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/yjDndDVSZJ6-rR0-RYT0r_QtGt8 X-Mailman-Approved-At: Tue, 18 Nov 2014 08:40:02 -0800 Cc: secauth@ietf.org, 'Tero Kivinen' Subject: Re: [Secauth] side meeting -- portal BCP X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 18:32:57 -0000 Yoav Nir wrote: > As another anecdote, I take the train to work every day. It's the same > physical train every morning, and I sit in the same car, and yet the > train wifi shows me the captive portal every day. Why? Because as soon > as I click "Enter", it shows a different web page with all their > notices ("the train from X to Y won't be running from 22-Nov at 20:00 > until 24-Nov at 6:00") and their timetable web app. It's not a pleasant > experience, but they really want me to see that page, and providing a > technical means to not show this page wouldn't help. I'm thinking about providing them a technical means by which to tell you about the page; you then could look at it on the machine tath is actually able to show it to you... > They're foiled anyway by the operating system on both my laptop and my > phone. As soon as the OS detects that it has "the Internet", the > special captive portal window disappears, so I manage to see the I'm curious about this part. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From nobody Tue Nov 18 10:43:10 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F4D1A6F12 for ; Tue, 18 Nov 2014 10:43:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DvacqQxScYNq for ; Tue, 18 Nov 2014 10:43:07 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF84E1A1B13 for ; Tue, 18 Nov 2014 10:42:18 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 627A12009E; Tue, 18 Nov 2014 13:44:42 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id C0E39637F5; Tue, 18 Nov 2014 13:42:13 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id AFD4B637EA; Tue, 18 Nov 2014 13:42:13 -0500 (EST) From: Michael Richardson To: Yoav Nir In-Reply-To: References: <22000.1416115306@sandelman.ca> <21609.46296.642010.426288@fireball.kivinen.iki.fi> <7444.1416249174@sandelman.ca> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/bfUIrCIqkqyV8jXnvrdBGElT6EY Cc: secauth@ietf.org, 'Tero Kivinen' Subject: Re: [Secauth] side meeting -- portal BCP X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 18:43:09 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Yoav Nir wrote: > Macs, phones, Some VPN clients, they all use a similar mechanism. Android 4.0 seems to do the same thing, but it only puts up a notify that o= ne might want to login, it doesn't do the continuing monitoring, and proceedin= g. > Macs it takes a few seconds so I can still see the notices and if I c= lick > anything there it stays. On my phone (not an Apple product) it disapp= ears > immediately. People have talked about making it a standard way... =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVGuTA4CLcPvd0N1lAQLCWQgAr2ZqLOWAI5/DldisxWBtznZFxQyFrIPF 3jgycUrndtCfnWynbPyy//fEWoCBwDs6zhE/Bb9QOXHmN2YWZ7iQjCCYgQep1r/v tqC0GHg2NUwQpEBXHsIEvzNMBfMv7uhFfpcLirDvGi57hjOqRstZkq8yfdU0ktYl wgYm3bIbxp5DWSs027sxxA1kOv6uNySSq3/Judv9ERhyU5kGNY8m25Knu9j1p/3S rmkVCsXextjZZEQ6DbrrJHTEGxb4LIBao/0I652oDl6W3ycxDk78G/VCAx5H8y0U 2KOjImb7ykCkGdxYvOxN8nBrRpbtWgWC4b3aYw1hOVi4utH2AW7FLw== =+3gP -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Nov 20 05:52:21 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1B7D1A0172 for ; Thu, 20 Nov 2014 05:52:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.184 X-Spam-Level: X-Spam-Status: No, score=0.184 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.594, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XthcoIea5NSB for ; Thu, 20 Nov 2014 05:52:13 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E44F51A0161 for ; Thu, 20 Nov 2014 05:52:12 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id sAKDqApW024832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 20 Nov 2014 15:52:10 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id sAKDq9S2008343; Thu, 20 Nov 2014 15:52:09 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21613.61961.101436.570547@fireball.kivinen.iki.fi> Date: Thu, 20 Nov 2014 15:52:09 +0200 From: Tero Kivinen To: Michael Richardson In-Reply-To: <7423.1416249042@sandelman.ca> References: <22000.1416115306@sandelman.ca> <21609.46296.642010.426288@fireball.kivinen.iki.fi> <7423.1416249042@sandelman.ca> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 9 min X-Total-Time: 9 min Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/LsvPeHTlb-ULpR2CMJYJ0lisLkY Cc: Crocker Steve , secauth@ietf.org, Dan York Subject: Re: [Secauth] side meeting -- portal BCP X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 13:52:17 -0000 Michael Richardson writes: > > So the hotel had few dozen useless wifi access points around the hotel, > > and only one working that was put there most likely without approval, > > that actually worked... Unfortunately that meant we had to sit in the > > hotel lobby quite close to the reception... > > So the hotel has a contract and managemenet problem, and somehow this is not > affecting the hotel's ability to get business... did you consider just > unplugging the broken system for them? Yes. Or actually we asked if we could go and see if we can fix it, but they didn't give us permission... :-) It is also funny to see how different networks are in different countries. In Argentina every single bar, restaurant, hotel etc had free wifi, but every single one were always encrypted using WEP or similar, with very weak fixed password (hotel2013, internet2013, restaurantname, restaurantname2013 etc). Usually you tried the name of place, name of place + year or just internet / internet + year, and if none of those worked, then you checked the password from the restaurant menu, or the card in wall / table. They didn't have captive protals or any of this click here to continue. Then on some other countries all hotels seem to have this similar system printing one time username / password on thermal paper, and those codes are valid for 30/60/120 minutes from first use for one device, and they must be entered to the web captive portal when you start to use them. Usually they are free, so you can go and ask as many as you like, but on some other countries they cost few dollars each... All of this is just pointing out that it does not seem to be what hotels / restaurants etc are wanting, but what have been sold to them by either the regulations or by the consulting firms / ISPs in that region, and the hotels / restaurants do not have real control over whats get installed... If the only thing that is offered to you is the ISP xxx's username + password based system, that is only thing you can get unless you are have enough knowledge to set up the system completely by yourself. -- kivinen@iki.fi From nobody Thu Nov 20 09:38:38 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4571A1BC8 for ; Thu, 20 Nov 2014 09:38:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXAlMNMRa-PG for ; Thu, 20 Nov 2014 09:38:34 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C25A1A1AE3 for ; Thu, 20 Nov 2014 09:38:34 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9DA242002A; Thu, 20 Nov 2014 12:41:08 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 56B29637F5; Thu, 20 Nov 2014 12:38:33 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 425FD637EA; Thu, 20 Nov 2014 12:38:33 -0500 (EST) From: Michael Richardson To: Tero Kivinen In-Reply-To: <21613.61961.101436.570547@fireball.kivinen.iki.fi> References: <22000.1416115306@sandelman.ca> <21609.46296.642010.426288@fireball.kivinen.iki.fi> <7423.1416249042@sandelman.ca> <21613.61961.101436.570547@fireball.kivinen.iki.fi> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/YGr4JR5wU-Q23jWPYMFZ_ufmOPw Cc: Crocker Steve , secauth@ietf.org, Dan York Subject: Re: [Secauth] side meeting -- portal BCP X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 17:38:36 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Tero Kivinen wrote: > In Argentina every single bar, restaurant, hotel etc had free wifi, > but every single one were always encrypted using WEP or similar, with > very weak fixed password (hotel2013, internet2013, restaurantname, > restaurantname2013 etc). Usually you tried the name of place, name of > place + year or just internet / internet + year, and if none of those > worked, then you checked the password from the restaurant menu, or the > card in wall / table. So basically just enough security to say that they didn't have an open AP, could it be that having an open AP in Argentina is against some law? > Then on some other countries all hotels seem to have this similar > system printing one time username / password on thermal paper, and > those codes are valid for 30/60/120 minutes from first use for one > device, and they must be entered to the web captive portal when you > start to use them. Usually they are free, so you can go and ask as > many as you like, but on some other countries they cost few dollars > each... I had the same experience in many places. My take is that management is anxious about being able to get rid of undesireables from their front lobby, etc. while the front desk staff mostly do not care. One coffee shop chain = in Ottawa (Bridgehead, locally owned) has some shops with the printer system a= nd some are just open+click-through. For awhile some of them would decline to hand out usernames when the place was busy, but that seems to have declined. I think it's a quesiton of control. At the IETF level, I sure would like to have a DHCP option that told me the URL at which I need to authenticate. I'd like it if the initial lease was rather short (10 minutes), and when I renew, it would tell me how long I ha= ve in my ticket/username/etc. left. One could as far as BCP's what the right ICMP unreachable to return before login and/or after time is up. This is particularly import for non-HTTP applications that run in the background. > All of this is just pointing out that it does not seem to be what > hotels / restaurants etc are wanting, but what have been sold to them > by either the regulations or by the consulting firms / ISPs in that It would be lovely if we could capture what they actually want, but I don't see a way to get the right people engaged in the conversation. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVG4nE4CLcPvd0N1lAQLoVggAod5iiU+f/YlZtk0ExVsmNcYAPEzDfa3E LOgekrxOco+XmxTMzxBBGVjASRsB8wsyZLXKMGKFIl65xLHQq6xUTTkarUNeOMoa yKblOXAyTK/7w76UkcyIng7Hy7E5JWnJhlW8TU9GmfmpVNFjUkNyveiy3835YQcs EG2aPYebU02u+q9Pqn7MaNycoJ0cPfFjzufky8AJbMsxeZhu5aVYIvOsNWrrqAzO jiCfb58ZBRVX1Zy6Xcyt+CaW+MssWgBXOUryNMjhDt4sPC/5Fvn87sbuIehAjiRy 0AjPDtUVjK/fq4vQB/QAa3fddPTjpUd6HPQl73MO5liZZT+LEourLg== =1+93 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Nov 20 10:11:41 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 972E41A1AB4 for ; Thu, 20 Nov 2014 10:11:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVxMhsVceKEX for ; Thu, 20 Nov 2014 10:11:26 -0800 (PST) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 731801A1AD5 for ; Thu, 20 Nov 2014 10:11:26 -0800 (PST) Received: by mail-qc0-f181.google.com with SMTP id m20so2505984qcx.40 for ; Thu, 20 Nov 2014 10:11:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:mime-version:subject :date:message-id:references:cc:in-reply-to:to; bh=K//IwRBMHK0L1MWzr+o5NQeZa7P0YaGQ+WdMsDR0mOU=; b=Z3b64OrweK7D5/jt//+Ajjz29szVhERt906/8YDxxAalNa/MFxYHp8LqYS+zrSGP+7 O7nI+H1yLCNEgbGfNFOHwE8cs+lp/RIjZo8ahEr+zTZgpPTAigRDsZIAoX21HjjQg+Hf heFoLwsbaB8yuKn3BBgYvsuQv35BEMTjknqSWyHMcv23VvqrMlDftqI6RuJuoIWU5CXc u0PDgVluj8Cbtcffca5NdBVPUoLumElpq/471a5f+V3ICjBPlKNJNczTdlaDl6L7EBzY xsz9+OWTC//CYE42DmHluB6o4lAu2TXt8QLypk4yw/EzdoqWqzInGEbUaOWcWjk6h+0z yj6A== X-Received: by 10.224.160.69 with SMTP id m5mr61128010qax.34.1416507085600; Thu, 20 Nov 2014 10:11:25 -0800 (PST) Received: from [10.114.32.175] (mobile-166-171-186-068.mycingular.net. [166.171.186.68]) by mx.google.com with ESMTPSA id e34sm2572593qgd.35.2014.11.20.10.11.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Nov 2014 10:11:23 -0800 (PST) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Date: Thu, 20 Nov 2014 09:14:08 -0600 Message-Id: <55B9CAE0-4CCB-440A-A987-7C692D44B799@gmail.com> References: <22000.1416115306@sandelman.ca> <21609.46296.642010.426288@fireball.kivinen.iki.fi> <7423.1416249042@sandelman.ca> <9878.1416272341@sandelman.ca> In-Reply-To: <9878.1416272341@sandelman.ca> To: Michael Richardson X-Mailer: iPhone Mail (11D257) Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/v0rQlAt5JES1kCS8sFZBYNzEh7k Cc: Dan York , Crocker Steve , "secauth@ietf.org" , Paul Lambert Subject: Re: [Secauth] side meeting -- portal BCP X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 18:11:37 -0000 I'm responding in air, so I may be a bit back in the thread once this sends,= but my thoughts on this have not changed from before the Hawaii IETF. Inli= ne Sent from my iPhone > On Nov 17, 2014, at 6:59 PM, Michael Richardson wr= ote: >=20 >=20 > Paul Lambert wrote: >>>> The internal built portals would be the ones that could be fixed, as >>>> they might have way to fix things. The 3rd party portals provided by >>>> telecom, isps etc are the ones which are impossible to fix, as hotels >>>> most likely have multiyear contracts with them, and those 3rd party >>>> operators have no interest of fixing anything, and if they can show >>>> you few more ads while you log in, they might get more money. >=20 >>>> So as the owners of the network do not care, I think this is problem >>>> that we (the IETF) cannot fix=E2=80=A6 >=20 >> Other forums are working on the problem: >> https://www.wi-fi.org/passpoint-release-2-operator-best-practices-for-aaa= -interface-deployment-v200 >> (sorry =E2=80=A6 not a free spec :-( >=20 > Thanks for the pointer. >=20 > will it be public once finished? If not, then they are completely wasting= > their time, as it just won't get implemented, because nobody will know it > exists.=20 >=20 > Does wi-fi.org think they have some actual customers involved who will be > able to drive adoption? Exactly. While this would be nice for users, providers of wifi access are n= ot motivated to enable the seamless access described. I'd need to see inter= ested implementers come to the table before we could charter something. Oth= erwise, an experimental, possibly ISE draft may be the only feasible option a= s this could just be a waste of time to solve. =20 Once you setup access points, you can connect in the future without trouble u= nless re-authentication is required to pay a fee, register, etc. Best regards, Kathleen=20 >=20 > --=20 > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > _______________________________________________ > Secauth mailing list > Secauth@ietf.org > https://www.ietf.org/mailman/listinfo/secauth From nobody Thu Nov 20 11:50:58 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF681ABD39 for ; Thu, 20 Nov 2014 11:50:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.206 X-Spam-Level: X-Spam-Status: No, score=0.206 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwkETVcGNkfP for ; Thu, 20 Nov 2014 11:50:44 -0800 (PST) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E91791ABD3C for ; Thu, 20 Nov 2014 11:50:43 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 9675525CA21C for ; Thu, 20 Nov 2014 19:50:41 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9_HJ8GrifGz for ; Thu, 20 Nov 2014 20:50:12 +0100 (CET) Received: from kopoli (unknown [95.235.216.24]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id CB34525CA067 for ; Thu, 20 Nov 2014 20:50:11 +0100 (CET) From: "Hosnieh Rafiee" To: Date: Thu, 20 Nov 2014 20:50:07 +0100 Message-ID: <009a01d004fb$316b1c70$94415550$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdAE+y19wjJnQQCZRRqcEZFZYtag1g== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/rmb5KgPoWYPHFEuzDiTyms0uBcM Subject: [Secauth] Summary of side meeting X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 19:50:50 -0000 All, Thanks again for attending the side meeting at IETF and sorry for my delay responding to the thread. I am travelling with limited internet access... There were 8 onside attendees in the side meeting . I first explained the differences of secauth with current WGs or recent BoFs. I also compared this work with some of RGs. Then I explained some of secauth usecases and asked others to share their opinions. According to the discussion, as also Michael summarized it, almost all folks agreed on the problem explained in the one of the use cases. However, how to handle that problem can have different aspects. The use case was simply about seamless connectivity of IoT especially the use case with hotspot. As I explained during my presentation, this use case is already implemented in mobile networks with the same operator but not with hotspots and different mobile operators. Maybe before we use SDN approach it was not easy to handle such use case because of complexity for terms of agreements and sharing authentication/authorization information among hotspots but I do think that controlling the hotspots via a centralized controller will simplify the policy handling. This is, of course, the extended version of Alex's idea. I think that this extension would also answer concerns that raised by Kathleen. Please share your opnion if you think this is not possible or if you think we have to handle this in other way. Again thanks for Michael, Alex, Kathleen, Tero, Yoav and Paul who shared their opinions. Thank you, Best, Hosnieh P.S. I have limited access to internet due to travelling From nobody Fri Nov 21 05:27:54 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAF71AD4A6 for ; Fri, 21 Nov 2014 05:27:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.715 X-Spam-Level: X-Spam-Status: No, score=-1.715 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWgIamRdOB9N for ; Fri, 21 Nov 2014 05:27:45 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 439A41A023E for ; Fri, 21 Nov 2014 05:25:36 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id sALDPWmp004842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 21 Nov 2014 15:25:32 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id sALDPV96000897; Fri, 21 Nov 2014 15:25:31 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21615.15691.743041.887655@fireball.kivinen.iki.fi> Date: Fri, 21 Nov 2014 15:25:31 +0200 From: Tero Kivinen To: Michael Richardson In-Reply-To: <30758.1416505113@sandelman.ca> References: <22000.1416115306@sandelman.ca> <21609.46296.642010.426288@fireball.kivinen.iki.fi> <7423.1416249042@sandelman.ca> <21613.61961.101436.570547@fireball.kivinen.iki.fi> <30758.1416505113@sandelman.ca> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 5 min X-Total-Time: 4 min Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/_wNKbYFkbHFws87EONgwJ_5Hcdo Cc: Crocker Steve , secauth@ietf.org, Dan York Subject: Re: [Secauth] side meeting -- portal BCP X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 13:27:52 -0000 Michael Richardson writes: > So basically just enough security to say that they didn't have an open AP, > could it be that having an open AP in Argentina is against some law? Could be. At least I know that in some cases in Finland some people have said that the owner could be liable for the traffic originating from the open access point, but someone using their encrypted access point without their knowledge (regardless how easy the password is) would be considered as hacking, thus they are not liable for the traffic. But I think that is actually not true even if someone claims so. > At the IETF level, I sure would like to have a DHCP option that told me the > URL at which I need to authenticate. I'd like it if the initial lease was > rather short (10 minutes), and when I renew, it would tell me how long I have > in my ticket/username/etc. left. One could as far as BCP's what the right > ICMP unreachable to return before login and/or after time is up. > This is particularly import for non-HTTP applications that run in the > background. I quite often have the problem that my web browser have about 2-3 dozen tabs open, and if I need to start my web browser to do login in location where they redirect all urls to login page, I will be really angry, as all my tabs are suddenly rendered unusable... Thats why I do have separate browser installed just in case I need to login before I can start my real browser... :-) -- kivinen@iki.fi From nobody Fri Nov 21 11:20:36 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9129A1A1A36 for ; Fri, 21 Nov 2014 11:20:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ac-S-Mz62b_d for ; Fri, 21 Nov 2014 11:20:28 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17EFA1A1A24 for ; Fri, 21 Nov 2014 11:20:26 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 90223203AB; Fri, 21 Nov 2014 14:23:02 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 8AC77637F5; Fri, 21 Nov 2014 14:20:23 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 69131637EA; Fri, 21 Nov 2014 14:20:23 -0500 (EST) From: Michael Richardson To: Tero Kivinen In-Reply-To: <21615.15691.743041.887655@fireball.kivinen.iki.fi> References: <22000.1416115306@sandelman.ca> <21609.46296.642010.426288@fireball.kivinen.iki.fi> <7423.1416249042@sandelman.ca> <21613.61961.101436.570547@fireball.kivinen.iki.fi> <30758.1416505113@sandelman.ca> <21615.15691.743041.887655@fireball.kivinen.iki.fi> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/40O_I31l8oAjakGqemwoZ9jJ86o Cc: Crocker Steve , secauth@ietf.org, Dan York Subject: Re: [Secauth] side meeting -- portal BCP X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 19:20:32 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Tero Kivinen wrote: > I quite often have the problem that my web browser have about 2-3 > dozen tabs open, and if I need to start my web browser to do login in > location where they redirect all urls to login page, I will be really > angry, as all my tabs are suddenly rendered unusable... > Thats why I do have separate browser installed just in case I need to > login before I can start my real browser... :-) Yes, I do *exactly* the same thing. And I always attempt access to some reliable site that I don't care about... because likely my DNS will get poisoned too. The real problem is that once the site I choose turns on DNSSEC, instead of just being poisoned, I will find that it just doesn't load. Many portals are smarter and just hijack port 80, which will also go away as a method. That's why I'm CC'ing Steve Crocker and Dan York: it's about DNSSEC deployment hurdles. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVG+QdICLcPvd0N1lAQL4CQf/WbvBYxIsS6RVI0byF+YMEX8XftHJMVbM CbgC+C8ZzIf8Ix2278Fw1JOdOA+5Ki2d22HSA2cVhb68FGRjMTG4hwc2sr3DC3Up zcX556EJV69/2S/vKiWh47uL0zWu4iAv4SIydqbNy5gZzcu5hLfk2eizTShG5WR2 iDBmS0MXowa0GKAtTmyPj/uJdCpz9C4seV98vnUYP/MZRn69ca6DyoSLazsOM4yn bf3BFzmwhqh6PtfzCLiFsmlMiLD1ewtP7nMVArNcQ18LeA4jWf3pVuImFQgcD1ib PUBbIejT9kAk6yBFXthG8p3WPNWfCr3U8d8nhbP24IyXR5q6cnVb/w== =GMpB -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Nov 24 02:08:00 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3E41A1BF6 for ; Mon, 24 Nov 2014 02:07:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kG_ExVwEwVw2 for ; Mon, 24 Nov 2014 02:07:57 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21C271A1AF1 for ; Mon, 24 Nov 2014 02:07:56 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id sAOA7sk2011716 for ; Mon, 24 Nov 2014 11:07:54 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A3BD2206B6E for ; Mon, 24 Nov 2014 11:08:30 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 916622069B4 for ; Mon, 24 Nov 2014 11:08:30 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id sAOA7UUU025414 for ; Mon, 24 Nov 2014 11:07:54 +0100 Message-ID: <54730362.5000503@gmail.com> Date: Mon, 24 Nov 2014 11:07:30 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: secauth@ietf.org References: <22000.1416115306@sandelman.ca> <21609.46296.642010.426288@fireball.kivinen.iki.fi> <7423.1416249042@sandelman.ca> <21613.61961.101436.570547@fireball.kivinen.iki.fi> <30758.1416505113@sandelman.ca> <21615.15691.743041.887655@fireball.kivinen.iki.fi> In-Reply-To: <21615.15691.743041.887655@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/rnJTz5bvkHGGFEDPle99Stnm-kk Subject: Re: [Secauth] side meeting -- portal BCP X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 10:07:59 -0000 Le 21/11/2014 14:25, Tero Kivinen a écrit : > Michael Richardson writes: [...] >> At the IETF level, I sure would like to have a DHCP option that told me the >> URL at which I need to authenticate. It sounds feasible. I guess DHCP enhancements may be considered ok by portal manufacturers. It can offer hints to the automatisation running in the client. Alex I'd like it if the initial lease was >> rather short (10 minutes), and when I renew, it would tell me how long I have >> in my ticket/username/etc. left. One could as far as BCP's what the right >> ICMP unreachable to return before login and/or after time is up. >> This is particularly import for non-HTTP applications that run in the >> background. > > I quite often have the problem that my web browser have about 2-3 > dozen tabs open, and if I need to start my web browser to do login in > location where they redirect all urls to login page, I will be really > angry, as all my tabs are suddenly rendered unusable... > > Thats why I do have separate browser installed just in case I need to > login before I can start my real browser... :-) > From nobody Wed Nov 26 08:01:12 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78F601A026E for ; Wed, 26 Nov 2014 08:01:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9R3Hm6IRizHs for ; Wed, 26 Nov 2014 08:01:06 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF2771A026A for ; Wed, 26 Nov 2014 08:01:05 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BPG42164; Wed, 26 Nov 2014 16:01:03 +0000 (GMT) Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml406-hub.china.huawei.com ([10.201.5.243]) with mapi id 14.03.0158.001; Wed, 26 Nov 2014 16:00:57 +0000 From: Hosnieh Rafiee To: "secauth@ietf.org" Thread-Topic: Can we also be protected against such attacks? Thread-Index: AdAJkimCrxm7yXjaSqSrT77Yg3foNg== Date: Wed, 26 Nov 2014 16:00:56 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A78C6B@lhreml513-mbb.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.91] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/x3VHae1CFAPGtjMkswPksZv9T-4 Subject: [Secauth] Can we also be protected against such attacks? X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 16:01:11 -0000 Hi Folks, Before start reading the old threads and answering them, I came across this= article and found it interesting to share.=20 =20 When we want to think of open authentication domains, does it involve more = risk with such scenarios (in this article)?? Best, Hosnieh From nobody Wed Nov 26 09:08:05 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD7B1A0149 for ; Wed, 26 Nov 2014 09:08:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpoQoYg1-zVk for ; Wed, 26 Nov 2014 09:07:57 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 453011A064C for ; Wed, 26 Nov 2014 09:07:41 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id sAQH7cjv008916 for ; Wed, 26 Nov 2014 18:07:38 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6FE55200E17 for ; Wed, 26 Nov 2014 18:08:18 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5C92520C6A0 for ; Wed, 26 Nov 2014 18:08:18 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id sAQH7MDh023058 for ; Wed, 26 Nov 2014 18:07:38 +0100 Message-ID: <547608CA.7070500@gmail.com> Date: Wed, 26 Nov 2014 18:07:22 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: secauth@ietf.org References: <814D0BFB77D95844A01CA29B44CBF8A7A78C6B@lhreml513-mbb.china.huawei.com> In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A7A78C6B@lhreml513-mbb.china.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/r_LOwuWNwIv1Z5skV2OSmFzq1dI Subject: Re: [Secauth] Can we also be protected against such attacks? X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 17:08:03 -0000 Le 26/11/2014 17:00, Hosnieh Rafiee a écrit : > Hi Folks, > > Before start reading the old threads and answering them, I came > across this article and found it interesting to share. > > > > When we want to think of open authentication domains, does it involve > more risk with such scenarios (in this article)?? Hi, When I read this article I wonder when was the last time I clicked on a linkedin button, whether Symantec covers the Regin risk, and try to remember whether this person in Belgium invented the AES candidate or is it somebody else. But, what is an open authentication domain? Alex > > Best, Hosnieh > > _______________________________________________ Secauth mailing list > Secauth@ietf.org https://www.ietf.org/mailman/listinfo/secauth > > From nobody Thu Nov 27 01:29:31 2014 Return-Path: X-Original-To: secauth@ietfa.amsl.com Delivered-To: secauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6374F1A1B4F for ; Thu, 27 Nov 2014 01:29:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mckufjXmGl6O for ; Thu, 27 Nov 2014 01:29:28 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2669E1A00E0 for ; Thu, 27 Nov 2014 01:29:28 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BPH15150; Thu, 27 Nov 2014 09:29:26 +0000 (GMT) Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml403-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Thu, 27 Nov 2014 09:29:25 +0000 From: Hosnieh Rafiee To: "secauth@ietf.org" Thread-Topic: [Secauth] Can we also be protected against such attacks? Thread-Index: AdAJkimCrxm7yXjaSqSrT77Yg3foNgACUfUAAB9tGwA= Date: Thu, 27 Nov 2014 09:29:25 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A79E92@lhreml513-mbb.china.huawei.com> References: <814D0BFB77D95844A01CA29B44CBF8A7A78C6B@lhreml513-mbb.china.huawei.com> <547608CA.7070500@gmail.com> In-Reply-To: <547608CA.7070500@gmail.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.91] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/7bDRLKZlyrdI3fXC7nyQkdtbhC4 Subject: Re: [Secauth] Can we also be protected against such attacks? X-BeenThere: secauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 09:29:30 -0000 Hi Alex, >=20 > When I read this article I wonder when was the last time I clicked on a > linkedin button, whether Symantec covers the Regin risk, and try to > remember whether this person in Belgium invented the AES candidate or > is it somebody else. >=20 > But, what is an open authentication domain? By considering the case where each hotspot might be under the control of di= fferent administrative domains but they would need to open their service to= end-users, then such phrase might cover the meaning or I might use a bad p= hrase for that. My main message is that, I guess with openness (that we cal= l it automation of interdomain and crossdomain authentication and authoriza= tion), the risk of similar attacks might increase since an infected node in= a new network might increase a risk of other nodes' infection in its visit= ed network.=20 There are some thoughts about this scenario The use case for secauth that I am thinking about is not only a simple cros= s domain authentication but also considering a case where the management/co= ntrolling and interfaces of the physical devices are somewhere on datacente= rs except the physical layer located, e.g., at the hotel or airport (physic= al hotspot). IMO, This is actually where we are going and there is good eff= orts by different groups of manufactures/vendors. I guess this would change= internet architectures since the administrative domains are virtually cont= rolled.=20 One example is that, there is one operator who offered its service to hotel= x, y and z. this is true that the customers can control their own devices = via their user interface placed somewhere on cloud but operator has higher = privilege on this service and can set this inter domain authentication agre= ement for all these hotels by easily asking them whether they want to suppo= rt this feature (because of these advantages), if yes, they can set it as a= default settings of their customers (hotel x, hotel y, hotel z) Now, we want to extend this to different operators (cross domain authentica= tion). So, the client first time register with first hotel and in each new = hotel, the automatically sent its request with its token (that might be kep= t somewhere on cloud that is accessible to all operators) controller and ha= ndled in a centralized controller/s. We need a way of communication between= controllers from different vendors so that this cross domain authenticatio= n can happen. In other word, in my opinion the focus of secauth should not = be only end user who request this service but vendors who can enable this s= ervice. In other word, we need transparency to offer such service to end-us= ers. I hope I could clearly explain my thoughts. Any thoughts? Thanks, Best, Hosnieh Therefore, it is not only=20 1- =20