Subject: Re: [saag] Fwd: New Version Notification for draft-aura-eap-noob-00.txt

From: Aura Tuomas <[email-masked]>
Date: Thu, 3 Mar 2016 09:19:56 +0000

Hi Josh,

I think I got your point. There are two questions here.

The first is about who will manage the AAA server for the devices. We have primarily thought it will be the user organization, which may outsource the authentication and authorization to a third party of their choice. You seem to be thinking that the device vendors will run the AAA server for their own devices. Both scenarios are certainly possible. The vendor-specific solution would not necessarily even need standard for the EAP method because it could be specified by the vendor alone. We have focused on the scenario where the AAA server is not necessarily the device vendor, and a standard for interoperability is needed.

The second question is whether all the devices in the same user organization should be handled by one AAA server, or if there should be multiple classes of devices that are handled by different AAA servers. Adding support for device classes, e.g. as subdomains "XXX.eap-noob.net", is certainly possible. We'll think about this. I'm not sure about the extra complexity that it will create.

Tuomas

Lähettäjä: Josh Howlett [mailto:[email-masked]]
Lähetetty: Monday, 29 February, 2016 23:29
Vastaanottaja: Mohit Sethi <[email-masked]>; Aura Tuomas <[email-masked]>; [email-masked]
Aihe: RE: [saag] Fwd: New Version Notification for draft-aura-eap-noob-00.txt

Hi Mohit,

Thanks, but I still don't follow the use case. I thought the draft is trying to address the scenario where I have devices from multiple vendors wanting to register themselves against each vendors' systems (e.g., my fridge registers with my fridge vendor's AAA server; my washing machine with my washing machine vendor's AAA server; etc.). How does my NAS know how to forward a request to the correct realm if each request is using the same realm?

Josh.

From: Mohit Sethi [mailto:[email-masked]]
Sent: 29 February 2016 17:10
To: Josh Howlett <[email-masked]<mailto:[email-masked]>>; Aura Tuomas <[email-masked]<mailto:[email-masked]>>; Mohit Sethi <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [saag] Fwd: New Version Notification for draft-aura-eap-noob-00.txt

Hi Josh

Thanks again for your useful questions.

1. The requests for "eap-noob.net" would either be served by a local AAA server or a remote AAA server for which a forwarding rule has been added. The request would not be forwarded to a global server based on DNS lookups. Hence, a DNS lookup for eap-noob.net is expected to respond with NXDOMAIN.

2. The need for the special purpose realm is to allow devices from any manufacturer to be directed to the AAA server of your choice. You only need setup the server or add the forwarding once for all the devices from any manufacturer. Not everyone wants to depend on the device vendor's AAA service for security.Besides, depending on a vendor service may not be always safe. As Stephen had pointed out in another mail thread (https://www.ietf.org/mail-archive/web/ace/current/msg01470.html), commercial devices will be end-of-lifed by vendors, and yet they still need to be functional for the owner.

/--Mohit
On 02/18/2016 09:05 PM, Josh Howlett wrote:
Sorry, ignore question 3, it makes no sense here.

From: Josh Howlett<mailto:[email-masked]>
Sent: 18 February 2016 18:47
To: Aura Tuomas<mailto:[email-masked]>; Mohit Sethi<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [saag] Fwd: New Version Notification for draft-aura-eap-noob-00.txt

Hi Aura,

A couple of other questions on the deployment theme:

1.       How would requests towards the single special people realm get disambiguated among the multiple AAA servers?

2.       In fact, what's the need for this special purpose realm at all - why not let the vendor burn one into the firmware, and use an intermediate AAA routing fabric do the AAA server discovery?

3.       Why this and not WPS (or something similar?)

Josh.

Sent from Outlook Mail<https://go.microsoft.com/fwlink/?LinkId=550987> for Windows 10 phone

From: Aura Tuomas<mailto:[email-masked]>
Sent: 18 February 2016 18:07
To: Josh Howlett<mailto:[email-masked]>; Mohit Sethi<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [saag] Fwd: New Version Notification for draft-aura-eap-noob-00.txt

Hi Josh,

Good observation; we may need to be clearer about the intended usage scenarios for EAP-NOOB.

In the home setting, the AAA server would typically be a cloud-based service, where the consumer can register a user account. This does require the 802.1X authentication (i.e. WPA2-Enterprise) to be configured at the home NAS, so that authentication for "@eap-noob.net" is forwarded to the cloud-based AAA server. You only need to configure the NAS once, and all future devices can be connected without touching the NAS.

This is a change from the way home wireless routers are configured today. We think that, as the number of IoT devices grows, configuring them with a shared passphrase will be too inconvenient. Obviously, the shared passphrase is also vulnerable to a single untrusted IoT device that may leak the passphrase, and using EAP helps to isolate the devices.

Of course, the benefits of EAP-NOOB will be greater in organizations which already use 802.1X authentication and which have larger numbers of IoT devices than a single home.

Anything else that we need to address?

Tuomas

-----Original Message-----
From: Josh Howlett [mailto:[email-masked]]
Sent: Thursday, 18 February, 2016 19:28
To: Mohit Sethi <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Aura Tuomas <[email-masked]><mailto:[email-masked]>
Subject: RE: [saag] Fwd: New Version Notification for draft-aura-eap-noob-00.txt

Hi Mohit,

This is an interesting draft, but I'm struggling to understand how this would be deployed in the consumer settings that the document alludes to. For example, who do you anticipate will be operating the NAS (the consumer?), AAA server (the vendor?), and the AAA fabric between these actors?

Josh.

> -----Original Message-----
> From: saag [mailto:[email-masked]] On Behalf Of Mohit Sethi
> Sent: 08 February 2016 15:34
> To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>
> Subject: [saag] Fwd: New Version Notification for
> draft-aura-eap-noob-00.txt
>
> Dear all
>
> We have just submitted a new IETF Draft titled "Nimble out-of-band
> authentication for EAP (EAP-NOOB)".
>
> The draft defines an EAP method where the authentication is based on a
> user-assisted out-of-band (OOB) channel between the server and peer.
> It is intended as a generic bootstrapping solution for
> Internet-of-Things devices which have no pre-configured authentication
> credentials and which are not yet registered on the authentication
> server. Consider devices you just bought or borrowed.
>
> The EAP-NOOB method is more generic than most ad-hoc bootstrapping
> solutions in that it supports many types of OOB channels. We specify
> the exact in-band messages but only the OOB message contents and not
> the OOB channel details. Also, EAP-NOOB supports ubicomp devices with
> only output (e.g. display) or only input (e.g. camera). Moreover, it
> makes combined use of both secrecy and integrity of the OOB channel
> for more robust security than the ad-hoc solutions. We have put a lot
> of effort into designing a robust security protocol.
>
> For one application example, we have used an earlier version of the
> protocol for bootstrapping security for ubiquitous displays: the user
> can configure wireless network access, link the device to a cloud
> service, and register ownership of the device for a specific cloud
> user - all in one simple step of scanning a QR code with a smart
> phone. There seemed to more potential to this idea than just using it
> for our own system, and thus we decided to write a generic EAP method for out-of-band authentication.
>
> The draft is available here:
> https://tools.ietf.org/html/draft-aura-eap-noob-00
>
> Please see if you can make use of it. We look forward to your feedback
> and comments.
>
> Regards
> /--Mohit
>
>
> -------- Forwarded Message --------
> Subject:       New Version Notification for draft-aura-eap-noob-00.txt
> Date:  Mon, 08 Feb 2016 04:30:35 -0800
> From:  [email-masked]<mailto:[email-masked]>
> To:    Tuomas Aura <[email-masked]><mailto:[email-masked]>, Mohit Sethi
> <[email-masked]><mailto:[email-masked]>
>
>
>
> A new version of I-D, draft-aura-eap-noob-00.txt has been successfully
> submitted by Tuomas Aura and posted to the IETF repository.
>
> Name:         draft-aura-eap-noob
> Revision:     00
> Title:                Nimble out-of-band authentication for EAP (EAP-NOOB)
> Document date:        2016-02-08
> Group:                Individual Submission
> Pages:                35
> URL:https://www.ietf.org/internet-drafts/draft-aura-eap-noob-00.txt
> Status:https://datatracker.ietf.org/doc/draft-aura-eap-noob/
> Htmlized:https://tools.ietf.org/html/draft-aura-eap-noob-00
>
>
> Abstract:
>     Extensible Authentication Protocol (EAP) [RFC3748] provides support
>     for multiple authentication methods.  This document defines the EAP-
>     NOOB authentication method for nimble out-of-band (OOB)
>     authentication and key derivation.  This EAP method is intended for
>     bootstrapping all kinds of Internet-of-Things (IoT) devices that have
>     a minimal user interface and no pre-configured authentication
>     credentials.  The method makes use of a user-assisted one-directional
>     OOB channel between the peer device and authentication server.
>
>
>
>
> 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
>
>
>
> _______________________________________________
> saag mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/saag

Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc's registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.

Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.

_______________________________________________

saag mailing list

[email-masked]<mailto:[email-masked]>

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

---

From: Josh Howlett <[email-masked]>
Date: Thu, 3 Mar 2016 10:17:30 +0000

Hi Tuomas,

I think it would be really helpful if you documented the intended deployment ecosystem at a high level (consumer, enterprise, vendor, AAA providers, etc.) and how these map to the protocol actors. I think the lack of a model results in ambiguity (at least in my own mind) as to how this could or should be deployed. You might want to do this in a separate document.

The Introduction also points to the need for establishment of "credentials for [...] authentication-security". The draft doesn't appear to address this requirement. Is this intentional?

Josh.

From: Aura Tuomas [mailto:[email-masked]]
Sent: 03 March 2016 09:20
To: Josh Howlett <[email-masked]>; Mohit Sethi <[email-masked]>; [email-masked]
Subject: VS: [saag] Fwd: New Version Notification for draft-aura-eap-noob-00.txt

Hi Josh,

Tuomas

Lähettäjä: Josh Howlett [mailto:[email-masked]]
Lähetetty: Monday, 29 February, 2016 23:29
Vastaanottaja: Mohit Sethi <[email-masked]<mailto:[email-masked]>>; Aura Tuomas <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Aihe: RE: [saag] Fwd: New Version Notification for draft-aura-eap-noob-00.txt

Hi Mohit,

Josh.

Hi Josh

/--Mohit

Hi Aura,

Josh.

Hi Josh,

Tuomas

-----Original Message-----
From: Josh Howlett [mailto:[email-masked]]
Sent: Thursday, 18 February, 2016 19:28
To: Mohit Sethi <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Aura Tuomas <[email-masked]><mailto:[email-masked]>
Subject: RE: [saag] Fwd: New Version Notification for draft-aura-eap-noob-00.txt

Hi Mohit,

Josh.

saag mailing list

---

From: Mohit Sethi <[email-masked]>
Date: Mon, 7 Mar 2016 17:47:16 +0200

Hi Josh

Thanks for the suggestion. It is a good idea to document the ecosystem 
assumptions. When writing about our own ideas it is easy to think that 
the design assumptions are obvious.

Regarding credentials for authentication, OOB authentication is an 
alternative to pre-established credentials. The secure channel created 
with OOB authentication could be used for setting up other credentials, 
such as a device certificate, but doing that is outside our protocol.

/--Mohit

On 03/03/2016 12:17 PM, Josh Howlett wrote:
>
> Hi Tuomas,
>
> I think it would be really helpful if you documented the intended 
> deployment ecosystem at a high level (consumer, enterprise, vendor, 
> AAA providers, etc.) and how these map to the protocol actors. I think 
> the lack of a model results in ambiguity (at least in my own mind) as 
> to how this could or should be deployed. You might want to do this in 
> a separate document.
>
> The Introduction also points to the need for establishment of 
> “credentials for […] authentication-security”. The draft doesn’t 
> appear to address this requirement. Is this intentional?
>
> Josh.
>
> *From:*Aura Tuomas [mailto:[email-masked]]
> *Sent:* 03 March 2016 09:20
> *To:* Josh Howlett <[email-masked]>; Mohit Sethi 
> <[email-masked]>; [email-masked]
> *Subject:* VS: [saag] Fwd: New Version Notification for 
> The first is about who will manage the AAA server for the devices. We 
> have primarily thought it will be the user organization, which may 
> outsource the authentication and authorization to a third party of 
> their choice. You seem to be thinking that the device vendors will run 
> the AAA server for their own devices. Both scenarios are certainly 
> possible. The vendor-specific solution would not necessarily even need 
> standard for the EAP method because it could be specified by the 
> vendor alone. We have focused on the scenario where the AAA server is 
> not necessarily the device vendor, and a standard for interoperability 
> is needed.
>
> The second question is whether all the devices in the same user 
> organization should be handled by one AAA server, or if there should 
> be multiple classes of devices that are handled by different AAA 
> servers. Adding support for device classes, e.g. as subdomains 
> “XXX.eap-noob.net”, is certainly possible. We’ll think about this. I’m 
> not sure about the extra complexity that it will create.
>
> Tuomas
>
> *Lähettäjä:*Josh Howlett [mailto:[email-masked]]
> *Lähetetty:* Monday, 29 February, 2016 23:29
> *Vastaano**ttaja:*Mohit Sethi <[email-masked] 
> <mailto:[email-masked]>>; Aura Tuomas 
> <[email-masked] <mailto:[email-masked]>>; [email-masked] 
> <mailto:[email-masked]>
> *Aihe:* RE: [saag] Fwd: New Version Notification for 
> Thanks, but I still don’t follow the use case. I thought the draft is 
> trying to address the scenario where I have devices from multiple 
> vendors wanting to register themselves against each vendors’ systems 
> (e.g., my fridge registers with my fridge vendor’s AAA server; my 
> washing machine with my washing machine vendor’s AAA server; etc.). 
> How does my NAS know how to forward a request to the correct realm if 
> each request is using the same realm?
>
> Josh.
>
> *From:*Mohit Sethi [mailto:[email-masked]]
> *Sent:* 29 February 2016 17:10
> *To:* Josh Howlett <[email-masked] 
> <mailto:[email-masked]>>; Aura Tuomas <[email-masked] 
> <mailto:[email-masked]>>; Mohit Sethi 
> <[email-masked] <mailto:[email-masked]>>; 
> [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [saag] Fwd: New Version Notification for 
> 1. The requests for "eap-noob.net" would either be served by a local 
> AAA server or a remote AAA server for which a forwarding rule has been 
> added. The request would not be forwarded to a global server based on 
> DNS lookups. Hence, a DNS lookup for eap-noob.net is expected to 
> respond with NXDOMAIN.
>
> 2. The need for the special purpose realm is to allow devices from any 
> manufacturer to be directed to the AAA server of your choice. You only 
> need setup the server or add the forwarding once for all the devices 
> from any manufacturer. Not everyone wants to depend on the device 
> vendor's AAA service for security.Besides, depending on a vendor 
> service may not be always safe. As Stephen had pointed out in another 
> mail thread 
> (https://www.ietf.org/mail-archive/web/ace/current/msg01470.html), 
> commercial devices will be end-of-lifed by vendors, and yet they still 
> need to be functional for the owner.
>
> /--Mohit
>
>     *From: *Josh Howlett <mailto:[email-masked]>
>     *Sent: *18 February 2016 18:47
>     *To: *Aura Tuomas <mailto:[email-masked]>; Mohit Sethi
>     <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
>     *Subject: *Re: [saag] Fwd: New Version Notification for
>     1.How would requests towards the single special people realm get
>     disambiguated among the multiple AAA servers?
>
>     2.In fact, what’s the need for this special purpose realm at all –
>     why not let the vendor burn one into the firmware, and use an
>     intermediate AAA routing fabric do the AAA server discovery?
>
>     3.Why this and not WPS (or something similar?)
>
>     Josh.
>
>     Sent from Outlook Mail
>     <https://go.microsoft.com/fwlink/?LinkId=550987> for Windows 10 phone
>
>     *From: *Aura Tuomas <mailto:[email-masked]>
>     *Sent: *18 February 2016 18:07
>     *To: *Josh Howlett <mailto:[email-masked]>; Mohit Sethi
>     <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
>     *Subject: *RE: [saag] Fwd: New Version Notification for
>     In the home setting, the AAA server would typically be a
>     cloud-based service, where the consumer can register a user
>     account. This does require the 802.1X authentication (i.e.
>     WPA2-Enterprise) to be configured at the home NAS, so that
>     authentication for "@eap-noob.net" is forwarded to the cloud-based
>     AAA server. You only need to configure the NAS once, and all
>     future devices can be connected without touching the NAS.
>
>     This is a change from the way home wireless routers are configured
>     today. We think that, as the number of IoT devices grows,
>     configuring them with a shared passphrase will be too
>     inconvenient. Obviously, the shared passphrase is also vulnerable
>     to a single untrusted IoT device that may leak the passphrase, and
>     using EAP helps to isolate the devices.
>
>     Of course, the benefits of EAP-NOOB will be greater in
>     organizations which already use 802.1X authentication and which
>     have larger numbers of IoT devices than a single home.
>
>     To: Mohit Sethi <[email-masked]>
>     <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
>     Cc: Aura Tuomas <[email-masked]> <mailto:[email-masked]>
>     This is an interesting draft, but I'm struggling to understand how
>     this would be deployed in the consumer settings that the document
>     alludes to. For example, who do you anticipate will be operating
>     the NAS (the consumer?), AAA server (the vendor?), and the AAA
>     fabric between these actors?
>
>     Josh.
>
>     > To: [email-masked] <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>
>     > Cc: [email-masked] <mailto:[email-masked]>
>     > We have just submitted a new IETF Draft titled “Nimble out-of-band
>     > authentication for EAP (EAP-NOOB)”.
>     >
>     > user – all in one simple step of scanning a QR code with a smart
>     > From: [email-masked] <mailto:[email-masked]>
>     > To:    Tuomas Aura <[email-masked]>
>     <mailto:[email-masked]>, Mohit Sethi
>     > <[email-masked]> <mailto:[email-masked]>
>     >
>     >
>     >
>     > [email-masked] <mailto:[email-masked]>
>     Jisc is a registered charity (number 1149740) and a company
>     limited by guarantee which is registered in England under Company
>     No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is:
>     One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
>
>     Jisc Services Limited is a wholly owned Jisc subsidiary and a
>     company limited by guarantee which is registered in England under
>     company number 2881024, VAT number GB 197 0632 86. The registered
>     office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203
>     697 5800.
>
>     [email-masked] <mailto:[email-masked]>
>