[Anima] Re: Additional AD review

[Owen Friel (ofriel)]

Hi Mahesh,
All these issues have been addressed in the github repo. We raised individual 
issues 156-166 for each of your comments below if you want to check the 
specific text:

https://github.com/anima-wg/brski-cloud/issues?q=is%3Aissue+is%3Aclosed

You can expect a draft-10 shortly.
Thanks,
Owen

From: Mahesh Jethanandani 
Sent: Wednesday, August 21, 2024 1:41 AM
To: draft-ietf-anima-brski-cloud@ietf.org
Cc: anima@ietf.org; anima-cha...@ietf.org
Subject: Additional AD review

Hi Authors,

Thanks for posting an update for the draft, and addressing the AD review 
comments of Rob Wilton. Since the changes were extensive, a second review was 
warranted. I expect some responses for the COMMENTs but it would be nice if you 
addressed the NITs also.

---
COMMENT
---

Overall comments:

Please run a spell checker of choice to fix all the spelling errors in the 
document, which there are plenty. The second has to with inconsistent use of 
terms. Examples include "Owner Registrar" and "owner Registrar”, “pledge” and 
“Pledge”, “bootstrap” and “Bootstrap". It helps to be consistent in your use of 
the terms.

Specific comments:

Section 1, paragraph 3
>To support enrolment of pledges without such an owner based access
>network, the mechanisms of BRSKI Cloud are required which assume that
>Pledge and Registrar simply connect to the Internet.  The Internet
>("Cloud") connected Registrar will then determine ownership of the
>Pledge and redirect the Plege to its owners Registrar.

I will admit I have not gone through the BRSKI specification. What happens if 
the URI of the Cloud Registrar is shutdown or moved? Is that covered by BRSKI, 
or is that outlined somewhere in this document?

Section 1.2.1, paragraph 1
>A pledge is bootstrapping from a location with no local domain
>Registrar (for example, the small site or teleworker use case with no
>local infrastructure to provide for automated discovery), and needs
>to discover its owner Registrar.  The Cloud Registrar is used by the
>pledge to discover the owner Registrar.  The Cloud Registrar
>redirects the pledge to the owner Registrar, and the pledge completes
>bootstrap against the owner Registrar.

Covered in the overall comments, but repeated here. What is the difference 
between "Owner Registrar" and "owner Registrar"? If they are the same, can we 
be consistent in its usage? Same for pledge and Pledge.

Section 2, paragraph 3
>For use case one, as described in Section 1.2.1, the Cloud Registrar
>redirects the pledge to an owner Registrar in order to complete
>bootstrap with the owner Registrar.  When bootstrapping against an
>owner Registrar, this Registrar will interact with a CA to assist in
>issuing certificates to the pledge.  This is illustrated in Figure 1.


It is not clear which registrar is "this Registrar". Is it the Cloud Registrar 
or the owner Registrar?

Section 2, paragraph 3
>For use case two, as described Section 1.2.2, the Cloud Registrar
>issues a voucher itself without redirecting the pledge to an owner
>Registrar, the Cloud Registrar will inform the pledge what domain to
>use for accessing EST services in the voucher response.  In this
>model, the pledge interacts directly with the EST service to enrol.
>The EST service will interact with a CA to assist in issuing
>certificated to the pledge.  This is illustrated in Figure 2.


s/cerfificated/a cerficate/

Section 3.1.2, paragraph 1
>According to [BRSKI], Section 2.7, the pledge MUST use an Implicit
>Trust Anchor database (see EST [RFC7030]) to authenticate the Cloud
>Registrar service.  The pledge MUST establish a mutually
>authenticated TLS connection with the Cloud Registrar.  Unlike the
>procedures documented in BRSKI section 5.1, the pledge MUST NOT
>establish a provisional TLS connection with the Cloud Registrar.


Please add a definition or a reference to "provisional TLS connection"?

Section 3.2, paragraph 2
>If the request is correct and the Registrar is able to handle it, but
>unable to determine ownership, then it MUST return a 401 Unauthorized
>response to the pledge.  This signals to the Pledge that there is
>currently no known owner domain for it, but that retrying later might
>resolve this situation.  In this scenario, the Registrar SHOULD
>include a Retry-After header that includes a time to defer.  A pledge
>with some kind of indicator (such as a screen or LED) SHOULD consider
>this a bootstrapping failure, and indicate this to the operator.


Thanks for addressing Rob's comment and changing the MAY to a SHOULD. But you 
left the rest of the paragraph as is, and now the following sentence does not 
make sense. What failure condition are you referring to? Also, wnen you do 

Re: [Anima] Moving draft-ietf-anima-brski-cloud-06 forward

[Owen Friel (ofriel)]

Thanks Esko,
I just merged a PR to address these: 
https://github.com/anima-wg/brski-cloud/issues/40
Thanks,
Owen

-Original Message-
From: Anima  On Behalf Of Esko Dijk
Sent: Thursday, June 22, 2023 9:01 AM
To: Sheng Jiang ; Brian E Carpenter 
; Brian Carpenter ; 
Toerless Eckert 
Cc: anima-chairs ; anima 
Subject: Re: [Anima] Moving draft-ietf-anima-brski-cloud-06 forward

Hi Sheng, authors,

I checked the new text vs the WGLC issues and confirm that these are resolved.

Because there's new text being added; I've reviewed this as well. Below my 
findings. I would prefer if the WG could fix this as part of the WGLC work.

** Section 3.2
I can't fully follow the logic in Section 3.2 - it's unclear. Below is a 
proposal for improvement. There needs to be reference to [BRSKI] defined codes, 
and a particular code defined for the "owner cannot be determined" case because 
just using any 4xx/5xx code for that at the whim of the registrar implementer 
doesn't make sense to me. (The party implementing the cloud registrar may be 
another party than the one making the pledge code - interoperability plays a 
role here.)

PROPOSED NEW TEXT:
The cloud registrar must determine pledge ownership. Prior to ownership 
determination, the registrar checks the request for correctness and if it is 
unwilling or unable to handle the request, it MUST return a suitable 4xx or 5xx 
error response to the pledge as defined by [BRSKI] and HTTP.
For example, in case of an unknown pledge a 404 is returned, for a malformed 
request 400 is returned, or in case of server overload 503.

If the request is correct and the registrar is able to handle it, but unable to 
determine ownership, then it MUST return a 401 Unauthorized response to the 
pledge. This signals to the Pledge that there is currently no known owner 
domain for it, but that retrying later might resolve this situation.

If the cloud registrar successfully determines ownership, then it MUST take one 
of the following actions:
* return a suitable 4xx or 5xx error response (as defined by [BRSKI] and HTTP) 
to the pledge if the request processing failed for any reason
* redirect the pledge to an owner register via 307 response code
* issue a voucher and return a 200 response code

** Section 3.3 
It seems that a section is missing on the Pledge side handling an "error 
response". For example, it could be just a sentence saying the "usual" HTTP 
error handling defined by [BRSKI] and HTTP applies.
And that for the case of 401 Unauthorized the Pledge MAY retry at a later time.


** Nits
"They operator the Registrar or EST Server"
"which is addresses in part in"

Best regards
Esko

-Original Message-
From: Anima  On Behalf Of Sheng Jiang
Sent: Friday, June 16, 2023 05:17
To: Brian E Carpenter ; Brian Carpenter 
; Toerless Eckert ; Esko Dijk 

Cc: anima-chairs ; anima 
Subject: [Anima] Moving draft-ietf-anima-brski-cloud-06 forward

Hi, Brian, Esko & Toerless,

The authors has submitted a new version draft-ietf-anima-brski-cloud-06. In 
principle, this draft has passed ANIMA WGLC with the condition that your 
editional comments are addressed. Could you check and confirm? After your 
confirmation, the document shepherd and WG chair would like to move it forward.

Regards,


--



Sheng Jiang


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

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

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

[Anima] FW: New Version Notification for draft-friel-anima-brski-cloud-03.txt

[Owen Friel (ofriel)]

Hi,

Michael, Rifaat and I have made significant updates including:

- clarifying use cases and architecture
- adding protocol operations details
- defining voucher yang module extensions

We believe the draft is ready for adoption, and want to start that discussion 
here.

Cheers,
Owen

-Original Message-
From: internet-dra...@ietf.org  
Sent: 25 September 2020 00:08
To: Michael Richardson ; Rifaat Shekh-Yusef 
; Owen Friel (ofriel) 
Subject: New Version Notification for draft-friel-anima-brski-cloud-03.txt


A new version of I-D, draft-friel-anima-brski-cloud-03.txt
has been successfully submitted by Michael Richardson and posted to the IETF 
repository.

Name:   draft-friel-anima-brski-cloud
Revision:   03
Title:  BRSKI Cloud Registrar
Document date:  2020-09-24
Group:  Individual Submission
Pages:  17
URL:https://www.ietf.org/id/draft-friel-anima-brski-cloud-03.txt
Status: https://datatracker.ietf.org/doc/draft-friel-anima-brski-cloud/
Html:   https://www.ietf.org/id/draft-friel-anima-brski-cloud-03.html
Htmlized:   https://tools.ietf.org/html/draft-friel-anima-brski-cloud-03
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-friel-anima-brski-cloud-03

Abstract:
   This document specifies the behaviour of a BRSKI Cloud Registrar, and
   how a pledge can interact with a BRSKI Cloud Registrar when
   bootstrapping.

   RFCED REMOVE: It is being actively worked on at https://github.com/
   anima-wg/brski-cloud


  


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


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

Re: [Anima] representing ACP info in X.509 certs

[Owen Friel (ofriel)]

Being completely pedantic about the RFC5280 text, nowhere in the text does it 
say that rfc822name cannot be used for anything but email address. It does 
state multiple times that an email address must be represented as an 
rfc822name, but places no explicit restrictions on what an rfc822name may 
represent. The text as is does not explicitly preclude use of rfc822name for 
ACP. This may be the widespread understanding of what RFC5280 means, but its 
not strictly what it says…

From: Anima  On Behalf Of Eric Rescorla
Sent: 21 June 2020 09:26
To: Stephen Kent 
Cc: Anima WG 
Subject: Re: [Anima] representing ACP info in X.509 certs

This matches my understanding as well.

One thing that's not clear to me: is the expectation that you will be using a 
public CA or that you will be using an enterprise-level one?

-Ekr


On Sat, Jun 20, 2020 at 5:03 PM Stephen Kent 
mailto:40verizon@dmarc..ietf.org>> 
wrote:

Folks,

My perspective matches what Russ & Ben have suggested, i.e., use of rfc822Name 
is inappropriate for this context. RFC 5280 is very clear about the intended 
use of the rfc822Name field in a cert and the proposed use in the anima context 
is inconsistent with 5280 text. A reasonable, appropriate way forward is to 
define a new otherName type for the anima context.

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

Re: [Anima] Cloud BRSKI discussion -- Option 1 use cases

[Owen Friel (ofriel)]

> -Original Message-
> From: Anima  On Behalf Of Brian E Carpenter
> Sent: 25 November 2019 19:25
> To: Michael Richardson 
> Cc: anima@ietf.org
> Subject: Re: [Anima] Cloud BRSKI discussion -- Option 1 use cases
> 
> On 25-Nov-19 22:14, Michael Richardson wrote:
> >
> > Brian E Carpenter  wrote:
> > > One thing that doesn't seem to be clear either in BRSKI or in
> > > draft-friel-anima-brski-cloud is where the Cloud Registrar's "well
> > > known" URI comes from and how the pledge knows it. Is it vendor
> > > specific or what?
> >
> > It is vendor specific, and it's baked in.
> 
> Thanks. That was my working assumption, but I suggest stating it up front in
> draft-friel-anima-brski-cloud.

[ofriel] 
https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-30#appendix-B
 states:

"   If no local proxy or registrar service is located using the GRASP
   mechanisms or the above mentioned DNS-based Service Discovery
   methods, the pledge MAY contact a well known manufacturer provided
   bootstrapping server by performing a DNS lookup using a well known
   URI such as "brski-registrar.manufacturer.example.com".  The details
   of the URI are manufacturer specific.  Manufacturers that leverage
   this method on the pledge are responsible for providing the registrar
   service.  Also see Section 2.7."

> 
> > The idea is that we can transform the well-known, but very much
> > proprietary "call-home" process that many devices use today into
> > something that enables a transfer of ownership mechanism.
> 
> Understood.
> 
> Brian
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima

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

Re: [Anima] Call for agenda ANIMA @ IETF 106, Singapore

[Owen Friel (ofriel)]

Hi Sheng,

Could I request 2 slots:

Slot 1:

Name: BRSKI Cloud Registrar
Draft: draft-friel-anima-brski-cloud
Time: 15 mins
Presenters: Owen Friel / Michael Richardson

Slot 2:

Name: ACME Integrations
Drafts: draft-friel-acme-integrations, draft-friel-acme-subdomains
Time: 10 mins
Presenter: Owen Friel

Thanks,
Owen




From: Anima  On Behalf Of Sheng Jiang
Sent: 08 October 2019 04:56
To: anima@ietf.org
Cc: anima-cha...@ietf.org
Subject: [Anima] Call for agenda ANIMA @ IETF 106, Singapore


Hi, all anima,



We have been allocated two sessions of 1.5 + 1 hour for the ANIMA WG meeting 
for IETF-106 (Singapore). We are now starting to collect agenda items for the 
sessions. Please send your request for agenda by October 31th, Thursday, to 
anima-cha...@ietf.org>
 and both chairs' email. Please note that email to a single chair may cause 
single-point failure.



As normal, the priority among these non-charter work items would be: these that 
have active discussion in mail list, then these have submitted drafts, and 
topics without drafts.



As you may observed, we now have the new WG charter in the place, but still, we 
have the priority to complete the current WG documents over to adopt any new 
work.



Please send us (anima-chairs at 
ietf.org)
 requests for time slot by October 31th, Thursday and include:



Name of time slot:

Name of draft(s):

Time requested:

Presenter name(s):



More details about the IETF 106, Montreal can be found at:



https://www.ietf.org/how/meetings/106/



Again, presenters and draft authors please invoke active discussions in the 
ANIMA list. Mail list is a very good place to discuss and reach consensus on 
technical issues.



Best regards,



Sheng

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

Re: [Anima] [Iot-onboarding] Fwd: Your Webex recording is available for viewing: IoT Onboarding Meeting-20190829 1513-1

[Owen Friel (ofriel)]

As requested:

https://github.com/upros/brski-cloud/blob/master/draft-friel-anima-brski-cloud.md
 is not published yet. It provides more details on how a BRSKI vendor default 
cloud registrar works, and lists a few options for redirect from cloud to prem. 
Some of the options also require voucher extensions to return domains/DNS-IDs.

https://tools.ietf.org/html/draft-friel-acme-integrations-01 covers how ACME 
could be used with both BRSKI and TEAP for issuing LDevIDs, and it also 
documents how ACME can be used to issue subdomain certs without explicit 
subdomain ownership proofs, which is a nice optimisation for issuing large 
numbers of LDevIDs. The subdomain part is in the process of being broken out 
into a separate doc: 
https://github.com/upros/acme-subdomains/blob/master/draft-friel-acme-subdomains.md
 but that’s not published yet either.


From: Iot-onboarding  On Behalf Of Eliot Lear
Sent: 29 August 2019 17:33
To: iot-onboard...@ietf.org; anima@ietf.org
Subject: [Iot-onboarding] Fwd: Your Webex recording is available for viewing: 
IoT Onboarding Meeting-20190829 1513-1

Hi everyone, and thanks for joining.  Those people who wish to listen to the 
recording (it started a bit after the meeting), please see attached.  I’ll 
summarize the meeting in a separate email.

Eliot


Begin forwarded message:

From: mailto:messen...@webex.com>>
Subject: Your Webex recording is available for viewing: IoT Onboarding 
Meeting-20190829 1513-1
Date: 29 August 2019 at 18:30:59 CEST
To: mailto:el...@cisco.com>>
Reply-To: mailto:messen...@webex.com>>

Hi Eliot Lear,
Your recording is now available on your Webex site.



IoT Onboarding Meeting-20190829 1513-1
Thursday, August 29, 2019
5:13 pm  |  Europe Summer Time (Amsterdam, GMT+02:00)



Play 
recording
 (47 min 54 sec)
Recording password: fRJsavS4



You can forward this message to others to allow them to play back the recording.



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

Re: [Anima] [Iot-onboarding] EXTERNAL: Re: OPC and BRSKI

[Owen Friel (ofriel)]

-Original Message-
From: Iot-onboarding  On Behalf Of Toerless 
Eckert
Sent: 12 August 2019 19:50
To: Jack Visoky 
Cc: Michael Richardson ; Randy Armstrong (OPC) 
; anima@ietf.org; iot-onboard...@ietf.org
Subject: Re: [Iot-onboarding] [Anima] EXTERNAL: Re: OPC and BRSKI

Agreeing to what Michael and you said, but also wanted to point out that TLS as 
defined by IETF is on a trajectory which may or may not be desirable for e.g.: 
industrial automation (where OPC is used) or other regulated/ critical 
environments.

For example the total elimination of any non-encryption option in the
TLS1.3 profile and the removal of the ability for passive observers to see the 
certificates exchanged impeeds severely on the ability to do passive 
diagnostics.

I at least think there are good reasons to also have a strong and independent 
reviewed authentication scheme without encryption that can well be diagnosed by 
passive observers.

Aspects like these are easily fixed IMHO by creating different profiles of TLS. 
Whether or not one could get such profiles through the TLS WG in the IETF is of 
course a different question given what seems to be a highly contentuous nature 
of the topic.

There also seems to be a desire of areas of industrial automation to avoid the 
overhead of a perceived to be redundant network layer. This was a thing back in 
the days of OSI where TP4 was often run in factories without CLNS, and given 
how IP hasn't really improved on simplified, automated address management vs. 
L2 switched ethernet, this still seems to be a thing. Aka: Someone would need 
to define TLS on top of just ethernet instead of IP/IPv6. And there may be 
other similar L2 "transport" technologies where its not clear if simple 
ethernet mappings would suffice (bluetooth, wifi,...).

Last but not least, QUIC is on a path to replace TLS and that too puts a dent 
into the belief that TLS as it stands would be a long term stable most-widely 
used protocol.

[ofriel] Its more accurate to say that QUIC is going to replace TCP. QUIC will 
be secured using TLS: https://tools.ietf.org/html/draft-ietf-quic-tls-22


Finally: There is something said to not simply trust a design like TLS which 
you do not really understand just because  its widely used, and thus hopefully 
well reviewed, but rather make sure you have a design based on solid 
understanding of the cryptographic principles employed and a well defined 
review/control process of implementations.  Incidents like with OpenSSL show 
how badly reviewed even the most widely deployed crypto mechanisms can be.

Cheers
Toerless



On Sun, Aug 11, 2019 at 09:31:22PM +, Jack Visoky wrote:
> > but there are significant benefits to not maintaining your own protocols, 
> > and significant benefits to getting the extensive review that TLS gets.
> 
> I could not agree more with this statement.
> 
> Thanks,
> 
> --Jack
> 
> 
> -Original Message-
> From: Michael Richardson 
> Sent: Saturday, August 10, 2019 5:16 PM
> To: Jack Visoky ; Randy Armstrong (OPC) 
> ; iot-onboard...@ietf.org; 
> anima@ietf.org
> Subject: Re: EXTERNAL: Re: [Anima] [Iot-onboarding] OPC and BRSKI
> 
> 
> Jack Visoky  wrote:
> > I am also involved with OPC-UA and would like to provide my/my
> > company's perspective.  One of the major drivers of this engagement
> > with the ANIMA group was a contentious point around whether or not TLS
> > and EST are required for support of BRSKI.  Some of us had taken the
> > position that these technologies are an integral part of BRSKI and
> > shouldn't be replaced with OPC specific methods, especially given the
> > benefit of using highly adopted security technologies, as well as the
> > tight coupling of BRSKI to these.  So, I think the idea that OPC should
> > just use these technologies is very much a viable answer.
> 
> If the device is powered or has enough battery to do 802.11, then it probably 
> has enough power and code space to do TLS (particularly mbedtls from ARM).
> If it's on a very low duty cycle on battery, and/or it does 802.15.4, 
> then the question is still open.  The IETF may start work on a 
> 802.15.4 specific AKE, (see l...@ietf.org).  We believe we need these 
> for 6tisch (TSCH mode of 802.15.4 for deterministic industrial 
> networks)
> 
> It appears that the OPC UA methods provide enough security to do BRSKI, but 
> there are significant benefits to not maintaining your own protocols, and 
> significant benefits to getting the extensive review that TLS gets.
> 
> > Also, I would strongly push back on any claims that low end OPC devices
> > cannot support TLS.  Other industrial protocols have already added TLS
> > support and are shipping products, including those with TLS client
> > functionality.  TLS is no more heavy-weight than existing, OPC-specific
> > security mechanisms.
> 
> The OPC-specific mechanism appears to avoid a DH operation and therefore 
> lacks PFS.  I unde

Re: [Anima] [Iot-onboarding] Device Certificate Deployment Automation with ACME using BRSKI

[Owen Friel (ofriel)]

FYI, Its up on github now:

https://github.com/upros/brski-cloud


From: Anima  On Behalf Of Owen Friel (ofriel)
Sent: 06 August 2019 14:05
To: Rifaat Shekh-Yusef ; anima@ietf.org; 
iot-onboard...@ietf.org
Subject: Re: [Anima] [Iot-onboarding] Device Certificate Deployment Automation 
with ACME using BRSKI

Hi guys,

After the meeting and from corridor conversations with Toerless, I had actually 
already started on such a draft.

What I have started so far is attached. Its not on a public repo yet, but will 
put it there. You are already named on it Rifaat, happy to add you too Michael 
and you can help figure out some of the open redirect options outlined in it ☺

My high level thoughts on this were to keep the ACME specifics out of the 
draft, and use the draft to define the cloud RA behaviour, and the pledge 
behaviour when interacting with the cloud RA, and the various cert, CA, TLS, 
redirect, etc. details. The fact that the RA (whether cloud or local) *may* use 
ACME to talk to the CA is transparent to the pledge.

I was thinking that the ACME specifics could be covered in a different draft 
based on merging draft-yusef-acme-3rd-party-device-attestation and 
draft-friel-acme-integrations, but leave the BRSKI clarifications/specifics in 
this one.

Thoughts?
Owen




From: Iot-onboarding 
mailto:iot-onboarding-boun...@ietf.org>> On 
Behalf Of Rifaat Shekh-Yusef
Sent: 02 August 2019 19:09
To: anima@ietf.org<mailto:anima@ietf.org>; 
iot-onboard...@ietf.org<mailto:iot-onboard...@ietf.org>
Subject: [Iot-onboarding] Device Certificate Deployment Automation with ACME 
using BRSKI

All,

During the last IETF meeting in Montreal we had a side meeting to discuss the
deployment automation of ACME issued certificates to devices, and the potential
use of the BRSKI mechanism to help with this. It was clear from the discussion
that BRSKI can be used to help address this use case, and that further 
discussion is
needed to define the needed enhancements to BRSKI.

The current BRSKI mechanism only briefly discusses the Cloud Registrar option in
section 2.7, which could be used to help address this use case.

Michael Richardson and I had another meeting over lunch yesterday to further
discuss this and we decided to work on a new draft to describe the issue and
define a solution.

Because of vacations and other commitments, we will try to publish the first
version of the draft early October.

Regards,
 Rifaat & Michael
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] [Iot-onboarding] Device Certificate Deployment Automation with ACME using BRSKI

[Owen Friel (ofriel)]

Hi guys,

After the meeting and from corridor conversations with Toerless, I had actually 
already started on such a draft.

What I have started so far is attached. Its not on a public repo yet, but will 
put it there. You are already named on it Rifaat, happy to add you too Michael 
and you can help figure out some of the open redirect options outlined in it ☺

My high level thoughts on this were to keep the ACME specifics out of the 
draft, and use the draft to define the cloud RA behaviour, and the pledge 
behaviour when interacting with the cloud RA, and the various cert, CA, TLS, 
redirect, etc. details. The fact that the RA (whether cloud or local) *may* use 
ACME to talk to the CA is transparent to the pledge.

I was thinking that the ACME specifics could be covered in a different draft 
based on merging draft-yusef-acme-3rd-party-device-attestation and 
draft-friel-acme-integrations, but leave the BRSKI clarifications/specifics in 
this one.

Thoughts?
Owen




From: Iot-onboarding  On Behalf Of Rifaat 
Shekh-Yusef
Sent: 02 August 2019 19:09
To: anima@ietf.org; iot-onboard...@ietf.org
Subject: [Iot-onboarding] Device Certificate Deployment Automation with ACME 
using BRSKI

All,

During the last IETF meeting in Montreal we had a side meeting to discuss the
deployment automation of ACME issued certificates to devices, and the potential
use of the BRSKI mechanism to help with this. It was clear from the discussion
that BRSKI can be used to help address this use case, and that further 
discussion is
needed to define the needed enhancements to BRSKI.

The current BRSKI mechanism only briefly discusses the Cloud Registrar option in
section 2.7, which could be used to help address this use case.

Michael Richardson and I had another meeting over lunch yesterday to further
discuss this and we decided to work on a new draft to describe the issue and
define a solution.

Because of vacations and other commitments, we will try to publish the first
version of the draft early October.

Regards,
 Rifaat & Michael


draft-friel-brski-cloud.md
Description: draft-friel-brski-cloud.md
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] FW: New Version Notification for draft-friel-acme-integrations-01.txt

[Owen Friel (ofriel)]

-Original Message-
From: Anima  On Behalf Of Michael Richardson
Sent: 03 July 2019 23:28
To: anima@ietf.org; Owen Friel (ofriel) 
Cc: Rifaat Shekh-Yusef 
Subject: Re: [Anima] FW: New Version Notification for 
draft-friel-acme-integrations-01.txt


Owen Friel (ofriel)  wrote:
> This early draft
> https://datatracker.ietf.org/doc/draft-friel-acme-integrations/ covers
> how BRSKI could potentially be integrated with an ACME CA for cert
> issuance.

I read it.
While it is certainly true that a BRSKI RA can use ACME to speak to a CA, I'm 
not actually sure what it means from a standards point of view.
[ofriel] Yes, this could maybe be Informational rather than std track. As 
currently written, there are no changes required to BRSKI, EST or ACME drafts, 
so it really is informational on how to stitch these things together. One of 
the interesting things is possisble use of ACME for subdomain certs, which the 
flows for EST, BRSKI and TEAP illustrate, as this is a nice signalling 
optimisation for scaling to large number of clients.

My code base does not connect the RA to LetsEncrypt, but rather uses 
LetsEncrypt to produce IDevIDs from a provisioning process.

I think that you have a problem in STEP 2 (section 3), and STEP 3 (section 4), 
STEP 3 (section 5).

In each place where you post a CSR, you omit the part where you get the 
CSRattributes.  At some point the pledge needs to learn about what the 
delegated domain is ("domain.com").
[ofriel] Sure, it doesn't include all the BRSKI bits. Its also left as a todo 
exactly how the client should determine its domain for inclusion in the CSR if 
it only has its IDevID to start with.

In section 4, the figures (which need to be numbered, btw), is labelled a 
Pledge, but since there is no BRSKI, it should "Client"
[ofriel] For sure, loads of minor nits in -01.


> Related work is
> 
https://datatracker.ietf.org/doc/draft-yusef-acme-3rd-party-device-attestation/,
> which covers how ACME could be used to issue device certs, but does not
> use BRSKI. We are currently discussing offline with Rifaat how we could
> potentially integrate both approaches.

I'll read this.

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

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

[Anima] FW: New Version Notification for draft-friel-acme-integrations-01.txt

[Owen Friel (ofriel)]

All,

This early draft 
https://datatracker.ietf.org/doc/draft-friel-acme-integrations/ covers how 
BRSKI could potentially be integrated with an ACME CA for cert issuance.

What is the WG initial feedback on this idea? I have requested 10mins at 
IETF105 to present/discuss.

Related work is 
https://datatracker.ietf.org/doc/draft-yusef-acme-3rd-party-device-attestation/,
 which covers how ACME could be used to issue device certs, but does not use 
BRSKI. We are currently discussing offline with Rifaat how we could potentially 
integrate both approaches. 

Owen

-Original Message-
From: internet-dra...@ietf.org  
Sent: 02 July 2019 19:50
To: Richard Barnes ; Owen Friel (ofriel) 
Subject: New Version Notification for draft-friel-acme-integrations-01.txt


A new version of I-D, draft-friel-acme-integrations-01.txt
has been successfully submitted by Owen Friel and posted to the IETF repository.

Name:   draft-friel-acme-integrations
Revision:   01
Title:  ACME Integrations
Document date:  2019-07-02
Group:  Individual Submission
Pages:  17
URL:
https://www.ietf.org/internet-drafts/draft-friel-acme-integrations-01.txt
Status: https://datatracker.ietf.org/doc/draft-friel-acme-integrations/
Htmlized:   https://tools.ietf.org/html/draft-friel-acme-integrations-01
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-friel-acme-integrations
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-friel-acme-integrations-01

Abstract:
   This document outlines multiple advanced use cases and integrations
   that ACME facilitates without any modifications or enhancements
   required to the base ACME specification.  These use cases are not
   immediately obvious from reading the ACME specification and thus are
   explicitly documented here.  The use cases include ACME issuance of
   subdomain certificates, and ACME integration with EST and TEAP.


  


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

Re: [Anima] Call for agenda ANIMA @ IETF 105, Montreal

[Owen Friel (ofriel)]

Hi,
I would like a time slot for:

Name of time slot: BRSKI / Afternoon session I
Name of draft(s): draft-friel-acme-integrations
Time requested: 10 mins
Presenter name(s): Owen Friel

And the draft covers how to potentially integrate BRSKI with ACME.

Owen


From: Anima  On Behalf Of Sheng Jiang
Sent: 26 June 2019 10:59
To: anima@ietf.org
Cc: anima-cha...@ietf.org
Subject: [Anima] Call for agenda ANIMA @ IETF 105, Montreal


Hi, all anima,



We have been allocated two sessions of 2 + 1.5 hour for the ANIMA WG meeting 
for IETF-105 (Montreal) - Tuesday Morning session I and Afternoon session I. We 
are now starting to collect agenda items for the sessions. Please send your 
request for agenda by July 11th, Thursday, to 
anima-cha...@ietf.org and both chairs' email. 
Please note that email to a single chair may cause single failure.



For this coming meeting, we would like have the 1.5 hour session for BRSHI and 
Voucher relevant topics and the 2 hour session for the others. As normal, the 
priority among these non-charter work items would be: these that have active 
discussion in mail list, then these have submitted drafts, and topics without 
drafts.



As you may observed, so far, our re-charter progress still not in the 
procedure. Until we have the new charter in the place by the IETF 105 week, we 
still not be able to adopt any new work.



Please send us (anima-chairs at 
ietf.org;) requests 
for time slot by July 11th, Thursday and include:



Name of time slot:

Name of draft(s):

Time requested:

Presenter name(s):



More details about the IETF 105, Montreal can be found at:



https://www.ietf.org/how/meetings/105/



Again, presenters and draft authors please invoke active discussions in the 
ANIMA list. Mail list is a very good place to discuss and reach consensus on 
technical issues.



Best regards,



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

Re: [Anima] Last Call: (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard

[Owen Friel (ofriel)]

Hi,
Late feedback, but its ambiguous in the draft how vendor default Cloud 
Registrar 
https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-20#section-2.7
 and redirects as described in 
https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-20#section-5.6
 should interact.

Should the cloud registrar redirect immediately in response to the voucher 
request, so that the pledge then sends the voucher request via a local domain 
RA?
Should the cloud registrar issue a voucher, and then the redirect happens 
during the EST enrol flow?
When redirected, what trust anchor database should the pledge use?

It seems like:
- the cloud registrar should redirect to the local Registrar immediately and 
not issue a voucher (and this assumes a level of sales channel integration / 
ownership tracking so that the cloud registrar knows which registrar owns the 
pledge)
- the pledge should use the implicit trust anchor database for the initial 
connection to the cloud registrar, but then revert to standard provisional TLS 
connection for the initial connection to the local Registrar
- the pledge may include a proximity-registrar-cert in the new voucher request 
to the local Registrar

Doing the redirect immediately facilitates proximity assertions in the voucher 
request and associated audit logs in the MASA, and allows the MASA to discover 
the local domain CA from the voucher request signature. Maybe a clarifying 
sentence in section 2.7 would help?
Regards,
Owen

-Original Message-
From: Anima  On Behalf Of The IESG
Sent: 21 May 2019 22:21
To: IETF-Announce 
Cc: ibagd...@gmail.com; draft-ietf-anima-bootstrapping-keyin...@ietf.org; 
anima@ietf.org; anima-cha...@ietf.org; tte+i...@cs.fau.de
Subject: [Anima] Last Call:  
(Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard


The IESG has received a request from the Autonomic Networking Integrated Model 
and Approach WG (anima) to consider the following document: - 'Bootstrapping 
Remote Secure Key Infrastructures (BRSKI)'
   as Proposed Standard

This is a second Last Call. IoT Directorate review was done after the ANIMA WG 
Last Call and consensus to request the publication, and that review resulted in 
substantial changes to the document.  

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 2019-06-04. 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


   This document specifies automated bootstrapping of an Autonomic
   Control Plane.  To do this a remote secure key infrastructure (BRSKI)
   is created using manufacturer installed X.509 certificate, in
   combination with a manufacturer's authorizing service, both online
   and offline.  Bootstrapping a new device can occur using a routable
   address and a cloud service, or using only link-local connectivity,
   or on limited/disconnected networks.  Support for lower security
   models, including devices with minimal identity, is described for
   legacy reasons but not encouraged.  Bootstrapping is complete when
   the cryptographic identity of the new key infrastructure is
   successfully deployed to the device but the established secure
   connection can be used to deploy a locally issued certificate to the
   device as well.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ballot/

The following IPR Declarations may be related to this I-D:

   https://datatracker.ietf.org/ipr/2816/
   https://datatracker.ietf.org/ipr/3233/
   https://datatracker.ietf.org/ipr/2463/



The document contains these normative downward references.
See RFC 3967 for additional information: 
rfc8368: Using an Autonomic Control Plane for Stable Connectivity of 
Network Operations, Administration, and Maintenance (OAM) (Informational - IETF 
stream)



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

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

Re: [Anima] [Emu] teap-brski

[Owen Friel (ofriel)]

-Original Message-
From: Emu  On Behalf Of Dan Harkins
Sent: 06 June 2019 15:13
To: anima@ietf.org; e...@ietf.org
Subject: [Emu] teap-brski





  Hello,



  In a private thread on teap-brski the topic of co-location of the TEAP server 
and the BRSKI registrar was brought up. It was suggested that the discussion 
move to these lists to get more input from the experts.



  In draft-lear-eap-teap-brski-02 the architecture shows a the TEAP server and 
the BRSKI registrar as separate while mentioning that they can be co-located.

The following assumes they are not co-located.



  The BRSKI pledge in this draft is called a "device" and the device 
establishes a provisional TLS connection (through TEAP) to the TEAP server over 
802.1X or something similar. The device does not connect to the registrar. The 
device then creates a voucher request and sends it to the TEAP server using a 
newly defined TEAP TLV. The registrar signs the request, forwards it onto a 
MASA, and sends the voucher it gets back from the MASA to the device using 
another newly defined TEAP TLV.



  So the question is, will this even work? If the TEAP server and BRSKI 
registrar are separate entities then the voucher will include the TEAP server's 
EE certificate but it will be signed by the registrar's EE certificate. From my 
admittedly limited understanding of BRSKI I think the MASA will reject this 
voucher request because it fails the "proximity" check (if I understand the 
proximity check correctly). The MASA will treat the registrar as a 
man-in-the-middle.



  BRSKI folks: is this correct? Will a voucher request be rejected from a 
deployment like this?



[ofriel] I believe this will fail the proximity check as outlined in 
https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-20#section-5.5.5



However, there is an interesting definition in 
https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-20#section-3.4



leaf prior-signed-voucher-request {

  type binary;

  description

"If it is necessary to change a voucher, or re-sign and

 forward a voucher that was previously provided along a

 protocol path, then the previously signed voucher SHOULD be

 included in this field.



 For example, a pledge might sign a voucher request

 with a proximity-registrar-cert, and the registrar

 then includes it in the prior-signed-voucher-request field.

 This is a simple mechanism for a chain of trusted

 parties to change a voucher request, while

 maintaining the prior signature information.



 The Registrar and MASA MAY examine the prior signed

 voucher information for the

 purposes of policy decisions. For example this information

 could be useful to a MASA to determine that both pledge and

 registrar agree on proximity assertions. The MASA SHOULD

 remove all prior-signed-voucher-request information when

 signing a voucher for imprinting so as to minimize the

 final voucher size.";

}



Most notable: “This is a simple mechanism for a chain of trusted parties to 
change a voucher request, while maintaining the prior signature information.”



So with some extra definition, one could envisage the TEAP server signing the 
Voucher request using its cert and including the Pledge’s voucher request in 
its prior-signed-voucher-request and sending it to the RA, and then the RA in 
turn signing the request using its own cert, and including the TEAP server’s 
voucher request in its prior-signed-voucher-request. The pledge could also 
assert the TEAP EE cert in its voucher request, with the TEAP server asserting 
the RA’s cert in its voucher request. The MASA could in theory then validate 
the full chain of trust back.



Now, that’s reading a lot into that one statement, and the rest of BRSKI 
certainly doesn’t describe operation like that, and its far easier to mandate 
that the TEAP server *is* the Registrar.







  EMU folks: if the answer from the BRSKI folks is that this doesn't work then 
is there any sort of weird tunneling or "phase 2" trickery that can be added to 
TEAP to get this to work or should we just explicitly state that the TEAP 
server and the registrar are the same entity (they authenticate with the same 
certificate)?



  Thanks,



  Dan.





___

Emu mailing list

e...@ietf.org

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

Re: [Anima] Revision of scope of MASA in the BRSKI - Reg

[Owen Friel (ofriel)]

-Original Message-
From: Anima  On Behalf Of Anoop Kumar Pandey
Sent: Thursday 19 July 2018 05:53
To: 'Michael Richardson' 
Cc: 'Toerless Eckert' ; anima@ietf.org
Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg

>Presenting a certificate of another party doesn't work.
>TLS and other protocols don't just use a certificate, but they use the related 
>private key to sign part of the transaction.

" private key to sign ": That's digital signature. In case of TLS only public 
key is used to encrypt and share the symmetric key which is used in later 
communication. No digital signature required.

[ofriel] https://tools.ietf.org/html/rfc5246#section-7.4.8 and 
https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-4.4.3 explain how 
the client uses its cert private key to sign the TLS handshake transcript. If 
client doesn’t know the private key, it cant generate the CertificateVerify and 
TLS fails.

-Original Message-
From: Michael Richardson [mailto:mcr+i...@sandelman.ca] 
Sent: 17 July 2018 09:20
To: Anoop Kumar Pandey 
Cc: 'Toerless Eckert' ; anima@ietf.org
Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg


Anoop Kumar Pandey  wrote:
> Anyone can present certificate of anyone else (it’s public). That’s
> why I proposed use of digital signature and later verification to
> establish the identity of both JRC and Pledge.

Presenting a certificate of another party doesn't work.
TLS and other protocols don't just use a certificate, but they use the related 
private key to sign part of the transaction.

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



---
[ C-DAC is on Social-Media too. Kindly follow us at:
Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]

This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this email
is strictly prohibited and appropriate legal action will be taken.
---

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

Re: [Anima] Revision of scope of MASA in the BRSKI - Reg

[Owen Friel (ofriel)]

-Original Message-
From: Toerless Eckert  
Sent: Sunday 15 July 2018 18:34
To: Eliot Lear 
Cc: Owen Friel (ofriel) ; Michael Richardson 
; anima@ietf.org
Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg

Eliot:

I think you're trying this type of bootstrap:

https://en.wikipedia.org/wiki/M%C3%BCnchhausen_trilemma#/media/File:Muenchhausen_Herrfurth_7_500x789.jpg

The way to IMHO unconfuse this is to separate out the discussion about how to 
get the voucher, and if at all, how to signal the right SSID to a pledge.
[ofriel] If the pledge is connecting to an 802.1x network behind an SSID, I 
don't think there is any need at all to explicitly tell the pledge the SSID at 
all. There could be multiple different SSIDs (in theory anyway) connecting to 
the same 802.1x network, the key thing is that the voucher tells the pledge to 
trust the EAP server that is it is establishing the TLS connection to. If the 
EAP connection is trusted, then is doesn't really matter which AP or SSID the 
pledge used to get there...

1. A pledge can either try to find his owners AP/SSID and hope that if it gets 
connected to another AP/owner in before, then it will get rejected.  That 
rejection could logically be done in two ways:

a) cooperatively by those other owners knowing what they own
   and rejecting anything else. 
[ofriel] I don't think we can rely on that.

Knowing what they own could have
   a standards protocol but IMHO it should be different from MASA
   because it could come from a reseller, not the manufacturer
   (because the MASA has no sales integration).

b) Some form of sales integration on the MASA so that it would reject
   non-owners. We did not talk about those schemes so far in ANIMA,
   IMHO the most simple sales integration is if there is a protocol
   by which a reseller could indicate to the MASA who owns a particular
   pledge. This transaction would then happen from the vendor as soon
   as it sold the pledge (and knows its serial number). The customer
   would need to provide once its trust anchors to the reseller,
   so they could be passed to the manufacturer by the reseller whenever
   this customer buys new pledges. The reseller could also guarantee
   any form of anonymity required, aka: manufacturer would not know
   who owns the trust anchors (paranoid customers may need to generate
   a bunch of trust anchors so they can not be identified by correlation
   over the set of pledges with the same trust anchor).

Both 1.a and 1.b are trial and error wrt. finding the right SSID. Once can just 
limit search to those SSIDs that do support BRSKI and those who don't by coming 
up with appropriate network announcements, but those will not be able to help 
identifying the right owner.
[ofriel] Agreed. Simple 802.11u/aq/etc. could reduce the number of SSID 
candidates, but its still a round robin by the device if it fails to get a 
voucher when it tried any given SSID candidate.

2. Open but potentially constrained WiFi access allowing to access a 
cloud-registrar. Constrained in so far that the AP operator only support 
passing through BRSKI but not anything else (to avoid providing a free internet 
service).

In this option, a case can be made to provide SSID information to the pledge 
during the voucher stage or after the enrolment stage.
The argument for providing it during the voucher stage is that the pledge could 
earlier break the connection and take the third-party AP and manufacturer cloud 
registrar out of the picture.
[ofriel] If connecting to a cloud-registrar then that pretty much mandates 
strong sales integration and ownership info on the MASA.

The main question is whether we should try to get the SSID passed to the pledge 
in an encrypted fashion so that the manufacturer MASA can not decrypt it. Of 
course, if you trust the manufacturers pledge, you kinda trust the 
manufacturer, but if i was running a MASA in a company of a country with 
perpass agencies, then i would like to define security procedures that would do 
its best to ensure that customers privacy is maximized.
[ofriel] There is an option 3, which is 
https://tools.ietf.org/html/draft-friel-brski-over-802dot11-01#section-2.1.3. 
DPP or any similar protocol where proof-of-ownership is required.

Cheers
Toerless

On Sun, Jul 15, 2018 at 09:38:47AM +0200, Eliot Lear wrote:
> Hi Toerless,
> 
> 
> On 15.07.18 09:19, Toerless Eckert wrote:
> > Note also that we have not defined cloud-registrar behavior. I think 
> > Eliot wold jus like to add something like WiFi SSID to vouchers, but 
> > i would rather like to see it as a separate "next-step after 
> > enrolment" message
> 
> There is an ordering problem with 802.11 in particular.  In order to 
> get the voucher one has to have network connectivity.  In order to 
> have network connectivity, one needs to be authenticated (e.g., having 
> received the voucher).  A

Re: [Anima] Revision of scope of MASA in the BRSKI - Reg

[Owen Friel (ofriel)]

-Original Message-
From: Toerless Eckert  
Sent: Sunday 15 July 2018 08:19
To: Owen Friel (ofriel) 
Cc: Eliot Lear ; Michael Richardson ; 
anima@ietf.org
Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg

Owen,

I've associated draft-friel-brski-over-802dot11 to anima so folks will see it 
in data tracker. Next time post new work for a particular WG with 
draft---, that will make it happen automatically.

2.1.1.1) There is no need to bother the MASA with sales integration just so 
that the owner will know whether or not it owns a particular device. Any 
protocol from the manufacturer/reseller to the owner will suffice.
[ofriel] The point here isn't for the MASA can tell the owner that he owns the 
devices, the purpose is for the owner to explicitly claim the devices on the 
MASA to accomplish your option 1(b) for later in this thread (the thread is 
very disjointed at this stage):
" b) Some form of sales integration on the MASA so that it would reject 
non-owners. "
I think we are actually talking about exactly the same thing here, if that's 
not clear in the draft text, we can certainly clarify.

I recommend carrier pidgeons with USB sticks trained to insert them into a USB 
slot releasing a food portion. Great protection against against unrecognize NSA 
interception of the channel especially for vendors products on the NSA 
shortlist ;-))

Kidding aside: A standard protocol for sales information disemination would be 
great, and given how its for bootstrap automation it would be fine for ANIMA. I 
would jus resist of mixing it with BRSKI/MASA unless there is clear evidence of 
not keeping it modular. Especially given how it cold come from the reseller, 
and nothe vendor.

2.1.1.2) This read a bit confused. I think it should mention two methods: One 
is the aove mentioned to know what you own - independent of MASA (yor last 
sentence in 2.1.1.2 confused this option with the MASA). The other option is 
just to try the MASA in the absence of better information. BUT: If you only try 
the MASA, you should only do this automatically if you do know the MASA has 
sales integation. Otherwise you better include a manual checkpoint before 
enrollment.
[ofriel] Sales integration with the MASA (where sales integration means that 
the MASA explicitly has a map of devices to owners) is not required here at 
all. One of the core features of MASA is that it audit logs all issued vouchers 
and the vouched registrar identity. If a network operator knows the identity of 
a device they own, but that device has not connected to their network, the 
operator can query the MASA audit logs to see if that missing device has been 
vouched for on a different network.

E.g. I own serial#abc123 signed by AcmeCA, I can see it powered up and 
apparently live on the desk beside me, but my Registrar/AAA doesn't see it. My 
Registrar /AAA could query MASA for logs pertaining to serial#abc123 and see 
that a voucher was issued for that device against 
registrar.the-company-on-the-floor-above-me.com. So this does not prevent my 
device from connecting to the wrong network, but it does allow me to detect it 
after the fact.

2.1.2) This section is a bit unmotivated even though its part of the best 
solution, but that solution requires more details than just WiFi.

Aka: You want to allow announcement (using any of the options you specified) of 
open access SSID that allow to connect to cloud-registrars.
These do not even have to be free internet access. Ideally we would think about 
an unencrypted channel to the cloud registrar that relies only on authenticated 
but unencrypted messages. That way the owner of the AP can veryify and 
constrict communications to only cloud-registrar-enrollment so that this access 
is not as a side-channel to gain full internet access. TLS 1.2 still allows 
zero-encryption, that would be the easiest option. TLS 1.3 removed it *sigh*.

Note also that we have not defined cloud-registrar behavior. I think Eliot wold 
jus like to add something like WiFi SSID to vouchers, but i would rather like 
to see it as a separate "next-step after enrolment" message

Cheers
Toerless

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

Re: [Anima] Revision of scope of MASA in the BRSKI - Reg

[Owen Friel (ofriel)]

-Original Message-
From: Anima  On Behalf Of Toerless Eckert
Sent: Tuesday 17 July 2018 00:30
To: Owen Friel (ofriel) 
Cc: Michael Richardson ; anima@ietf.org; Eliot Lear 

Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg

On Mon, Jul 16, 2018 at 08:01:23PM +, Owen Friel (ofriel) wrote:
[ofriel] Are we making the assumption that all networks are well behaved and a 
Registrar will actually reject devices it does not explicitly own? What about a 
rogue network where the operator does not own the connecting devices but the 
registrar accepts them anyway? That is the issue here.

I think Brians comment was abouut fixing BRSKI to re-include text we lost in 
rev -08. The details of that text are not too relevant except IMHO giving some 
examples, as it did in -07.

For the benefit of BRSKI becoming RFC, i would like to really only ask the 
minimum necessary to fix this piece, but not draw it into the larger discussion 
here related to your draft.
[ofriel] Agreed. I think the point Eliot and I are making is that the BRSKI 
draft is fine as is (with that edit Brian pointed out) and does not need to 
explicitly address the Wi-Fi SSID rogue network issue. And its worth pointing 
out that the BRSKI draft does not preclude building a solution for that rogue 
network SSID issue either (we have discussed this at length with Max). The 
draft-friel-brski-over-802dot11 draft starts to touch on some mechanisms for 
how to address the SSID selection issue, and that is a potential place to start 
to document possible solutions.

As you point out, we can never be sure that rogue  domains are not simply 
accepting devices they do not own. But we can build secure pledges by making 
MASA more secure and not hand out vouchers without more than the minimum 
necessary logging. That is not saying that the MASA should do more than just 
logging for every device, for example if the MASA supports both lightbulbs and 
core routers, it's clear that the MASA policies could be different.

And this "sales" integration could be simply that the MASA requires some simple 
identity for a domains registrar. E.g: verify some domains email, credit-card 
number, ... something easily automated and good enough to track back the bad 
guy with enough likelihood.

Cheers
Toerless

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

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

Re: [Anima] Revision of scope of MASA in the BRSKI - Reg

[Owen Friel (ofriel)]

-Original Message-
From: Brian E Carpenter  
Sent: Saturday 14 July 2018 16:20
To: Eliot Lear ; Owen Friel (ofriel) ; Eliot 
Lear ; Michael Richardson ; 
anima@ietf.org
Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg

On 15/07/2018 02:47, Eliot Lear wrote:
> Brian, is it your contention that 802.11 is beyond the scope of 
> autonomic computing?

No, of course not. But autonomic nodes aren't supposed to connect to any old 
WiFi they happen to find; that's exactly the case where secure bootstrap needs 
to fail. If they connect to a network on which there's a registrar that knows 
nothing about them, it won't authorize them to join the ACP.
[ofriel] Are we making the assumption that all networks are well behaved and a 
Registrar will actually reject devices it does not explicitly own? What about a 
rogue network where the operator does not own the connecting devices but the 
registrar accepts them anyway? That is the issue here.

"The domain registrar authenticates the pledge, makes authorization 
decisions,..."

In Figure 3, I guess authorization is the tiny item "[accept device?]".

BRSKI is defined in a nicely general way, but in an AN it's the domain 
registrar's job to decide who's allowed in.
Actually there seems to be a glitch in the text on this.
We find:

> 5.2.  Pledge Requests Voucher from the Registrar
>...
>...The registrar performs authorization as
>detailed in [[EDNOTE: UNRESOLVED.  See Appendix D "Pledge
>Authorization"]]. 

but that leads nowhere that I can find. BRSKI authors, please comment.

   Brian

> 
> 
> On 14.07.18 01:34, Brian E Carpenter wrote:
>> On 13/07/2018 21:26, Owen Friel (ofriel) wrote:
>>> I think its more accurate to state:
>>>
>>> “What a CUSTOMER wants to avoid is a pledge joining a network where the 
>>> MASA just does the logging and does no validation, without any other means 
>>> to determine that the device is on the correct network.” E.g. I plug in a 
>>> wi-fi device and it connects to the SSID of the company on the floor below 
>>> me.
>> That is so far outside the scope of the autonomic networking 
>> infrastructure application of BRSKI that I don't see why we'd even 
>> mention it. It's a case that definitely needs to fail hard in the autonomic 
>> context.
>>
>> If we want to extend the scope of BRSKI to cover BYOD on insecure 
>> WiFi, I think that's for some other WG.
>>
>>Brian
>>
>>> The MASA cannot help with this unless there is complex sales channel 
>>> integration and the MASA explicitly knows in advance exactly what network 
>>> each pledge will be connecting to. A potential option is to also require 
>>> the registrar to provide some proof of ownership to the MASA in the 
>>> VoucherRequest.
>>>
>>> From: Anima  On Behalf Of Eliot Lear
>>> Sent: Thursday 12 July 2018 17:38
>>> To: Michael Richardson ; anima@ietf.org
>>> Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg
>>>
>>>
>>> The problem is that the manufacturer doesn't have enough context to make 
>>> decisions as to which network to join.  That is the challenge.
>>>
>>> On 12.07.18 17:12, Michael Richardson wrote:
>>>
>>>
>>>
>>> Eliot Lear <mailto:l...@cisco.com> wrote:
>>>
>>> > involved. What a manufacturer wants to avoid is a pledge 
>>> joining a
>>>
>>> > network where the MASA just does the logging and does no 
>>> validation,
>>>
>>> > without any other means to determine that the device is on the
>>>
>>> > correct network. Otherwise, the pledge (we could call it the
>>>
>>> > "station" in this context) could simply home to the wrong 
>>> network,
>>>
>>> > and even resetting the device won't get you to the right network.
>>>
>>>
>>>
>>> I don't understand how the "manufacturer" can have a desire ("the 
>>> pledge
>>>
>>> avoid joining a network ...") that is different from the MASA's desire.
>>>
>>>
>>>
>>> The MASA *is* the expression manufacturer's desire.
>>>
>>> If the manufacturer has sales channel information that indicates the 
>>> Pledge
>>>
>>> is on the wrong network, it should not issue a voucher.
>>>
>>>
>>>
>>> So the situation you describe makes no sense to me.
>>>
>>>
>>>
>>>
>>>
>>>
>>> ___
>>>
>>> Anima mailing list
>>>
>>> Anima@ietf.org<mailto:Anima@ietf.org>
>>>
>>> https://www.ietf.org/mailman/listinfo/anima
>>>
>>>
>>>
>>> ___
>>> Anima mailing list
>>> Anima@ietf.org
>>> https://www.ietf.org/mailman/listinfo/anima
>>>
>> ___
>> Anima mailing list
>> Anima@ietf.org
>> https://www.ietf.org/mailman/listinfo/anima
> 
> 

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

Re: [Anima] Revision of scope of MASA in the BRSKI - Reg

[Owen Friel (ofriel)]

I think its more accurate to state:

“What a CUSTOMER wants to avoid is a pledge joining a network where the MASA 
just does the logging and does no validation, without any other means to 
determine that the device is on the correct network.” E.g. I plug in a wi-fi 
device and it connects to the SSID of the company on the floor below me.

The MASA cannot help with this unless there is complex sales channel 
integration and the MASA explicitly knows in advance exactly what network each 
pledge will be connecting to. A potential option is to also require the 
registrar to provide some proof of ownership to the MASA in the VoucherRequest.

From: Anima  On Behalf Of Eliot Lear
Sent: Thursday 12 July 2018 17:38
To: Michael Richardson ; anima@ietf.org
Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg


The problem is that the manufacturer doesn't have enough context to make 
decisions as to which network to join.  That is the challenge.

On 12.07.18 17:12, Michael Richardson wrote:



Eliot Lear  wrote:

> involved. What a manufacturer wants to avoid is a pledge joining a

> network where the MASA just does the logging and does no validation,

> without any other means to determine that the device is on the

> correct network. Otherwise, the pledge (we could call it the

> "station" in this context) could simply home to the wrong network,

> and even resetting the device won't get you to the right network.



I don't understand how the "manufacturer" can have a desire ("the pledge

avoid joining a network ...") that is different from the MASA's desire.



The MASA *is* the expression manufacturer's desire.

If the manufacturer has sales channel information that indicates the Pledge

is on the wrong network, it should not issue a voucher.



So the situation you describe makes no sense to me.






___

Anima mailing list

Anima@ietf.org

https://www.ietf.org/mailman/listinfo/anima

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

Re: [Anima] BRSKI over 802.11

[Owen Friel (ofriel)]

Just submitted: 
https://datatracker.ietf.org/doc/draft-friel-brski-over-802dot11/


-Original Message-
From: Anima [mailto:anima-boun...@ietf.org] On Behalf Of Owen Friel (ofriel)
Sent: Tuesday 27 February 2018 11:06
To: Toerless Eckert ; Michael Richardson 
Cc: Max Pritikin (pritikin) ; anima@ietf.org; Eliot Lear 
(elear) 
Subject: Re: [Anima] BRSKI over 802.11

An early draft of this is now available at:

https://github.com/anima-wg/brski-over-802dot11/blob/master/brski-over-802dot11.md



-Original Message-
From: Toerless Eckert [mailto:t...@cs.fau.de]
Sent: Friday 16 February 2018 18:01
To: Michael Richardson 
Cc: Owen Friel (ofriel) ; Max Pritikin (pritikin) 
; Eliot Lear (elear) ; anima@ietf.org
Subject: Re: [Anima] BRSKI over 802.11

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

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

Re: [Anima] BRSKI over 802.11

[Owen Friel (ofriel)]

An early draft of this is now available at:

https://github.com/anima-wg/brski-over-802dot11/blob/master/brski-over-802dot11.md



-Original Message-
From: Toerless Eckert [mailto:t...@cs.fau.de] 
Sent: Friday 16 February 2018 18:01
To: Michael Richardson 
Cc: Owen Friel (ofriel) ; Max Pritikin (pritikin) 
; Eliot Lear (elear) ; anima@ietf.org
Subject: Re: [Anima] BRSKI over 802.11

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

[Owen Friel (ofriel)]

-Original Message-
From: Michael Richardson [mailto:mcr+i...@sandelman.ca] 
Sent: Thursday 15 February 2018 22:12
To: Owen Friel (ofriel) 
Cc: Toerless Eckert ; anima@ietf.org; Max Pritikin (pritikin) 
; Eliot Lear (elear) 
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 , 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) 
Cc: Michael Richardson ; anima@ietf.org; Max Pritikin 
(pritikin) ; Eliot Lear (elear) 
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 of .11u whose whole purpose is for STAs to make a 

Re: [Anima] BRSKI over 802.11

[Owen Friel (ofriel)]

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

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.


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 of .11u whose whole purpose is for STAs to make a 
decision on which SSID to use based on advertised capabilities, rather than 
SSID naming convention.

Additionally, operators will not want to deploy a new SSID just to enable BRSKI 
flows as each SSID eats up air space and wifi channel capacity due to beacon 
overheads, etc. It would be better to add the relevant bits to the AQNP for an 
existing SSID. From the operator perspective, that's modifying the config of an 
existing SSID rather than deploying a new one.

2. Leverage existing 802.11u

It appears as if NAI Realm could be a possible mechanism for advertising BRSKI 
capability (and Roaming consortium, 3GPP cellular network are not). We could 
possibly piggy back on top of NAI Realm and advertise a realm of simply 
"_bootstrapks". WLCs certainly appear to allow this kind of configuration 
(although today some WLCs tie .11u configuration to HS2.0 configuration i.e. 
you cannot enable advertising 802.11u bits without also advertising HS2.0 in 
Beacons - but thats a WLC implementation gap not a standards gap).

The key conceptual difference is that we are using this special realm name more 
as a logical service advertisement rather than as a backhaul internet provider 
advertisement. This would not require any 802.11 IEEE spec changes, but could 
fall into the realm of IETF spec definition. i.e. if you configure your 
existing wifi network using existing 802.11u mechanisms to advertise this NAI 
Realm, then IoT devices will know that this SSID offers BRSKI services.

Additionally (or alternatively...) as NAI Realm includes advertising the EAP 
mechanism required, if a new EAP-BRSKI were to be defined, then this could be 
advertised. STAs could just scan for an NAI Realm that enforced EAP-BRSKI, and 
ignore the realm name.

One big issue with this is Eliot's point about "a business in an office 
building on the 10th floor in New York City or London, where you might hear 2 
dozen different networks". The STA ends up scanning a lot of SSIDs, and it may 
find multiple SSIDs that advertise EAP-BRSKI or NAI Realm "_bootstrapks". It 
would have to attempt to join all of them in sequence, and rely on the operator 
configuring their network such that the manufacturer IDevID CA or the specific 
IDevID is not trusted and rejects the device. It could also result in the STA 
joining the wrong SSID, which would not be ideal.

3. Define new 802.11u extensions

Similar to HS2.0, we define a new BRSKI Indication Element that is advertised 
in Beacons,