Re: [Anima] BRSKI over 802.11
Hi, Catching up on this threadit is not clear to me that we can prescribe an "SSID" as there can be a couple of solutions And for that level, I believe is out of scope for IETF; that said, there are a couple of means to do this w/in 802.11 the cleanest one is using the service/capability advertisements from 802.11u.The SSID is really not sufficient on the 802.11 as we've build agility there as well to denote the types of authentication and key management that we would also want to retain (agility to) as we do this ala BRSKI. But, I break it down to "discovery" as perhaps being an 802.11 scope and thereafter we can discuss work relevant here. That said, for the actual enrollment would very well be suited to be in the EAP realm as 802.11 already prescribes to using that model within 802.1X. Hopefully that makes sense, Nancy On 2/12/18, 1:56 AM, "Anima on behalf of Eliot Lear" wrote: Hi Bing, I think you've got it down, but I want to stress that these are early days, and I could, perhaps easily, be convinced to go another way. I think Michael is trying to do that ;-) I think the question is this: in a WiFi environment how can the device know which network to connect with in the first place, and how does it then send packets to complete the BRSKI flow? As a difficult use case, consider a business in an office building on the 10th floor in New York City or London, where you might hear 2 dozen different networks. Eliot On 11.02.18 10:16, Liubing (Leo) wrote: > Hi Michael, Eliot and all, > > A clarification question: it sounds like there are two approaches proposed, not sure I understood it correctly: > > Michael's proposal: there is a dedicated SSID, say "Anima", it is enabled by default, and there is no security. And that SSID can only do BRSKI, no other services permitted (just like the http portal authentication). After getting the certificate, then certificate-based EAP could be run to do the 802.1x authentication; or maybe they just negotiated a key for WPA2. In this case, the BRSKI just works as the bootstrap of WiFi. > > Eliot's proposal: we'll have a new EAP method, say "EAP-BRSKI", just treat BRSKI as an option encapsulated in EAP protocol, under the WiFi access framework. > > Michael and Eliot: did I get you correctly? > > B.R. > Bing > >> -Original Message- >> From: Anima [mailto:anima-boun...@ietf.org] On Behalf Of Eliot Lear >> Sent: Thursday, February 08, 2018 5:51 PM >> To: Artur Hecker ; anima@ietf.org >> Subject: Re: [Anima] BRSKI over 802.11 >> >> Artur, >> >> I suspect much – but not all – of this could be addressed in EAP. >> >> Eliot >> >> >> On 08.02.18 10:24, Artur Hecker wrote: >>> Hi Michael >>> >>> >>> Sorry, maybe I misunderstood the intention. Is your intention to make it >> "standard" or just to make a demonstration? If the latter, then it's OK. It's the >> first that I simply doubt it will work. >>> I am not claiming that there are better means to do that, let alone that what >> you proposed makes no sense. I actually said that this makes sense. I just think >> that we enter the realms of 802.1 and 802.11 at the same time and have no >> authority there. >>> It has indeed nothing to do with Wireless access points. Any STA (802.11) and >> any supplicant (802.1X) is subject to standardization and regulation of the bodies >> of IEEE, in any mode of operation. WPS should not be limited to any Access >> Point presence, since it supports WiFi Direct. I agree, the supported methods are >> rudimentary. If I remember correctly, something like PIN, the push button you >> mentioned, NFC and USB. >>> I guess, a possibility would be to specify an additional ANIMA/ACP/BRSKI >> method for WPS, why not. All I am saying is that we probably need to do it there, >> as any try to do it in the ANIMA WG would require specific 802.11 modes and >> specific 802.1X functions/behaviours, which I am not sure we can dictate to >> have. >>> >>> Regards >>> artur >>> >>> >>> -Original Message- From: Michael Richardson [mailto:mcr+i...@sandelman.ca] Sent: 07 February 2018 20:07 To: Artur Hecker Cc: anima@ietf.org Subject: Re: [Anima] BRSKI over 802.11 Artur Hecker wrote: > Hi Michael, > My opinion: I don't think understood the question :-) 1) It's not about Wireless Access Points, so all of the Wifi Alliance, etc. talk makes no sense to me. There can be no access points until they have been configured. It's possible that there might NEVER been any access points, because the operat
Re: [Anima] BRSKI over 802.11
Liubing (Leo) wrote: > A clarification question: it sounds like there are two approaches > proposed, not sure I understood it correctly: (1) > Michael's proposal: there is a dedicated SSID, say "Anima", it is > enabled by default, and there is no security. And that SSID can only do > BRSKI, no other services permitted (just like the http portal > authentication). (2) > After getting the certificate, then certificate-based > EAP could be run to do the 802.1x authentication; or maybe they just > negotiated a key for WPA2. In this case, the BRSKI just works as the > bootstrap of WiFi. (3) > Eliot's proposal: we'll have a new EAP method, say "EAP-BRSKI", just > treat BRSKI as an option encapsulated in EAP protocol, under the WiFi > access framework. > Michael and Eliot: did I get you correctly? Yes, I think you described that exactly correctly. I've put some numbers in to help split up the thoughts. The decidcated SSID would be in IBSS mode, and it could use WPA2-Enterprise with a known username/password (like we do for the IETF SSID), which would get per-station keying material.There is also "Wifi Direct", defined by the Wi-fi Alliance, which also might make sense and might provide similar L2 keying. There would be no DHCPv4 or DHCPv6 or RAs on the link, as it would all just be LL. The only traffic would be GRASP M_FLOODs (from the DULL). There is a (4) - bring up an ACP across this dedicated SSID. This is not mutually exclusive with (2). If one does (3), then I guessone can do (2) to get connectivity. (3) still has to define some kind of SSID on which this new 1x method will be seen. It could be that we can do something with 802.11 beacons to indicate the capability and not have to pick a particular SSID name on which to "rendezvous" -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] Document Action: 'Using Autonomic Control Plane for Stable Connectivity of Network OAM' to Informational RFC (draft-ietf-anima-stable-connectivity-10.txt)
The IESG has approved the following document: - 'Using Autonomic Control Plane for Stable Connectivity of Network OAM' (draft-ietf-anima-stable-connectivity-10.txt) as Informational RFC This document is the product of the Autonomic Networking Integrated Model and Approach Working Group. The IESG contact persons are Warren Kumari, Benoit Claise and Terry Manderson. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-stable-connectivity/ Technical Summary This document describes how to integrate OAM processes with the autonomic control plane (ACP) in Autonomic Networks (AN) in order to provide stable and secure connectivity for those OAM processes. Working Group Summary This document was called draft-eckert-anima-stable-connectivity prior to its adoption. There was unanimous support for it in favor of adoption and none against, so this document was adopted in December 2015. There was interest in this work posts since its adoption. There was never any opposition for this work. This document went through a relevant long document development period (12 months for individual document period, 22 month for WG document period). It has been reviewed well. Document Quality This document went through multiple reviews by multiple participants. So far, there is no existing implementations. Personnel Sheng Jiang is the document shepherd. Terry Manderson is the responsible AD. ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] Protocol Action: 'Voucher Profile for Bootstrapping Protocols' to Proposed Standard (draft-ietf-anima-voucher-07.txt)
The IESG has approved the following document: - 'Voucher Profile for Bootstrapping Protocols' (draft-ietf-anima-voucher-07.txt) as Proposed Standard This document is the product of the Autonomic Networking Integrated Model and Approach Working Group. The IESG contact persons are Warren Kumari, Benoit Claise and Terry Manderson. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-voucher/ Technical Summary This document defines a strategy to securely assign a pledge to an owner, using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher". This document only defines the voucher artifact, leaving it to other documents to describe specialized protocols for accessing it. Working Group Summary This document was called draft-kwatsen-anima-voucher prior to its adoption. There was unanimous support for it in favor of adoption and none against), so this document was adopted in January, 2017, as a accompanying document along with another ANIMA WG document draft-ietf-anima-bootstrapping-keyinfra, which have been adopted in Auguest 2015. It is worthy to clarifying that this document is actually independent from draft-ietf-anima-bootstrapping-keyinfra. There was interest in this work posts since its adoption. There was never any opposition for this work. This document went through a relevant shorter document development period (3 months for individual document period, 8 month for WG document period). It has been reviewed well. Document Quality This document went through multiple reviews by multiple WGs (ANIMA, 6tisch, NETCONF) participants. And this document went through a cross-group WGLC, which did receive comments to help improving the document. So far, there is no existing implementations. Personnel Sheng Jiang is the document shepherd. Terry Manderson is the responsible AD. IANA Note IANA is asked to registers a URIs in the IETF XML registry: URI: urn:ietf:params:xml:ns:yang:ietf-voucher IANA is requested to registers a YANG module in the YANG Module Names registry: ietf-voucher. All the necessary information is in the IANA considerations document. It is clear enough that the IANA will be able to implement it. ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] Last Call: (An Autonomic Control Plane (ACP)) to Proposed Standard
The IESG has received a request from the Autonomic Networking Integrated Model and Approach WG (anima) to consider the following document: - 'An Autonomic Control Plane (ACP)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2018-02-26. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Management and Control Plane should ideally be self-managing, and as independent as possible of configuration. This document defines such a plane and calls it the "Autonomic Control Plane", with the primary use as a control plane for autonomic functions. It also serves as a "virtual out of band channel" for OAM (Operations Administration and Management) communications over a network that is secure and reliable even when the network is not configured, or not misconfigured. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2407/ The document contains these normative downward references. See RFC 3967 for additional information: draft-behringer-anima-autonomic-control-plane: An Autonomic Control Plane (None - ) draft-carpenter-anima-ani-objectives: Technical Objective Formats for the Autonomic Network Infrastructure (None - ) draft-behringer-autonomic-control-plane: An Autonomic Control Plane (None - ) draft-ietf-roll-applicability-template: ROLL Applicability Statement Template (None - IETF stream) draft-behringer-anima-autonomic-addressing: An Autonomic IPv6 Addressing Scheme (None - ) ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] BRSKI over 802.11
Hi Bing, I think you've got it down, but I want to stress that these are early days, and I could, perhaps easily, be convinced to go another way. I think Michael is trying to do that ;-) I think the question is this: in a WiFi environment how can the device know which network to connect with in the first place, and how does it then send packets to complete the BRSKI flow? As a difficult use case, consider a business in an office building on the 10th floor in New York City or London, where you might hear 2 dozen different networks. Eliot On 11.02.18 10:16, Liubing (Leo) wrote: > Hi Michael, Eliot and all, > > A clarification question: it sounds like there are two approaches proposed, > not sure I understood it correctly: > > Michael's proposal: there is a dedicated SSID, say "Anima", it is enabled by > default, and there is no security. And that SSID can only do BRSKI, no other > services permitted (just like the http portal authentication). After getting > the certificate, then certificate-based EAP could be run to do the 802.1x > authentication; or maybe they just negotiated a key for WPA2. In this case, > the BRSKI just works as the bootstrap of WiFi. > > Eliot's proposal: we'll have a new EAP method, say "EAP-BRSKI", just treat > BRSKI as an option encapsulated in EAP protocol, under the WiFi access > framework. > > Michael and Eliot: did I get you correctly? > > B.R. > Bing > >> -Original Message- >> From: Anima [mailto:anima-boun...@ietf.org] On Behalf Of Eliot Lear >> Sent: Thursday, February 08, 2018 5:51 PM >> To: Artur Hecker ; anima@ietf.org >> Subject: Re: [Anima] BRSKI over 802.11 >> >> Artur, >> >> I suspect much – but not all – of this could be addressed in EAP. >> >> Eliot >> >> >> On 08.02.18 10:24, Artur Hecker wrote: >>> Hi Michael >>> >>> >>> Sorry, maybe I misunderstood the intention. Is your intention to make it >> "standard" or just to make a demonstration? If the latter, then it's OK. >> It's the >> first that I simply doubt it will work. >>> I am not claiming that there are better means to do that, let alone that >>> what >> you proposed makes no sense. I actually said that this makes sense. I just >> think >> that we enter the realms of 802.1 and 802.11 at the same time and have no >> authority there. >>> It has indeed nothing to do with Wireless access points. Any STA (802.11) >>> and >> any supplicant (802.1X) is subject to standardization and regulation of the >> bodies >> of IEEE, in any mode of operation. WPS should not be limited to any Access >> Point presence, since it supports WiFi Direct. I agree, the supported >> methods are >> rudimentary. If I remember correctly, something like PIN, the push button you >> mentioned, NFC and USB. >>> I guess, a possibility would be to specify an additional ANIMA/ACP/BRSKI >> method for WPS, why not. All I am saying is that we probably need to do it >> there, >> as any try to do it in the ANIMA WG would require specific 802.11 modes and >> specific 802.1X functions/behaviours, which I am not sure we can dictate to >> have. >>> >>> Regards >>> artur >>> >>> >>> -Original Message- From: Michael Richardson [mailto:mcr+i...@sandelman.ca] Sent: 07 February 2018 20:07 To: Artur Hecker Cc: anima@ietf.org Subject: Re: [Anima] BRSKI over 802.11 Artur Hecker wrote: > Hi Michael, > My opinion: I don't think understood the question :-) 1) It's not about Wireless Access Points, so all of the Wifi Alliance, etc. talk makes no sense to me. There can be no access points until they have been configured. It's possible that there might NEVER been any access points, because the operator actually doesn't want/need any enabled. Think about inside of a cage in a data center. 2) It's about *devices* that have 802.11 interfaces. You can't use WPS or anything else involving 802.1x until you have credentials, which is what BRSKI gets you. So you can't use WPS to *bootstrap* WPS. (and pushing buttons on the front of the AP is by definition not "zero- touch") > Q3: Sorry, I did not quite understand this one. If you meant the ad-hoc > essid based network, my first intuition would be to object, as I > believe that we should not prescribe such modes for ACP, but rather use > the best available one. 3) The ACP is secured inside IPsec over Link-Layer IPv6 (or MACSEC, or a bunch of other possible technologies in the ACP document). It's not about the security of the ACP. Since the point of the ACP is that it's always available, it needs to be available even when the Wifi Access Point is toast or not yet configured. Of course, once there is a non-adhoc/IBSS network available, the ACP would see this as additional interfaces and make additional mesh >>
