Subject: [saag] EAP-NOOB

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 7 Apr 2016 20:19:33 +0200

I just wanted to explain my comments from the SAAG session regarding the
EAP-NOOB talk today.

(1.) Not every network uses EAP

For example, EAP is not used in IEEE 802.15.4, Bluetooth Low Energy, or
low power WANs

It is also not used in home networks that use WiFi.

(2.) Many radio / link layer technologies provide a solution for onboarding*

Cellular technologies use manufacturer-provided credentials, often using
SIM cards, and maybe in the future use soft-SIMs.

Bluetooth Low Energy uses a pairing procedure in various flavors.

Thread (for use with IEEE 802.15.4) uses J-PAKE.

So, either they use manufacturer provided secrets or an approach where
keys are provisioned later (by the customer or professionals). You often
see that the term 'installer' or 'commissioning tool' being used for
this task.

For use with WiFi various companies have also released some of these
'commission tools'. They often use some short range radio technology to
provision the WiFi credentials and other configuration information.

3. Consumer environments are different from industrial usage

In industrial environments you typically have dedicated staff to help
with the installation (because you often have to do more than just to
provision the secrets). For example, in commercial indoor lighting you
have various parties responsible for wiring, installing the fixtures,
the light design, the installation and configuration, etc.

In the home environment you often have no 'administrator' and no server
infrastructure available. Some companies today rely more on the end
consumer having a smart phone or tablet that can be used as the
"installer".

4. There are two types of credentials in use, namely (a) network access
credentials and (b) application layer credentials

IoT devices almost always come with pre-configured application layer
service credentials. So, you do not need to touch those.

So, I am arguing that you have to think carefully about
 * what radio technology you consider,
 * what deployment environment we are talking about (and what the
constraints are), and
 * there are lots of solutions out there. We might be able to re-use
those instead of creating a new one.

Ciao
Hannes

*: I use the term 'onboarding' to refer to the process of putting
credentials and configuration to a device. Onboarding can happen at
various stages throughout the lifetime of the device.

Bootstrapping is, on the other hand, used to create/distribute keys to
new parties based on already existing keys. For example, Kerberos would
do such a bootstrapping between a client and a server based on already
existing keys established between the client and the KDC and the server
and the KDC.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 7 Apr 2016 11:24:44 -0700

Hannes said:

"For example, Kerberos would
do such a bootstrapping between a client and a server based on already
existing keys established between the client and the KDC and the server
and the KDC."

[BA] As far as I know, there is no deployed usage of Kerberos-based EAP
authentication.  The major issue is that a host typically does not have
Internet access prior to completing EAP authentication, so that Kerberos
would need to be integrated with EAP in order for Kerberos tickets to be
obtained.

On Thu, Apr 7, 2016 at 11:19 AM, Hannes Tschofenig <
[email-masked]> wrote:

> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 7 Apr 2016 20:26:29 +0200

Hey Bernard,

the example of Kerberos was unrelated to EAP. It was just to clarify the
terminology of what bootstrapping means. For some reason, the IoT
community created this term and we have been using key distribution
typically instead.

Ciao
Hannes

On 04/07/2016 08:24 PM, Bernard Aboba wrote:
> On Thu, Apr 7, 2016 at 11:19 AM, Hannes Tschofenig
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     [email-masked] <mailto:[email-masked]>

---

From: "Henry B (Hank) Hotz, CISSP" <[email-masked]>
Date: Thu, 7 Apr 2016 19:44:29 -0700

> On Apr 7, 2016, at 11:24 AM, Bernard Aboba <[email-masked]> wrote:
> 
> Hannes said: 
> 
> [BA] As far as I know, there is no deployed usage of Kerberos-based EAP authentication.  The major issue is that a host typically does not have Internet access prior to completing EAP authentication, so that Kerberos would need to be integrated with EAP in order for Kerberos tickets to be obtained. 

I would love to hear that statement proved wrong. There is (was) a GSS-EAP draft. AFAIK (I haven’t read it) it primarily provided for tunneling the Kerberos messages via EAP. 

Is there still insufficient interest in creating such a thing?

> On Thu, Apr 7, 2016 at 11:19 AM, Hannes Tschofenig <[email-masked]> wrote:

Personal: [email-masked]
Business: [email-masked]
https://www.linkedin.com/in/hbhotz/

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 8 Apr 2016 16:37:28 -0400 (EDT)

> Is there still insufficient interest in creating such a thing?

draft-ietf-abfab-gss-eap became RFC 7055, and my understanding is that the
authors do have it deployed in production, though probably (mostly?) with
a non-kerberos GSS mechanism.

The IAKERB GSS mechanism (draft-ietf-kitten-iakerb) provides a way to have
the GSS acceptor proxy kerberos messages between the GSS initiator and the
KDC, which would permit an EAP client to obtain initial kerberos
credentials during the process of authenticating to EAP.  IAKERB is
implemented in MIT krb5, though I do not actually know of anyone deploying
it with GSS-EAP.

-Ben