Re: [Anima] BRSKI over 802.11

[Toerless Eckert]

I am not even sure we would need to come up with just one permitted option.

The two directions i see now from Owens input:

a) "enterprise" Model.

Relying on AAA server to be able to authenticate Pledges
based on e.g.: EAP-TLS with IDevID as auth. No additional SSID needed. Should
try to also announce 802.11u GAS, but need to figure out if/how this would
work in the face of multiple SSIDs supported (aka: multi-domain).

b) SSID approach
- can work without any change to 802.11 infra, just put BRSKI proxy on the 
BRSKI VLAN.
- Work without AAA, e.g.: PSK (home AP).
- multi-domain, no 802.11u support needed (unclear how ubiquitous that is).

Single domain mode where AP has only one domain offering BRSKI, BRSKI SSID
is just called BRSKI%%, no beacon sent (called "hidden" in most UIs). Connects
only to BRSKI Proxy, carries only BRKSI traffic therefore. 

Multiple 's on an AP, each one wanting to offer BRSKI, second and further
SSID have to be renamed to BRSKI%. But actual SSID for BRSKI for those 
's
is BRSKI%. No crypto, just connected to BRSKI Proxy. 

Cheers
Toerless

On Fri, Feb 16, 2018 at 11:43:04AM -0500, Michael Richardson wrote:
> 
> Owen Friel (ofriel)  wrote:
> > [ofriel] I think a more comprehensive analysis of the various SSID
> > discover options (DPP, hardcoded SSID, NAI Realm,..) and how each fits
> > into the two post-SSID discovery options of (i) a new EAP-BRSKI
> > vs. (ii) reuse of EAP-TLS (or some suitable EAP method, possibly with
> > 2x 80.1x exchanges) is needed before any consensus on the contents of
> > an ID is necessary. Unless you are suggesting than an initial ID merely
> > outlines the multiple options but makes no final recommendation
> > yet. Happy to get started on that...
> 
> Yes... the point of the ID would be to layout the options
> 
> The options-not-selected would go into an appendix of a final document to
> explain paths not taken.
> 
> --
> Michael Richardson , Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 



> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima


-- 
---
t...@cs.fau.de

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] BRSKI over 802.11

[Michael Richardson]

Owen Friel (ofriel)  wrote:
> [ofriel] I think a more comprehensive analysis of the various SSID
> discover options (DPP, hardcoded SSID, NAI Realm,..) and how each fits
> into the two post-SSID discovery options of (i) a new EAP-BRSKI
> vs. (ii) reuse of EAP-TLS (or some suitable EAP method, possibly with
> 2x 80.1x exchanges) is needed before any consensus on the contents of
> an ID is necessary. Unless you are suggesting than an initial ID merely
> outlines the multiple options but makes no final recommendation
> yet. Happy to get started on that...

Yes... the point of the ID would be to layout the options

The options-not-selected would go into an appendix of a final document to
explain paths not taken.

--
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

Re: [Anima] BRSKI over 802.11

[Owen Friel (ofriel)]

-Original Message-
From: Michael Richardson [mailto:mcr+i...@sandelman.ca] 
Sent: Thursday 15 February 2018 22:12
To: Owen Friel (ofriel) <ofr...@cisco.com>
Cc: Toerless Eckert <t...@cs.fau.de>; anima@ietf.org; Max Pritikin (pritikin) 
<priti...@cisco.com>; Eliot Lear (elear) <el...@cisco.com>
Subject: Re: [Anima] BRSKI over 802.11


Owen, thanks for the extensive email... I actually read to the end.
What's this legacy "DHCP" protocol?  Does anyone still use it? :-) I thought 
IPv4 was an over-the-top service now.. :-) :-)

It seems like you have most of an ID already there... perhaps you'd like to 
write something up... since you seem to have thought through all the 
possibilities.

[ofriel] I think a more comprehensive analysis of the various SSID discover 
options (DPP, hardcoded SSID, NAI Realm,..) and how each fits into the two 
post-SSID discovery options of (i) a new EAP-BRSKI vs. (ii) reuse of EAP-TLS 
(or some suitable EAP method, possibly with 2x 80.1x exchanges) is needed 
before any consensus on the contents of an ID is necessary. Unless you are 
suggesting than an initial ID merely outlines the multiple options but makes no 
final recommendation yet. Happy to get started on that...

--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works  -= IPv6 
IoT consulting =-



___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] BRSKI over 802.11

[Owen Friel (ofriel)]

Inline Toerless.

-Original Message-
From: Toerless Eckert [mailto:t...@cs.fau.de] 
Sent: Thursday 15 February 2018 22:44
To: Owen Friel (ofriel) <ofr...@cisco.com>
Cc: Michael Richardson <mcr+i...@sandelman.ca>; anima@ietf.org; Max Pritikin 
(pritikin) <priti...@cisco.com>; Eliot Lear (elear) <el...@cisco.com>
Subject: Re: [Anima] BRSKI over 802.11

Thanks, Owen, inline

On Thu, Feb 15, 2018 at 07:54:48PM +, Owen Friel (ofriel) wrote:
> (some context - I've been talking internally to Max and Eliot about 
> this quite a bit)
> 
> First, a high level summary of 802.11u-2011 (which is incorporated into 
> 802.11-2016) capabilities.
> 
> STAs and APs advertise support for 802.11u by setting the Interworking bit in 
> the Extended Capabilities IE, and by including the Interworking IE in Beacon, 
> Probe Request and Probe Response frames.
> 
> The Interworking IE includes info on:
> - Access Network Type (Private, Free public, Chargeable public, etc.)
> - internet bit (yes/no)
> - ASRA (Additional Step required for Access - e.g. this could mean 
> EAP-TLS, or a BRSKI flow)
> 
> 802.11u introduced ANQP Access Network Query Protocol which enables STAs to 
> query APs for info not present in Beacons/Probe Reponses.
> 
> ANQP defines these key IEs for enabling the STA to determine which network to 
> connect to:
> 
> Roaming consortium IE: includes the OI(s) of the roaming consortium(s). The 
> OI is typically  provisioned on cell phones by the SP, so the cell phone can 
> automatically detect wifi networks that provide access to its SP's consortium.
> 
> 3GPP Cellular Network IE: includes the Mobile Country Code (MCC) and Mobile 
> Network Code (MNC) of the SP the AP provides access to.
> 
> Network Access Identifier Realm IE: includes RFC4282 realm names that the AP 
> provides access to (e.g. wifi.service-provider.com). The NAI Realm IE also 
> includes info on the EAP type required to access that realm e.g. EAP-TLS.
> 

[ofriel] One other comment on NAI Realms, WLCs often place artificial 
restrictions on the numbers of these than can be configured. 802.11 allows 2x 
octet count of realms, but WLCs could only allow e.g. 32. Additionally, big 
mobile SPs often have dozens of roaming partners, and these guys tend to use a 
single Roaming  consortium OI instead of NAI Realms.

> Domain name IE: the domain name(s) of the local AP operator. Its purpose is 
> to enable a STA to connect to a domain operator that may have a more 
> favourable pricing model for backhaul connections to the internet / SP.
> 
> STAs can use some or all of the above IEs to make a suitable decision on 
> which SSID to pick.
> 
> HotSpot 2.0 is an example of a spec built on top of 802.11u and defines 10 
> additional ANQP elements using the standard vendor extensions mechanisms 
> defined in 802.11.
> It also defines a HS2.0 Indication element that is includes in Beacons and 
> Probe Responses so that STAs can immediately tell if an SSID supports HS2.0.
> 
> That's the end of the .11u intro, but I'll come back to NAI Realms in a bit.

Right. I've looked at 
http://web.mit.edu/freebsd/head/contrib/wpa/hostapd/hostapd.conf
where it shows all the parameters you could configure. If we wanted to make 
this applicable to BRSKI i am mostly worried that we wold need to register 
somehow new values for parameters that allow only predefined values.

[ofriel] Well, if we went down the path of using NAI Realms for BRSKI, NAI 
Realms already allows entry of free-form domains. It doesn't have pre-defined 
values for NAI Realms. What would be needed is some registry where we define 
the well-known NAI Realm that should be configured on the WLC. That wouldn't 
require IEEE changes. And that value could be defined in an IETF draft that 
points to an IANA registry..?

[ofriel] That hostapd.conf file has a section " # NAI Realm information " 
outlining how to configure these, it also allows specification of the EAP 
Method Type, with that value being taken from the IANA registry. It gives 
examples for 13 (EAP-TLS) and 21 (EAP-TTLS) so if a EAP-BRSKI method were 
defined, that hostapd.conf already supports that type of config.

Any idea what the process for that is ?

[ofriel] If we wanted to e.g. advertise a new value for the Access Network Type 
bits in the Access Network Options octet in the Interworking IE, that's IEEE 
work I guess. If we wanted to define a new vendor extension IE (similar to 
HS2.0) then that's.. Wi-Fi alliance work..?

> I agree with Nancy below on splitting this into SSID discovery and 
> connection/authentication steps. There were a few discovery options proposed 
> in this thread, and I'll add to that:
> 
> 1. define a well-known naming convention for BRSKI capable SSIDs e.g. 
> BRSKI%xfinity
> 
> This goes against the grain 

Re: [Anima] BRSKI over 802.11

[Toerless Eckert]

ic 
> keys.

How would that work in the face of multi-operator domains supported by the
AP ? Aka: on my home AP i can have xfinity and my own home network service,
and we would not want to assume coordination betwen them about which of the
two domain should claim a device.


> Anyways, once the device somehow knows the SSID, it can begin connection and 
> authentication.
> 
> There have been comments that pre-completing BRSKI, the client must connect 
> to an unsecure network. That's not entirely true. The network could in fact 
> enforce 802.1x and EAP-TLS based on the manufacturer's cert / IDevID.

I am somewhat cautious as to how easy it would be to get all the necessary bits
implemented in APs to support that approach without impacting the pre-existing 
SSID
security. For example, if this requires to know something about
IDevIDs on the radius server, and radius server upgrades, then it IMHO a nogo.

> Similarly, if an EAP-BRSKI mechanism were to be defined, the network could 
> deny access and not even allow the client to send its /requestvoucher unless 
> it successfully completed the initial TLS and presented a trusted IDevID. So 
> it could be a bootstrapping network segment that allows devices from trusted 
> manufacturers. That seems like a better alternative to using WPA-PSK with a 
> known network key or WAP-802.1x with a known username/password (both of which 
> require somehow provisioning that key into the device).
> 
> And on defining a new EAP-BRSKI mechanism, it should be possible to achieve 
> today what EAP-BRSKI would enable, albeit with 2 x 802.1x, 2 x DHCP requests. 
> A flow could be:
> 
> 1. device discovers SSID
> 2. network enforces 802.1x EAP-TLS and checks that device has an IDevID 
> signed by a trusted manufacturer CA; if not deny access
> 3. AAA instructs WLC to put device in a network segment that grants it access 
> to the Registrar and nothing else
> 4. device does DHCP, gets and IP, and does the BRSKI dance and uses its 
> IDevID to get an LDevID
> 5. Once device has an LDevID, it does  DHCP Release and an EAPOL-Logoff
> 6. Device restarts 802.1x
> 7. network enforces 802.1x EAP-TLS and this time checks that device has a 
> trusted LDevID
> 8. AAA instructs WLC to put device in a network segment that grants it access 
> to all required services
> 9. device does DHCP and we are done
> 
> Not saying that that complex flow is desirable, the 2x 802.1x and 2x DHCP 
> will make constrained Things baulk, but its feasible. And if we were to say 
> use the NAI Realms "_bootstrapks" mechanism, we could in theory build that 
> solution out now with no infrastructure revs, and with minimal 
> standardisations effort (rfc to define the use of NAI Realm).

This is getting back to the discussion i referred to a few years back.

> The EAP-BRSKI flow would be something like:
> 
> 1. device discovers SSID
> 2. network enforces 802.1x EAP-BRSKI and checks that device has an IDevID 
> signed by a trusted manufacturer CA; if not deny access
> 3. BRSKI flow takes place at L2, with /requestvoucher being tunnelled inside 
> EAP, etc.
> 4. Once device has completed BRSKI and has an LDevID, it gets its EAP-Success
> 5. AAA instructs WLC to put device in a network segment that grants it access 
> to all required services
> 6. device does DHCP and we are done
> 
> This is simpler than the 2 x 802.1x, 2 x DHCP above.

Cheers
toerless
> 
> Owen
> 
> -Original Message-
> From: Anima [mailto:anima-boun...@ietf.org] On Behalf Of Toerless Eckert
> Sent: Wednesday 14 February 2018 19:13
> To: Michael Richardson <mcr+i...@sandelman.ca>
> Cc: anima@ietf.org
> Subject: Re: [Anima] BRSKI over 802.11
> 
> On Wed, Feb 14, 2018 at 02:08:20PM -0500, Michael Richardson wrote:
> > > Nancy mentioned other 802.11 options beside SSID, so maybe we should
> > > gate a decision to adopt any such work to the WG having sufficient
> > > understanding of what the existing options in 802.11 are that
> > > we could leverage without having to extend 802.11. Maybe we could
> > > draft Nancy or some other 802.11 expert to give a summary to the WG
> > > (802.11u eg.).
> > 
> > I'm willing to listen to ideas, but I'm afraid of going down the IEEE hole 
> > here.
> 
> Maybe i was unclear. I think we should just know the whole slew of tools 
> available from 802.11 that we can use without changing 802.11. I only know 
> SSID/ESSID, so i try to figure out how to abuse oops: well use them. Nancy 
> pointed to more tools.
> 
> > > Aka: selecting the best SSID in face of competing offers
> > > multiple or single AP is the type of work i think we should
> > > give some tthought to. Ideally something extensible
> > > where we can in the first spec get away with a most simple
> > > start but will have forward compatibility with later
> > > updates/extensions.
> > 
> > your suggestions are inline with what I was thinking.
> 
> Cheers
> Toerless
> 
> > --
> > Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works  
> > -= IPv6 IoT consulting =-
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima

-- 
---
t...@cs.fau.de

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] BRSKI over 802.11

[Michael Richardson]

Owen, thanks for the extensive email... I actually read to the end.
What's this legacy "DHCP" protocol?  Does anyone still use it? :-)
I thought IPv4 was an over-the-top service now.. :-) :-)

It seems like you have most of an ID already there... perhaps you'd like to
write something up... since you seem to have thought through all the 
possibilities.

--
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

Re: [Anima] BRSKI over 802.11

[Owen Friel (ofriel)]

that is advertised 
in Beacons, and then define any additional AQNP elements as are required. This 
is likely a standards body quagmire (and would also requires significant 
infrastructure / WLC development if that's a consideration...)

4. Use / Extend WPS

None of the existing WPS mechanism are really suitable (PIN, push button, NFC, 
USB). Extending WPS, similar to defining new 802.11u extensions, seems like a 
standards body quagmire. Defining a new EAP-BRSKI mechanism seems more 
tractable.

5. Use WiFi Device Provisioning Protocol (Eliot suggested this one)

Some comments on briefly reviewing this. At a high level, if we have a 
bootstrapping Thing trying to discover and connect to an AP (with no one doing 
supervision/handholding via a mobile app or anything), then the Thing is the 
DPP Enrolee and the AP is the DPP Configurator. Additionally, the AP must 
initiate the DPP exchange and not the Thing (the Thing must be the DPP 
responder) because as per DPP, the Initiator must know in advance and validate 
the bootstrapping public key (which would be the public key of the IDevID I 
guess)of the Responder. This means that the AP must be continuously polling for 
Things that it wants to bootstrap (and the Thing must be cycling through all 
channels listening for a DPP initiation request, similar to standard SSID 
passive scanning) . It needs further thought if this has any channel capacity 
implications. The DPP groupId is meant to help with this I think...

One big advantage of this is that the Thing is not attempting (and potentially 
failing, or worse - succeeding to connect to the wrong SSID) to connect to a 
large number of SSIDs unlike option 2 NAI Realm. It also means that an operator 
should not inadvertently claim someone else's Thing as it should be unlikely 
that two Things will have identical bootstrapping public keys.

Anyways, once the device somehow knows the SSID, it can begin connection and 
authentication.

There have been comments that pre-completing BRSKI, the client must connect to 
an unsecure network. That's not entirely true. The network could in fact 
enforce 802.1x and EAP-TLS based on the manufacturer's cert / IDevID. 
Similarly, if an EAP-BRSKI mechanism were to be defined, the network could deny 
access and not even allow the client to send its /requestvoucher unless it 
successfully completed the initial TLS and presented a trusted IDevID. So it 
could be a bootstrapping network segment that allows devices from trusted 
manufacturers. That seems like a better alternative to using WPA-PSK with a 
known network key or WAP-802.1x with a known username/password (both of which 
require somehow provisioning that key into the device).

And on defining a new EAP-BRSKI mechanism, it should be possible to achieve 
today what EAP-BRSKI would enable, albeit with 2 x 802.1x, 2 x DHCP requests. A 
flow could be:

1. device discovers SSID
2. network enforces 802.1x EAP-TLS and checks that device has an IDevID signed 
by a trusted manufacturer CA; if not deny access
3. AAA instructs WLC to put device in a network segment that grants it access 
to the Registrar and nothing else
4. device does DHCP, gets and IP, and does the BRSKI dance and uses its IDevID 
to get an LDevID
5. Once device has an LDevID, it does  DHCP Release and an EAPOL-Logoff
6. Device restarts 802.1x
7. network enforces 802.1x EAP-TLS and this time checks that device has a 
trusted LDevID
8. AAA instructs WLC to put device in a network segment that grants it access 
to all required services
9. device does DHCP and we are done

Not saying that that complex flow is desirable, the 2x 802.1x and 2x DHCP will 
make constrained Things baulk, but its feasible. And if we were to say use the 
NAI Realms "_bootstrapks" mechanism, we could in theory build that solution out 
now with no infrastructure revs, and with minimal standardisations effort (rfc 
to define the use of NAI Realm).

The EAP-BRSKI flow would be something like:

1. device discovers SSID
2. network enforces 802.1x EAP-BRSKI and checks that device has an IDevID 
signed by a trusted manufacturer CA; if not deny access
3. BRSKI flow takes place at L2, with /requestvoucher being tunnelled inside 
EAP, etc.
4. Once device has completed BRSKI and has an LDevID, it gets its EAP-Success
5. AAA instructs WLC to put device in a network segment that grants it access 
to all required services
6. device does DHCP and we are done

This is simpler than the 2 x 802.1x, 2 x DHCP above.

Owen

-Original Message-
From: Anima [mailto:anima-boun...@ietf.org] On Behalf Of Toerless Eckert
Sent: Wednesday 14 February 2018 19:13
To: Michael Richardson <mcr+i...@sandelman.ca>
Cc: anima@ietf.org
Subject: Re: [Anima] BRSKI over 802.11

On Wed, Feb 14, 2018 at 02:08:20PM -0500, Michael Richardson wrote:
> > Nancy mentioned other 802.11 options beside SSID, so maybe we should
> > gate a decision to adopt any such work to the WG having sufficient
&g

Re: [Anima] BRSKI over 802.11

[Toerless Eckert]

On Wed, Feb 14, 2018 at 02:08:20PM -0500, Michael Richardson wrote:
> > Nancy mentioned other 802.11 options beside SSID, so maybe we should
> > gate a decision to adopt any such work to the WG having sufficient
> > understanding of what the existing options in 802.11 are that
> > we could leverage without having to extend 802.11. Maybe we could
> > draft Nancy or some other 802.11 expert to give a summary to the WG
> > (802.11u eg.).
> 
> I'm willing to listen to ideas, but I'm afraid of going down the IEEE hole 
> here.

Maybe i was unclear. I think we should just know the whole slew of tools 
available
from 802.11 that we can use without changing 802.11. I only know SSID/ESSID, so
i try to figure out how to abuse oops: well use them. Nancy pointed to more 
tools.

> > Aka: selecting the best SSID in face of competing offers
> > multiple or single AP is the type of work i think we should
> > give some tthought to. Ideally something extensible
> > where we can in the first spec get away with a most simple
> > start but will have forward compatibility with later
> > updates/extensions.
> 
> your suggestions are inline with what I was thinking.

Cheers
Toerless

> --
> Michael Richardson , Sandelman Software Works
>  -= IPv6 IoT consulting =-

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] BRSKI over 802.11

[Michael Richardson]

Toerless Eckert  wrote:
> I would prefer for any work in this space to happen in
> followup document(s), not in BRSKI itself.

I agree completely.
I wasn't imagining putting it into the current document.

> I think anything done in ANIMA should purely be describing mechanisms
> to leverage unmodified existing 802.11 mechanisms and ideally we find
> some existing work that also built some form of layered standards
> on top of 802.11.

> The issue we IMHO need to overcome is that there
> are ways how this could also be done by extending 802.11 and we
> need to have an argument why that may be an option but it is
> nonwithstanding for us to do it NOT that way. We had for example
> also a long discussion in the beginning of ANIMA why not to use EAP
> in BRSKI.

I agree completely.

> Nancy mentioned other 802.11 options beside SSID, so maybe we should
> gate a decision to adopt any such work to the WG having sufficient
> understanding of what the existing options in 802.11 are that
> we could leverage without having to extend 802.11. Maybe we could
> draft Nancy or some other 802.11 expert to give a summary to the WG
> (802.11u eg.).

I'm willing to listen to ideas, but I'm afraid of going down the IEEE hole
here.

> Aka: selecting the best SSID in face of competing offers
> multiple or single AP is the type of work i think we should
> give some tthought to. Ideally something extensible
> where we can in the first spec get away with a most simple
> start but will have forward compatibility with later
> updates/extensions.

your suggestions are inline with what I was thinking.

--
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

Re: [Anima] BRSKI over 802.11

[Eliot Lear]

Hi Toerless,

On this point:

On 14.02.18 17:56, Toerless Eckert wrote:
> Aka: selecting the best SSID in face of competing offers
> multiple or single AP is the type of work i think we should
> give some tthought to. Ideally something extensible
> where we can in the first spec get away with a most simple
> start but will have forward compatibility with later 
> updates/extensions.

+1.  And I think this needs to be a pretty broad discussion.  We need to
sort, at least in our own minds, at what layer to solve what problem,
and how to do that without driving end users and administrators
absolutely crazy.

Eliot




signature.asc
Description: OpenPGP digital signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] BRSKI over 802.11

[Toerless Eckert]

 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 <artur.hec...@huawei.com>; 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 <artur.hec...@huawei.com>
> >>>> Cc: anima@ietf.org
> >>>> Subject: Re: [Anima] BRSKI over 802.11
> >>>>
> >>>>
> >>>> Artur Hecker <artur.hec...@huawei.com> 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,
> >>&

Re: [Anima] BRSKI over 802.11

[Nancy Cam-Winget (ncamwing)]

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" <anima-boun...@ietf.org 
on behalf of l...@cisco.com> 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 <artur.hec...@huawei.com>; 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 <artur.hec..

Re: [Anima] BRSKI over 802.11

[Michael Richardson]

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

Re: [Anima] BRSKI over 802.11

[Eliot Lear]

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 <artur.hec...@huawei.com>; 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 <artur.hec...@huawei.com>
>>>> Cc: anima@ietf.org
>>>> Subject: Re: [Anima] BRSKI over 802.11
>>>>
>>>>
>>>> Artur Hecker <artur.hec...@huawei.com> 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

Re: [Anima] BRSKI over 802.11

[Liubing (Leo)]

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 <artur.hec...@huawei.com>; 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 <artur.hec...@huawei.com>
> >> Cc: anima@ietf.org
> >> Subject: Re: [Anima] BRSKI over 802.11
> >>
> >>
> >> Artur Hecker <artur.hec...@huawei.com> 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 c

Re: [Anima] BRSKI over 802.11

[Eliot Lear]

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 <artur.hec...@huawei.com>
>> Cc: anima@ietf.org
>> Subject: Re: [Anima] BRSKI over 802.11
>>
>>
>> Artur Hecker <artur.hec...@huawei.com> 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 links across it 
>> for
>> the ACP to use.  But that's not bootstrap, that's operation.
>>
>> > Q4: As I believe that Q2 is strongly biased, I believe that so is
>> > Q4. The WiFi Alliance already specifies several ways how to bootstrap
>> > wireless access points, including e.g. WPS. We would rather need to
>> > see, how to integrate with such means. And again, I don't believe we
>> > have authority on that.
>>
>> Maybe you could point to specific documents that would permit two devices
>> which have never been touched to communicate over 802.11 without
>> configuration.
>>
>> --
>> Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
>> -= IPv6 IoT consulting =-
>>
>>
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
>




signature.asc
Description: OpenPGP digital signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] BRSKI over 802.11

[Artur Hecker]

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 <artur.hec...@huawei.com>
> Cc: anima@ietf.org
> Subject: Re: [Anima] BRSKI over 802.11
> 
> 
> Artur Hecker <artur.hec...@huawei.com> 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 links across it for
> the ACP to use.  But that's not bootstrap, that's operation.
> 
> > Q4: As I believe that Q2 is strongly biased, I believe that so is
> > Q4. The WiFi Alliance already specifies several ways how to bootstrap
> > wireless access points, including e.g. WPS. We would rather need to
> > see, how to integrate with such means. And again, I don't believe we
> > have authority on that.
> 
> Maybe you could point to specific documents that would permit two devices
> which have never been touched to communicate over 802.11 without
> configuration.
> 
> --
> Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] BRSKI over 802.11

[Michael Richardson]

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 links across it
for the ACP to use.  But that's not bootstrap, that's operation.

> Q4: As I believe that Q2 is strongly biased, I believe that so is
> Q4. The WiFi Alliance already specifies several ways how to bootstrap
> wireless access points, including e.g. WPS. We would rather need to
> see, how to integrate with such means. And again, I don't believe we
> have authority on that.

Maybe you could point to specific documents that would permit two devices
which have never been touched to communicate over 802.11 without configuration.

--
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

Re: [Anima] BRSKI over 802.11

[Artur Hecker]

Hi Michael,


My opinion:

Q1: In principle, I believe that it would make sense to do it. However, a 
different question is whether ANIMA WG of the IETF is the right place for it. 
For instance, the integration of WPA-Enterprise you mentioned had been done by 
the WiFi-Alliance, albeit heavily relying on IETF protocols (RADIUS, PPP, EAP, 
Microsoft's MPPE, VSAs, etc).

Q2: Specifically, the relevant issues would seem to rather fall into the scope 
of IEEE 802.1 (for the supplicant), IEEE 802.11 (for the wireless client) or of 
the WiFi Alliance (for integration, etc). We need to consider their way(s) of 
specifying all that. For instance, one could argue that the bootstrapping 
should be done over the DS, whereas whether the DS itself is wireless or not 
should not play any role. In this case, I believe it would be wrong to define 
ESSIDs or modes of operation of 802.11, because it's extremely biased. I am not 
even talking about OAM, because I do not want troubles :-)

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.

Q4: As I believe that Q2 is strongly biased, I believe that so is Q4. The WiFi 
Alliance already specifies several ways how to bootstrap wireless access 
points, including e.g. WPS. We would rather need to see, how to integrate with 
such means. And again, I don't believe we have authority on that.


Regards
artur


> -Original Message-
> From: Anima [mailto:anima-boun...@ietf.org] On Behalf Of Michael 
> Richardson
> Sent: 07 February 2018 17:00
> To: anima@ietf.org
> Subject: [Anima] BRSKI over 802.11
> 
> 
> Q1) Is there interest in doing bootstrap of devices/routers/etc. over WIFI?
> 
> Q2) If there is, should the BRSKI document proscribe an Ad-Hoc (IBSS) ESSID
> on which bootstrap would be done (perhaps named "BRSKI" or "ANIMA").
> 
> Q3) Would you want to use this network as a substrate for the ACP later on?
> 
> Q4) Should such a network be
>  a) unsecured (cleartext)
>  b) use WPA-PSK with a known "network key"
>  b) use WPA2 enterprise 802.1X using a published username/password.
> (like we use for ietf network)
> This is no less secure than unsecured, but unlike (b), each
> session gets a unique session key.
> 
> --
> ]   Never tell me the odds! | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works| network architect  [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails
> [

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima