Re: [Emu] AD Review: draft-ietf-emu-noob-03

[Aura Tuomas]

Hi Roman,

Thank you for your review. We have made the necessary changes and published 
version -04. I have also explained the changes made in-line below. Hopefully, 
the draft is now ready for the next steps.

Regards,
Tuomas


 Forwarded Message  
Subject:[Emu] AD Review: draft-ietf-emu-noob-03
Date:   Sun, 7 Mar 2021 13:33:59 +
From:   Roman Danyliw 

To: emu@ietf.org 



Hi!

I performed an AD review on draft-ietf-emu-noob-03. Thanks for the work on this 
document -- in particular for providing copious examples in the Appendix; and 
co-developing this text with the implementations and the proofs.

** Section 3.2.3. Per "The OOB receiver MUST compare the received value of the 
fingerprint Hoob ...", perhaps overly pedantic, it would be worth mentioning 
that this is compared relative to the expected PeerId + Hoob.

Tuomas: Added  "The OOB receiver MUST compare the received value of the 
fingerprint Hoob (see Section 3.3.2) with a value that it computes locally for 
the PeerID received."


** Section 3.4.2 and Section 6.6. I wanted to talk through the expected 
implementation logic around the downgrade protection in the check during the 
cryptosuite upgrade. Specifically:

(a) Section 3.4.2. The server SHOULD NOT offer and the peer MUST NOT accept
protocol versions or cryptosuites that it knows to be weaker than the
one currently in the Cryptosuitep field of the persistent EAP-NOOB
association.

(b) Section 6.6. As long as
the server or peer saves any information about the other endpoint, it
MUST also remember the previously negotiated cryptosuite and MUST NOT
accept renegotiation of any cryptosuite that is known to be weaker
than the previous one, such as a deprecated cryptosuite.

To make sure I understand that right, let's say I registered cryptosuite = 3 as 
"ECDHE curve Curve25519 + SHA-512". If the peer initially used this new 
cryptosuite=3 and later tried to negotiate the current cryptosuite=1, this 
should fail because SHA-256 is weaker than SHA-512? What about the situation of 
hypothetical cryptosuite = 4 as "fancy new PQ-resistant algo + SHA-256"? 
No issues with the suggested design, but perhaps we should further caveat 
somewhere in the document by adding language that determining the relative 
strength of the cryptosuites is out of scope and may be managed through local 
policy or configuration.

Tuomas: Yes, thank you for raising this. We have added: "Determining the 
relative strength of the cryptosuites is out of scope and may be managed 
through local policy or configuration at the peer and server." 


** Section 4. Per "The EAP Method Type number for EAP-NOOB needs to be 
assigned", can the explicit registry name for this be explicitly named.

Tuomas: We now call out the registry name explicitly. We realized that all the 
new registries created should also have explicit names. We have made the 
necessary changes. 


** Section 4.1. Per "public-key format [RFC7517] Section 6.2.1" in both 
cryptosuites, RFC5717 doesn't have a Section 6.2.1.

Tuomas: Good catch. This is a remanent from when the text was pointing to 
section 6.2.1 of RFC 7518. Fixed.


** Section 5.4. Editorial. Please add the model URLs as a reference instead of 
a bare URL

Tuomas: The URLs are now informational references. 


** Section 5.4, 6.1, 6.2, 6.6, Appendix E. In the spirit of inclusive language, 
please consider: s/man-in-the-middle/on-path/

** Section 6.5. In the spirit of inclusive language, please consider: 
s/blacklist misbehaving peer devices/add misbehaving peer devices to a deny 
list/

Tuomas: We have now made the appropriate terminology changes.


** Appendix C. Per "Table 11 lists some suggested data fields for ServerInfo. 
Further specifications may specify application- specific ServerInfo and 
PeerInfo contents.":

-- I would recommend tuning the guidance to make it clear that if these fields 
names are used in any OOB-enabled application their semantics will be as 
defined here (I stumbled over calling these "suggested data fields").

NEW:
Table 11 defines commonly used data fields for ServerInfo. Further 
specifications may define additional application-specific ...

-- Is there an EAP reference to describe handle unknown fields?

Tuomas: Error types 5002 and 5004 handle the cases where ServerInfo and 
PeerInfo have unknown fields. 


-- Did the WG discuss/consider defining an IANA registry to manage the 
Peer/ServerInfo fields to ensure there are clear pointers to their semantics?

Tuomas: This is was something briefly eluded to by the IoT directorate review 
of Dave Thaler. Based on Dave's recommendation, we had added a type tag. We 
consulted RFC 8216 again and like your recommendation of making the PeerInfo 
and ServerInfo semantics clearer with an IANA registry. We were initially 
hesitant but 'specification required' is flexible enough to not prevent new 
applications of EAP-NOOB from defining new data fields. PeerInfo and ServerInfo 
are now IANA 

Re: [Emu] Working Group Last Call for draft-ietf-emu-eap-noob-02

[Aura Tuomas]

Alan, thank you for your review!

We had not thought about the collisions of uft8-username within the realm. 
After some discussion, the best solution seemst to be to let the server assign 
a full NAI instead of just the Realm. This is the only significant change made 
to the new draft 3. 

Tuomas


-Original Message-
From: Emu  On Behalf Of Alan DeKok
Sent: torstai 3. joulukuuta 2020 15:23
To: Joseph Salowey 
Cc: EMU WG 
Subject: Re: [Emu] Working Group Last Call for draft-ietf-emu-eap-noob-02
Importance: High



> On Nov 21, 2020, at 6:31 PM, Joseph Salowey  wrote:
> 
> At  IETF 109 meeting there was support for moving EAP-NOOB forward.  The 
> chairs and authors believe the document is ready to progress so this starts 
> the working group last call for EAP-NOOB [1].   Please review the document 
> and send comments to the list by December 11, 2020.  Statements of support or 
> opposition are welcome especially if accompanied with reasons for the 
> position.  

  I support publication of this document.

NITs:

  Section 3.3.1 says "The default realm for the peer is "eap-noob.arpa".

  But the diagram in 3.2.1 has:  (NAI=n...@eap-noob.net)
  I suggest using "arpa" instead of "net".


  Section 3.3.1 says "The peer MUST copy the PeerId byte-by-
   byte from the message where it was allocated, and the server MUST
   perform a byte-by-byte comparison"

  It's a little odd to talk about "byte-by-byte".  Perhaps just "copy the 
PeerID", and "the server must verify that the PeerID exactly matches ..."

  
  Section 3.3.1 also discusses a "server-assigned realm".  But there seems to 
be no guidance on which realm to use.  Since this specification also mandates 
the use of a particular utf8-username "noob", there is a potential conflict 
with existing users.

  It may be useful to suggest the use of a sub-realm, specifically used for 
EAP-NOOB, e.g. "noob.example.net".  Allowing a sub-realm for noob means that 
administrators can select an otherwise unused realm, and assign it specifically 
for use with EAP-NOOB.

  That can cause issues with roaming, however.  Roaming systems match on 
realms, and may not always be capable of matching on variants of realms.  So if 
they allow "example.net", they may not be capable of processing 
"noob.example.net".   RFC 7542 Section 3 "Routing inside of AAA Systems" is 
silent on this topic, while Eduroam allows sub-realms.

  My suggestion is that the document should recommend the use of noob-specific 
sub-realms, and then admit that this might cause issues in some roaming 
environments.  That trade-off is acceptable, I think.  Most roaming systems 
which cannot handle sub-realms will likely not be using EAP-NOOB.


  Appendix E says:

  PeerId is provided to the peer by the server and
   might be a 22-character ASCII string. 

  I think it's best to just refer to Section 3.3.1, for the format of the 
PeerId.  And then note that the construction in Section 3.3.1 is compatible 
with HTTP, and does not require escaping.

  Alan DeKok.

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

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

Re: [Emu] [Iot-directorate] Iotdir early review of draft-ietf-emu-eap-noob-01

[Aura Tuomas]

I understand the issues that have been discussed: (1) feature completeness of 
the specification, (2) availability of implementations, and (3) compactness of 
the binary encoding. We initially, in 2016, considered ASN.1, CBOR and JSON as 
equal candidates and rejected CBOR because the specification and implementation 
were not mature at the time. While CBOR now has both the features (issue 1) and 
implementations (issue 2), I hesitate to make such a big change so late in the 
standardization process. The compactness of the binary representation (issue 3) 
make little difference because EAP-NOOB is a bootstrapping protocol; the 
efficiency gains of CBOR would be more significant in payload data or signaling 
that continues throughout the device lifetime. 

There is, however, another issue that always bothered me much more. It is the 
ability to verify the HMAC correctly.

That is, my biggest concern with both JSON and CBOR is (4) the lack of 
canonical binary serialization. IN EAP-NOOB, we need to receive a serialized 
data message, extract some fields and subtrees, compose an HMAC input out of 
these parts of the data, and reliably compute always the same HMAC on it. The 
easy but flawed implementation would be to decode the received message, extract 
the selected parts, and then re-encode them, but the lack of canonical encoding 
means that the resulting byte string could be different in different 
encoder/decoder implementations. 

For the above reason, we have to extract the unmodified binary encoding of 
received messages. Some JSON libraries provide access to the unmodified binary 
encoding of document parts, but many either have no such function, return the 
Unicode serialization but no binary one, or do not guarantee that the returned 
byte string is unmodified. When we initially looked at CBOR, I expected it to 
solve this problem but found that, just like for JSON, there was no such 
function and we had to read the code of the decoder/encoder implementations to 
figure out a solution. 

A theoretical advantage of CBOR over JSON in this respect is that CBOR is 
serialized directly to a byte string while JSON is serialized to a Unicode 
string, which is then encoded as a byte string. This means that it may be 
easier for a CBOR library to provide access to the unmodified binary 
representation of fields and subtrees of received messages. But if the 
specification does not require them to provide that access, there is no real 
difference to JSON.

Tuomas


-Original Message-
From: Emu  On Behalf Of Carsten Bormann
Sent: Saturday, 11 July, 2020 16:40
To: Mohit Sethi M 
Cc: draft-ietf-emu-eap-noob@ietf.org; emu@ietf.org; Dave Thaler 
; iot-director...@ietf.org
Subject: Re: [Emu] [Iot-directorate] Iotdir early review of 
draft-ietf-emu-eap-noob-01
Importance: High

Hi Mohit,


> On 2020-07-11, at 15:27, Mohit Sethi M 
>  wrote:
> 
> Hi Michael,
> 
> Thanks for the input. This is indeed something we should discuss at the 
> upcoming virtual EMU meeting. 
> 
> Some colleagues (Ingles Sanchez et al.) have also investigated and documented 
> the savings that might result from the use of CBOR in EAP-NOOB: 
> https://hal.archives-ouvertes.fr/hal-02880326/document

That paper simply translates a JSON-like structure into CBOR, without using any 
of the additional benefits of using CBOR (e.g., numeric map labels).
So I would expect the benefits of moving to CBOR to be larger than described in 
this paper.

> EAP-NOOB also relies on the JWK specification for encoding public keys. While 
> CBOR equivalent is defined in RFC 8152, it is a rather large document that 
> contains all the functionality of JWK, JWS, JWA (as far as I understand). 
> Following smaller modular specifications was somehow easier at the time. 

RFC 8152 does have a section structure, so you don’t need to read all of it to 
just get the equivalent of JWK.

> What is more important is that wpa_supplicant currently has a JSON encoder 
> and parser (https://w1.fi/cgit/hostap/tree/src/utils/json.c). I think you 
> would agree that wpa_supplicant is probably the most important tool for those 
> using EAP (at least on 802.11). 
> 
> One could use an external library since there are many CBOR implementations 
> available: https://cbor.io/impls.html. However this has two major downsides:
> 
> - Adding an external library dependency implies that the overall system 
> becomes more brittle. 

To the contrary.  An implementation of JSON just for one application is likely 
to have received less testing and overall development attention than an 
industrial-strength library.  If you for some reason don’t agree with that, you 
can always create another CBOR implementation in an afternoon :-)

> - Updating and maintaining two components is definitely harder than one. 

Not sure I follow.

> As said, this is worth discussing at the meeting since it would result in a 
> large change to the existing EAP-NOOB implementations. 

Certainly!
I just wanted 

Re: [Emu] Iotdir early review of draft-ietf-emu-eap-noob-01

[Aura Tuomas]

Dave, thank you for the thorough review. It helped to weed out any vague 
expressions that could later become stumbling blocks. We incorporated may 
changes based on your comments already in draft-ietf-emu-eap-noob-02 (both the 
comments below and the ones in the linked pdf). I'll post answers to the 
comments here for the record.

Applicability
-

1) Added an explanation of the benefits of dynamic OOB message versus static 
registration codes. The main reason is that the receipt of the OOB message 
authorizes the server to take ownership of the device. Static registration 
codes cannot be expected to stay secret over time, thus, do cannot provide this 
functionality.

2) EAP does have retransmission timer, and thus I think we can assume one for 
EAP-NOOB. (Nevertheless, I really like this kind of observations and can add a 
note about relative time clocks if necessary.)

3) Need to come back to the JSON vs CBOR discussion.

4) Added the word RECOMMENDED to maximum length of the ServerUrl. The 
60-character maximum was chosen to fit into some QR code size that I felt was 
reasonable. There is not reason for a strict limit, though. 

Remembering many PeerIds (from the linked file): To clarify, remembering many 
PeerIds (which the server assigns in the Initial Exchange) is different from 
remembering many Noobs (which are sent by the OOB sender). In any case, in both 
cases, the constrained peer may remember only the latest one.

Interoperability


5,6) Changes to MUST as suggested. This was a good lesson on interoperability 
in details.

7) Sending updated Realm, ServerInfo and PeerInfo in the Reconnect Exchange is 
truly optional. There is not pressure to implement that part. The normative 
parts of this specification do not make use of the values and therefore I would 
not want to say anything about alternative update methods. 

8) It is true that ServerInfo and PeerInfo could be specified in more detail. 
The way this draft is written that it makes minimal suggestions for the initial 
deployments. We need more experience before standardizing the contents, which 
could be done in a later specification.

Attacks and mitigations
---

9) Replaced the printer example with LEDs and lightbulbs, which are also 
output-only devices. The printer example is pretty interesting and could even 
be one of the practical applications for EAP-NOOB, but elaborating on its 
intricacies would clutter the text. 

10) Will add discussion of UI clogging attacks against the server to the next 
version.

Identity protection (from the linked file): I have to think what to say about 
identity protection. We did have a plan for changing random peer identifiers, 
but the reliability issues related to the possible failure of synchronization 
are quite complex, and explaining them and the solution would have taken over 
the specification. 

Internationalization


11-13) This is a good lesson about the need to be precise about character sets. 
Changed the text to say bytes or ASCII characters when that is what we mean. 

Miscellaneous
-

14) Clarified.

15) Added a reference to 802.11 for "SSID".

16) Upper and lower case are allowed. Good point.

17) Yes, attestation is a good idea if the peer device has the hardware. Added 
a reference to ietf-rats-eat.


Again, this review was really valuable.
Regards,
Tuomas


-Original Message-
From: Dave Thaler via Datatracker  
Sent: Saturday, 13 June, 2020 03:40
To: iot-director...@ietf.org
Cc: draft-ietf-emu-eap-noob@ietf.org; emu@ietf.org
Subject: Iotdir early review of draft-ietf-emu-eap-noob-01
Importance: High

Reviewer: Dave Thaler
Review result: Ready with Issues

A marked up copy with my comments inline, including editorial nits not covered 
in this email is at 
https://www.microsoft.com/en-us/research/uploads/prod/2018/06/draft-ietf-emu-eap-noob-01.pdf
(a Word version is also available if requested, but the PDF should suffice).
See change tracking in red throughout the PDF for editorial nits.

Summary of issues:

Applicability
-

1) The document states that it does not support static printed registration 
codes.  It would benefit from stating the *rationale* for not supporting things 
like QR code stickers.  E.g., does the WG believe that such things are less 
secure?  The document does say this "also" prevents attacks where a static 
secret code would be leaked, but the use of "also" implies that's not the main 
rationale.

2) Section 3.2.5 says:
> A peer that has not received an OOB message MUST wait at least the 
> server-specified minimum waiting time in seconds

This means that this protocol cannot be easily implemented in IoT devices that 
have no relative time clock.  Does EAP itself already have this limitation 
regardless of EAP method?  If not, it would be good to call this out, since
this limits applicability to constrained devices.   Maybe add an
"Applicability" section 

Re: [Emu] eap-noob

[Aura Tuomas]

On 6/8/20 2:25 PM, Hannes Tschofenig wrote:

> Hi all

> I read through draft-aura-eap-noob-08 during the call for adoption.
> The draft acknowledges that the concept of "onboarding" is a new term for an 
> old concept, namely network access authentication. I like the draft from that 
> point of view.
> The content looks fine good and the design is well described. There is a 
> formal analysis available and sample code available.

Thank you for taking the time to review, and also for the positive feedback..

> I believe it would be good to note that the solution does not support any 
> form of cloning prevention because the device is assumed to be "blank" from 
> the point of view of keying material.

This is a good point. We'll add text in the security considerations. All blank 
devices are treated the same in EAP-NOOB. Thus, technically you can make as 
many clones of a blank device as you want. To prevent cloning, the protocol 
could be extended to bind the peer identity a TEE.

>  I was wondering about one aspect, and maybe I missed it somewhere: what are 
> you actually authenticating?
> The identifier for the client is assigned by the EAP server. The server is 
> also unknown at the start of the protocol.

The peer device is authenticated based on the fact that the user has physical 
access to it. The user typically authenticates the server based on a web 
certificate, but that depends on the OOB channel. EAP-NOOB is akin to 
device-pairing protocols (such as Bluetooth); the difference is that, instead 
of associating two devices with each other, EAP-NOOB associates a device with a 
server (and a user account in the server).

> I also got the impression that the authors are not entirely sure about 
> repeating the OOB step. Earlier in the document it sounds like the authors do 
> not really like the idea to repeat it and then later in the document they 
> acknowledge that it will be necessary to deal with it anyway. Am I reading 
> in-between the lines here?

I think this point could be written more clearly in the draft. It is mentioned 
multiple times because one of our most important goals for the design was to 
avoid repeating the OOB step after a successful association whenever it 
possibly can be avoided. In the protocol, this means creating an association 
that will be used for reauthentication, and that a temporary network or server 
failure should not cause the peer device to go back to its initial state. The 
protocol also supports rekeying and, unlike typical OOB pairing protocols, 
algorithm update (ECDH curve update) without a new OOB step.  The exception is 
that, if the device or server lose the association state, there is no way to 
recover without resetting also the other endpoint.
> There is also a not-so-bright side of this draft: the deployment. The 
> solution places many constraints on potential solutions, the authors have 
> little influence on the deployment environment, the use of EAP is not that 
> common in IoT communication technologies, there are many other competing 
> solutions, etc.

This is a reasonable point to make about EAP-NOOB and for EAP more generally. 
There is always tension between generic protocols like EAP and proprietary or 
technology-specific solutions. The advantages of EAP include the ability to 
change the authentication method without changing anything else in your 
protocol and system, independence of the lower-layer technology, lower cost of 
application development given the existing specifications and implementations, 
and ready support for roaming. For example 3GPP moved from technology-specific 
protocols to EAP, and they must see some advantage in it. It escapes me why 
802.11 has not given up on the non-EAP authentication methods that add lots of 
complexity to their specification.
> Ciao
> Hannes

Thank you again for your comments.
Tuomas
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] FW: New Version Notification for draft-aura-eap-noob-08.txt

[Aura Tuomas]

The latest version of the EAP-NOOB draft has only editorial changes. Many are 
based on Daniel Migault's review, which was very helpful in spotting 
potentially confusing text bits. Some terminology questions may need further 
discussion. The length of the PeerId requires a detailed analysis, which I will 
work on with my students. Overall, these are very minor issues and, IMO, the 
draft is ready for working group adoption.

Tuomas


-Original Message-
From: internet-dra...@ietf.org  
Sent: Tuesday, 10 March, 2020 00:25
To: Aura Tuomas ; Mohit Sethi 
Subject: New Version Notification for draft-aura-eap-noob-08.txt


A new version of I-D, draft-aura-eap-noob-08.txt has been successfully 
submitted by Tuomas Aura and posted to the IETF repository.

Name:   draft-aura-eap-noob
Revision:   08
Title:  Nimble out-of-band authentication for EAP (EAP-NOOB)
Document date:  2020-03-09
Group:  Individual Submission
Pages:  62
URL:https://www.ietf.org/internet-drafts/draft-aura-eap-noob-08.txt
Status: https://datatracker.ietf.org/doc/draft-aura-eap-noob/
Htmlized:   https://tools.ietf.org/html/draft-aura-eap-noob-08
Htmlized:   https://datatracker.ietf.org/doc/html/draft-aura-eap-noob
Diff:   https://www.ietf.org/rfcdiff?url2=draft-aura-eap-noob-08

Abstract:
   Extensible Authentication Protocol (EAP) provides support for
   multiple authentication methods.  This document defines the EAP-NOOB
   authentication method for nimble out-of-band (OOB) authentication and
   key derivation.  The EAP method is intended for bootstrapping all
   kinds of Internet-of-Things (IoT) devices that have no pre-configured
   authentication credentials.  The method makes use of a user-assisted
   one-directional OOB message between the peer device and
   authentication server to authenticate the in-band key exchange.  The
   device must have an input or output interface, such as a display,
   microphone, speakers or blinking light, which can send or receive
   dynamically generated messages of tens of bytes in length.


  


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


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

Re: [Emu] draft-aura-eap-noob-07 review

[Aura Tuomas]

Hi Daniel,

Thank you for the review! I really  appreciate you taking the time to read the 
draft with such care. I have fixed most of the issues, but some require more 
thought and I run out of time for today’s deadline. Responses are inline.

Tuomas


From: Emu  On Behalf Of Daniel Migault
Sent: Thursday, 16 January, 2020 18:14
To: emu@ietf.org
Subject: [Emu] draft-aura-eap-noob-07 review
Importance: High

Hi,
I have reviewed the eap-noob document and believe it is ready for adoption. I 
have made a series of comments that are mostly editorial and some clarifying 
questions. I am happy to review the document further.

Yours,
Daniel

[...]

Abstract

   Extensible Authentication Protocol (EAP) 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.


A nit. There are double spaces, so maybe :%s/  / /gc may be needed.  I believe
that *minimal* should be expanded here as it might be an important
characteristic of the object. Typically the ability to communicate an URL to
the end user, is a characteristic that is not generic to all devices at least
maybe not the bulb or temperature network. I would be good that from the
abstract the reader knows if this methods apply or not.


Edited the abstract to be more specific.



1.  Introduction

   This document describes a method for registration, authentication and
   key derivation for network-connected ubiquitous computing devices,
   such as consumer and enterprise appliances that are part of the
   Internet of Things (IoT).  These devices may be off-the-shelf
   hardware that is sold and distributed without any prior registration
   or credential-provisioning process.  Thus, the device registration in
   a server database, ownership of the device, and the authentication
   credentials for both network access and application-level security
   must all be established at the time of the device deployment.
   Furthermore, many such devices have only limited user interfaces that
   could be used for their configuration.  Often, the interfaces are
   limited to either only input (e.g. camera) or output (e.g. display
   screen).  The device configuration is made more challenging by the
   fact that the devices may exist in large numbers and may have to be
   deployed or re-configured nimbly based on user needs.

   More specifically, the devices may have the following
   characteristics:

   o  no pre-established relation with a specific server or user,


I understand this characteristic as requiring that devices must be completely
new. I have the impression that the characteristic concerns more the state of
the device then the device itself. Does the text means that such
characteristics are not necessary or that these characteristic if existing will
make the registration impossible. Typically, I imagine the following scenarios.
I have a registered screen from in a server in my company. I am taking that
screen to the University that organises a workshop. Can the screen work with
two different accounts/registration on different servers ? Do I have to
necessarily factory reset the screen ? Do I have to redo the registration
procedure when I bring the screen back to my company ? Am I going to possibly
register the screen I bought on second-hand-gatan ?  

Added hard reset as alternative to off-the-shelf. Multiple registrations is 
something we have consciously avoided discussing because the protocol itself is 
agnostic to the number of simultaneous instance one device can implement. I’ll 
think about an appropriate way of discussing this.


   o  no pre-provisioned device identifier or authentication
  credentials,

I do have the same questions as above. 

   o  limited user interface and configuration capabilities.

I am finding limited too vague to understand if my device is a candidate
for this registration.

Edited the text to be more slightly specific.


   Many proprietary OOB configuration methods exits for specific IoT
   devices.  The goal of this specification is to provide an open
   standard and a generic protocol for bootstrapping the security of
   network-connected appliances, such as displays, printers, speakers,



Aura & Sethi   Expires May 1, 2020  [Page 3]

Internet-Draft  EAP-NOOBOctober 2019


   and cameras.  The security bootstrapping in this specification makes
   use of a user-assisted out-of-band (OOB) channel.  The device
   authentication relies on user having physical access to the device,
   and the of the key exchange security is based on 

Re: [Emu] EAP-NOOB: request for optional message pair to configure EAP Peer

[Aura Tuomas]

Hi Philip,

It would definitely be useful to provision various types of long-term 
credentials after the security bootstrapping and to use them for 
reauthentication later. One way to achieve this with the current spec is to use 
the exported AMSK as a shared key for a separate credential provisioning 
protocol. We have given some thought to provisioning long-term credentials in 
EAP-NOOB, but it was not clear which and how many different credential types 
EAP-NOOB should support. We might end up with an unrealistically complicated 
protocol. Also, it would require fragmentation support e.g. to deliver long 
certificates or certificate chains. A better solution might be a to export a 
credential provisioning key from all EAP methods in a standard way and to use 
that for the provisioning protocol of your choice. I would be happy to discuss 
how to achieve this and if there is a way that meets your requirements..

*Chairs*: I hope that you can initiate a call for adoption of EAP-NOOB, so that 
the working group can decide on this kind of feature requests depending on the 
priorities of the community. From my point of view, the spec is quite ready.

Tuomas


From: Emu  On Behalf Of philipginzboorg
Sent: Friday, 6 March, 2020 15:27
To: emu@ietf.org
Subject: [Emu] EAP-NOOB: request for optional message pair to configure EAP Peer
Importance: High

Hi,

I am Philip Ginzboorg from Huawei Finland. Together with my colleague Sandeep 
Tamrakar we are working on IoT  security-related project and had a look at 
EAP-NOOB.

Here is our comment on the EAP-NOOB draft version 7:
- In addition to the functionality that EAP-NOOB already provides, we would 
like to have the possibility for the EAP server to configure the EAP Peer. For 
instance, the EAP Server could provision long-term credentials to the EAP Peer.
- For that purpose, we would like to have one optional message pair in the 
EAP-NOOB protocol exchanged, just before the Completion Exchange (Section 
3..2.4) ends.
 - The first additional message, from EAP Server to EAP Peer, could be of a 
separate Command message type (e.g., type=10). It should be send only during 
the Completion exchange, after the server verifies the correctness of the 
received MAC (i.e. MACp) from the EAP Peer, and before EAP-Success message.
 - Upon receiving this message, the EAP Peer will configure itself as 
instructed by the EAP Server, if MACs is correct. Then, the EAP Peer will 
respond with configuration success message.
- For example, in Fig 6 (https://tools.ietf.org/html/draft-aura-eap-noob-07) 
after 4th message (Type=4,PeerId,MACp) and before EAP-Success message, there 
would be a possibility of sending additional message (e.g., Type=10, say, a 
configuration Command message) to the EAP Peer, and expect back a response.

Philip
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

[Aura Tuomas]

I was looking at the EAP-TLS with TLS 1.3 draft and noticed that it forbids PSK 
authentication. Why is that? While there is the EAP-PSK method, I would much 
rather use EAP-TLS with PSK because it provides identity protection and perfect 
forward secrecy, unlike EAP-PSK. 

In fact, I think EAP-TLS with PSK should become the standard authentication 
method for networks that rely on shared secrets, e.g. WPA-Personal. Unifying 
the Wi-Fi authentication around EAP would greatly simplify the Wi-Fi protocol 
stack. Not that I expect it to happen immediately, but we should not close 
sensible paths forward.

Tuomas

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

Re: [Emu] Implementing EAP-NOOB in Contiki - Use of the Realm assigned by the server?

[Aura Tuomas]

Yes, the new Realm assigned in the Initial Exchange should be used already 
during the Waiting Exchange and Completion Exchange. As part of the editorial 
improvements in draft-06, I edited the specification to be clearer on this 
point. 

The reason is better compatibility with roaming implementations, which are not 
part of the EAP-NOOB protocol but may want to work with it. If the Initial 
Exchange takes place while roaming, some external mechanism is needed to route 
the Initial Exchange, where the peer uses the default Realm, from the foreign 
AAA to the peer's intended home AAA. Since the realm is assigned in the Initial 
Exchange and taken into use immediately, the AAA routing will work normally for 
the subsequent Waiting and Completion Exchanges, and the same external 
mechanism is not needed there. That is, it is easier for foreign network to 
support Initial Exchange for roaming peer devices. The use case for such 
roaming support in eduroam was brought forward by Josh Howlett and Rhys Smith.

Tuomas



-Original Message-
From: Emu  On Behalf Of Eduardo Inglés UM
Sent: Thursday, June 20, 2019 1:20 PM
To: emu@ietf.org
Subject: [Emu] Implementing EAP-NOOB in Contiki - Use of the Realm assigned by 
the server?
Importance: High

Hello all,

During the IETF 104 Prague I told you that I am implementing EAP-NOOB in 
Contiki. During the process I have had few issues that I will send in separate 
emails for clarifications in the coming weeks.

I like the way EAP-NOOB allows the server to send a realm that a peer can use 
later on during its lifetime. I find it useful when peers are roaming in 
different networks, for example, in the use case that I sent in a previous 
email. However, reading the specification it is not clear to me when a device 
should start using the Realm assigned by the server.

Should I use it already during Waiting Exchange? Or only after the device has 
been successfully authenticated in the Completion Exchange?

Regards,
Eduardo Inglés.



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

[Emu] FW: New Version Notification for draft-aura-eap-noob-06.txt

[Aura Tuomas]

Hi all!

I have updated the EAP-NOOB draft. Here is a summary of the changes: 

* The major change was to add a separate request-response pair for 
communicating the PeerId and peer state to the server, instead of overloading 
the NAI. This is in conformance with RFC 3748 section 5.1: the NAI is now used 
only for routing the EAP requests and for selecting the method, and the 
method-specific peer identifier is communicated inside the method. (Note that 
the example messages in the appendix have not yet been updated.)

* Rolled back a change introduced in the previous version: the Kz identifier. 
While this could make implementation slightly easier, it conflicted with a 
potential future privacy extension where the PeerId is re-randomized 
periodically. 

* Refactored the text so that the initial handshake part of the exchanges, 
which is common to all exchanges, is described in its own section. This change 
is in response to questions from implementors. The text now follows more 
closely what I expect to be the sever logic in a the typical implementation. 
There were also other smaller editorial clarifications, e.g. when to start 
using the server-assigned realm. 

Regards,
Tuomas



-Original Message-
From: internet-dra...@ietf.org  
Sent: Wednesday, July 3, 2019 3:47 PM
To: Mohit Sethi ; Aura Tuomas 
Subject: New Version Notification for draft-aura-eap-noob-06.txt


A new version of I-D, draft-aura-eap-noob-06.txt has been successfully 
submitted by Tuomas Aura and posted to the IETF repository.

Name:   draft-aura-eap-noob
Revision:   06
Title:  Nimble out-of-band authentication for EAP (EAP-NOOB)
Document date:  2019-07-03
Group:  Individual Submission
Pages:  62
URL:https://www.ietf.org/internet-drafts/draft-aura-eap-noob-06.txt
Status: https://datatracker.ietf.org/doc/draft-aura-eap-noob/
Htmlized:   https://tools.ietf.org/html/draft-aura-eap-noob-06
Htmlized:   https://datatracker.ietf.org/doc/html/draft-aura-eap-noob
Diff:   https://www.ietf.org/rfcdiff?url2=draft-aura-eap-noob-06

Abstract:
   Extensible Authentication Protocol (EAP) 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

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

Re: [Emu] Support of NIST P-256 in EAP-NOOB

[Aura Tuomas]

Thank you for bringing up this issue. If there is broader demand for NIST 
P-256, we certainly can consider adding it to the draft. In any case, it would 
make sense to have two different curves in the specification to facilitate 
interoperability testing of the cryptosuite negotiation. At this point, maybe 
we can work on the interoperability first and then decide on the specific 
curves. The selection of curves will probably require broader community input, 
for example from SAAG.

Tuomas

 

-Original Message-
From: Emu  On Behalf Of Eduardo Inglés UM
Sent: Thursday, June 20, 2019 1:23 PM
To: emu@ietf.org
Subject: [Emu] Support of NIST P-256 in EAP-NOOB
Importance: High

Hi again,

I am currently implementing EAP-NOOB on Zolertia Firefly boards 
(https://zolertia.io/product/firefly/). The board provides hardware 
acceleration for ECC operations. However, currently the API only supports ECDHE 
with NIST P-256 and EAP-NOOB draft only mentions the cryptosuite x25519 in 
Section 4.1.

I know that IETF likes the curve x25519, which has been specified through the 
CFRG process. Besides that, I see that many other platforms only support NIST 
P-256 in hardware. Thus, I wonder if it would be possible to support NIST P-256 
to the draft?

In this draft
(https://tools.ietf.org/html/draft-ietf-lwig-curve-representations-06) I see 
that perhaps it is possible to use the code NIST P-256 for doing x25519. 
However, I have no coding expertise in cryptographic encoding to do that. Hence 
authors, do you want to support another curve?


Regards,
Eduardo Inglés.

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

Re: [Emu] Questions about EAP-NOOB

[Aura Tuomas]

We had intended to transfer "eap-noob.net" to IANA, but replacing this domain 
with .arpa is equally ok. 

The domain name reservation considerations in section 4.4. of 
https://tools.ietf.org/html/draft-aura-eap-noob-05#section-4.4 will still be 
relevant.  

Tuomas


-Original Message-
From: Eliot Lear  
Sent: Wednesday, 6 March, 2019 15:31
To: Alan DeKok 
Cc: Aura Tuomas ; emu@ietf.org
Subject: Re: [Emu] Questions about EAP-NOOB
Importance: High

And indeed it was Alan who I was referring to in my message.  I generally agree 
with Alan’s thinking below.

Eliot

> On 6 Mar 2019, at 13:45, Alan DeKok  wrote:
> 
> On Mar 6, 2019, at 7:23 AM, Aura Tuomas  wrote:
>> The realm used by the peer is initially “eap-noob.net”. The server can 
>> assign another realm in Initial Exchange. The main purpose for assigning 
>> another realm is that the peer can later use it for roaming in access 
>> networks that have AAA routing set up for the assigned realm.
> 
>  This is fine for an initial draft.  I'd avoid implementing anything that 
> uses "eap-noob.net", though.
> 
>  The correct domain to use is .arpa:
> 
>   https://www.iana.org/domains/arpa
> 
>  The controlling document here is RFC 3172.
> 
>  It looks like EAP-TEAP-BRSKI requires a similar NAI for provisioning.  So it 
> would best best to coordinate both the name, and the use of it.  Perhaps 
> "provisioning.arpa" could be used as a generic name, and then subdomains 
> within that could be used for particular purposes.
> 
>  Alan DeKok.
> 
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu

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

[Emu] FW: New Version Notification for draft-aura-eap-noob-05.txt

[Aura Tuomas]

Hi all!

We have updated the EAP-NOOB draft. The security considerations section has 
been improved based on comments from Eric Rescorla at secdispatch and our 
ongoing modeling work. We have also made some changes to the Reconnect Exchange 
based on implementation experiences to make it easier to implement. 

Regards,
Tuomas


-Original Message-
From: internet-dra...@ietf.org  
Sent: Monday, 11 March, 2019 20:16
To: Mohit Sethi ; Aura Tuomas 
Subject: New Version Notification for draft-aura-eap-noob-05.txt


A new version of I-D, draft-aura-eap-noob-05.txt has been successfully 
submitted by Tuomas Aura and posted to the IETF repository.

Name:   draft-aura-eap-noob
Revision:   05
Title:  Nimble out-of-band authentication for EAP (EAP-NOOB)
Document date:  2019-03-11
Group:  Individual Submission
Pages:  60
URL:https://www.ietf.org/internet-drafts/draft-aura-eap-noob-05.txt
Status: https://datatracker.ietf.org/doc/draft-aura-eap-noob/
Htmlized:   https://tools.ietf.org/html/draft-aura-eap-noob-05
Htmlized:   https://datatracker.ietf.org/doc/html/draft-aura-eap-noob
Diff:   https://www.ietf.org/rfcdiff?url2=draft-aura-eap-noob-05

Abstract:
   Extensible Authentication Protocol (EAP) 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

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

Re: [Emu] Questions about EAP-NOOB

[Aura Tuomas]

Hi Dan and Rafa,

Thank you for the questions!

Yes, the Initial Exchange in EAP-NOOB always ends in EAP-Failure.  Then, we 
give some time for the user to transfer the OOB message. After the OOB step, 
the peer tries again and the Completion Exchange ends in EAP-Success.

Yes, the out-of-band (OOB) message is cryptographically bound to the ECHD 
result. That, is the message authentication code (Hoob) in the OOB message 
takes the ECDH output as one of its inputs.

Our current implementation opportunistically tries all the W-Fi network that 
support WPA2-Enterprise. It definitely would be better to advertise the 
capability for EAP-NOOB in IEEE 802.11u, or even advertise the domain of the 
EAP-NOOB server. I think it will take some time before the 802.11 APs start to 
support EAP-NOOB in that way, though, and we want the protocol to work with 
existing Wi-Fi networks.

The realm used by the peer is initially “eap-noob.net”. The server can assign 
another realm in Initial Exchange. The main purpose for assigning another realm 
is that the peer can later use it for roaming in access networks that have AAA 
routing set up for the assigned realm.

We have only tested EAP-NOOB on Wi-Fi: https://github.com/tuomaura/eap-noob. It 
can be used on any networks that support EAP and where the user-assisted OOB 
authentication methods makes sense from the user experience perspective.

Regards,
Tuomas


From: Emu  On Behalf Of Dan Garcia
Sent: Monday, 28 January, 2019 13:39
To: emu@ietf.org
Subject: [Emu] Questions about EAP-NOOB
Importance: High

Dear Toumas, Mohit,

We have been discussing EAP NOOB draft we would like to ask some questions 
about it. It is a very interesting approach related to IoT.


In EAP-NOOB as first step the EAP authenticator starts the authenction (e.g. 
the AP), eap-noob happens but it seems there will be a EAP failure , is this 
correct?
Assuming it is, if you send an EAP failure, will the EAP method still continue? 
How would this work? Since we are waiting, we assume, from an EAP success, or 
an alternative way of confirmation that the authentication has been completed.

It seems that the user gets something from the IoT device this something is due 
to the ECDH, right?

Regarding the discovery of the EAP authenticator. The AP should announce what 
are the available domains to where it is connected ( a solution based on the 
AAA infraestructure ?) Could this information be provided to the AP using IEEE 
802.11u?

Related to this, what would be the realm provided by the EAP peer to the 
authenticator?

Another question would be which are the main radio technologies where EAP NOOB 
is expected to be used. Are you planning to support 802.15.4, WIFI, etc? In 
this line, do you have any EAP-NOOB implementation in Contiki?



Thank you in advance.
Best Regards.
Dan and Rafa.


--
=

Dan Garcia Carrillo, Ph.D.
Doctorado Industrial (MINECO)
E-mail: dgar...@odins.es

Odin Solutions, S.L.
Polígono Industrial Oeste
C/ Perú, 5, 3º, Oficina 12
30820 - Alcantarilla (Murcia) - Spain
Tlf.: +34 902 570 121
Web: www.odins.es
=

AVISO LEGAL: La información contenida en este correo electrónico, y en su caso 
en los documentos adjuntos, es información privilegiada para uso exclusivo de 
la persona y/o personas a las que va dirigido. No está permitido el acceso a 
este mensaje a cualquier otra persona distinta a los indicados. Si usted no es 
uno de los destinatarios, cualquier duplicación, reproducción, distribución, 
así como cualquier uso de la información contenida en él o cualquiera otra 
acción u omisión tomada en relación con el mismo, está prohibida y puede ser 
ilegal. En dicho caso, por favor notifíquelo al remitente y proceda a la 
eliminación de este correo electrónico, así como de sus adjuntos si los hubiere.

Asimismo, y en cumplimiento de Ley Orgánica 3/2018 de protección de datos de 
carácter personal y garantía de los derechos digitales y del Reglamento Europeo 
RGPD 679/2016 le informamos que sus datos están siendo objeto de tratamiento 
por parte de ODIN SOLUTIONS, S.L. con N.I.F. B-73.845.893, con la finalidad del 
mantenimiento y gestión de relaciones comerciales y administrativas. La base 
jurídica del tratamiento es el cumplimiento de la legislación fiscal, mercantil 
y contable. No se prevén cesiones y/o transferencias internacionales de datos. 
Para ejercitar sus derechos puede dirigirse a ODIN SOLUTIONS, S.L., domiciliada 
en C/ Perú, 5, 3º, Oficina 12, Pol. Ind. Oeste, 30820 Alcantarilla (Murcia), o 
bien por E-mail a 
protecciondeda...@odins.es, con el fin de 
ejercer sus derechos de acceso, rectificación, supresión (derecho al olvido), 
limitación de tratamiento, portabilidad de los datos, oposición, y a no ser 
objeto de decisiones automatizadas, indicando como Asunto: 

Re: [Emu] Questions about EAP-NOOB draft

[Aura Tuomas]

Hi Eduardo,

1. 
I' not sure what kind of alternative key derivation you are suggesting. Are you 
thinking about alternative ECDH curves, or RSA maybe? I believe even the 
low-end devices can do ECDHE these days so it is not obvious to me why that 
should be sometimes avoided.

2.
This is a valid scenario for real-world deployments. Thank you for bringing it 
up.

Managed handovers where the previous authentication / management server is 
still online and co-operative, are already supported. After copying the 
EAP-NOOB associations for the peer devices to the new server, the old server 
can send a new Realm field in the next Reconnect Exchange and then be taken 
offline. Alternatively, Radius routing can be set at the access networks to 
capture the old realm, and the new server can send the new Realm in Reconnect. 
We should check the EAP-NOOB spec though to make sure that there is nothing to 
prevent such usage.

Unmanaged handovers where the old server just goes out of business are messier. 
We simply need to copy the server-side EAP-NOOB association database because 
there is nothing else for re-bootstrapping the security association - except of 
course a new user-assisted OOB step.

Regards,
Tuomas



-Original Message-
From: Emu  On Behalf Of Eduardo Inglés UM
Sent: Wednesday, 9 January, 2019 20:25
To: emu@ietf.org
Subject: [Emu] Questions about EAP-NOOB draft
Importance: High

Dear Tuomas,

First of all, I would like to say that EAP-NOOB draft is very complete and 
understandable. Also, with regard to the rest of the solutions I have found, I 
think it is a great solution so far and I like the way to approach the problems.

I am working on implementing EAP-NOOB on resource-constrained devices for our 
use case. But I have the following 2 questions:

1. Regarding the key derivation section. There, it is explained the use of 
ECDHE for the key exchange. Do you have in mind to accept any alternatives 
besides the one explained in the draft? Maybe weaker methods or stronger but 
not so constrained.

2. I have a concrete use case. Specifically, I am interested in knowing how the 
Reconnect State works.
In the scenario there are some devices that are going to be installed and then 
they will be inaccessible to be able to repeat the OOB step. 
These devices already have the corresponding security associations with a 
specific RealM. For example, a device from the University of Murcia is managed 
by a company called Odins.

Now we assume that Odins stops managing those devices and Ericsson becomes the 
new manager with his own AAA Infrastructure. To establish the new RealM, I 
understand that the device should be restarted and the entire process done. Is 
there a mechanism to allow migration without having to repeat the OOB step?


Regards,
Eduardo Inglés.

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

Re: [Emu] FW: New Version Notification for draft-aura-eap-noob-04.txt

[Aura Tuomas]

Hi Shiva,

You are making a valid point. I think we need to do some work on analyzing the 
security threats and requirements regarding the error messages etc. When there 
is an established key, we might be able to protect the integrity of the error 
messages that lead to state transitions or prevent one for a longer time. 

Regards,
Tuomas



-Original Message-
From: Shiva Prasad Thagadur Prakash 
 
Sent: Sunday, 4 November, 2018 09:01
To: emu@ietf.org; Aura Tuomas 
Subject: Re: [Emu] FW: New Version Notification for draft-aura-eap-noob-04.txt
Importance: High

Hi EMU,

In my previous job, I was one of the team members implementing EAP- NOOB. I 
have now changed employers and work on something completely different (Platform 
Security). I am following this draft out of personal interest. 

I appreciate the fact that the authors have taken the time to formally verify 
the protocol. A paper from as recent as CCS 2018 (October): http 
s://papers.mathyvanhoef.com/ccs2018.pdf, shows new attacks in the Wi-Fi 4-way 
handshake protocol and recommends formally modelling 802.11.

I would however strongly recommend the authors of this document, and others, to 
encrypt as many EAP messages as possible. For example, error messages sent in 
EAP-NOOB are still in plain. Since these messages usually cause one or the 
other side to change states, they should be protected. 802.11, TLS and other 
protocols have been taking a similar approach of encrypting as much as 
possible. As an example, 802.11 now uses protected management frames.

Regards
Shiva

On ke, 2018-10-24 at 17:47 +, Aura Tuomas wrote:
> Dear all,
>  
> We have submitted a new version of our draft titled “Nimble out-of- 
> band authentication for EAP (EAP-NOOB)”:
>  
> https://tools.ietf.org/html/draft-aura-eap-noob-04
>  
> 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.
>  
> What is new in version -04? Since the previous version, we have done 
> extensive modeling and verification of the protocol and worked to 
> resolve some discovered issues. We especially looked for denial-of- 
> service conditions that may arise from dropped messages and other 
> protocol failures, which both could be caused a network attacker.
> Based on this analysis, we have rethought the recovery from dropped 
> final messages. The error handling still needs some attention. In any 
> case, the specification is a pretty good shape and ready for anyone to 
> review.
>  
> The open-source implementation and the mCRL2 formal model are still 
> based on the previous version but work is ongoing to update them:
> https://github.com/tuomaura/eap-noob
>  
> Emu is the working group that closest matches our spec. Thus, we look 
> forward to your feedback and comments here or in the wg meeting in a 
> couple of weeks.
>  
> Regards,
> Tuomas
>  
> 
> 
> -Original Message-
> From: internet-dra...@ietf.org 
> Sent: Monday, 22 October, 2018 20:50
> To: Mohit Sethi ; Aura Tuomas 
> Subject: New Version Notification for draft-aura-eap-noob-04.txt
> 
> 
> A new version of I-D, draft-aura-eap-noob-04.txt has been successfully 
> submitted by Tuomas Aura and posted to the IETF repository.
> 
> Name:   draft-aura-eap-noob
> Revision:   04
> Title:  Nimble out-of-band authentication for EAP (EAP-NOOB) 
> Document date:  2018-10-22
> Group:  Individual Submission
> Pages:  58
> URL:    https://www.ietf.org/internet-drafts/draft-aura-eap-n
> oob-04.txt
> Status: https://datatracker.ietf.org/doc/draft-aura-eap-noob/
> Htmlized:   https://tools.ietf.org/html/draft-aura-eap-noob-04
> Htmlized:   https://datatracker.ietf.org/doc/html/draft-aura-eap-
> noob
> Diff:   https://www.ietf.org/rfcdiff?url2=draft-aura-eap-noob
> -04
> 
> Abstract:
>    Extensible Authentication Protocol (EAP) 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.
> 
>  
>  
> 
> 
>

Re: [Emu] New Version Notification for draft-aura-eap-noob-04.txt

[Aura Tuomas]

Hi Dan, thank you for the comment.

We have been looking through this and, yes, it might be feasible to use 
EAP-NOOB together with your ideas for sending EAP over CoAP.

Regards,
Tuomas


From: Dan García Carrillo 
Sent: Wednesday, 31 October, 2018 11:02
To: Aura Tuomas 
Cc: emu@ietf.org
Subject: Re: [Emu] New Version Notification for draft-aura-eap-noob-04.txt
Importance: High

Hi Tuomas,

This is an interesting work.

We have been investigating how to send EAP over the CoAP protocol specifically 
thinking of IoT devices 
(https://tools.ietf.org/html/draft-marin-ace-wg-coap-eap-06). Being an EAP 
lower layer, CoAP-EAP is agnostic to any EAP method. From what I see, EAP-NOOB 
seems to be an interesting proposal for authentication of IoT devices, since 
there is no pre-provisioning or credentials or identities. Because EAP-NOOB 
does not require large messages, causing fragmentation, it could be integrated 
in a real scenario using CoAP-EAP as EAP lower layer.

Best Regards,
Dan.

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

[Emu] FW: New Version Notification for draft-aura-eap-noob-04.txt

[Aura Tuomas]

Dear all,



We have submitted a new version of our draft titled "Nimble out-of-band 
authentication for EAP (EAP-NOOB)":



https://tools.ietf.org/html/draft-aura-eap-noob-04



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.



What is new in version -04? Since the previous version, we have done extensive 
modeling and verification of the protocol and worked to resolve some discovered 
issues. We especially looked for denial-of-service conditions that may arise 
from dropped messages and other protocol failures, which both could be caused a 
network attacker. Based on this analysis, we have rethought the recovery from 
dropped final messages. The error handling still needs some attention. In any 
case, the specification is a pretty good shape and ready for anyone to review.



The open-source implementation and the mCRL2 formal model are still based on 
the previous version but work is ongoing to update them:

https://github.com/tuomaura/eap-noob



Emu is the working group that closest matches our spec. Thus, we look forward 
to your feedback and comments here or in the wg meeting in a couple of weeks.



Regards,

Tuomas




-Original Message-
From: internet-dra...@ietf.org 
Sent: Monday, 22 October, 2018 20:50
To: Mohit Sethi ; Aura Tuomas 
Subject: New Version Notification for draft-aura-eap-noob-04.txt


A new version of I-D, draft-aura-eap-noob-04.txt has been successfully 
submitted by Tuomas Aura and posted to the IETF repository.

Name:   draft-aura-eap-noob
Revision:   04
Title:  Nimble out-of-band authentication for EAP (EAP-NOOB)
Document date:  2018-10-22
Group:  Individual Submission
Pages:  58
URL:https://www.ietf.org/internet-drafts/draft-aura-eap-noob-04..txt
Status: https://datatracker.ietf.org/doc/draft-aura-eap-noob/
Htmlized:   https://tools.ietf.org/html/draft-aura-eap-noob-04
Htmlized:   https://datatracker.ietf.org/doc/html/draft-aura-eap-noob
Diff:   https://www.ietf.org/rfcdiff?url2=draft-aura-eap-noob-04

Abstract:
   Extensible Authentication Protocol (EAP) 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
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] FW: New Version Notification for draft-aura-eap-noob-03.txt

[Aura Tuomas]

Dear all,

We have submitted a new version of our draft titled “Nimble out-of-band 
authentication for EAP (EAP-NOOB)”:

https://tools.ietf.org/html/draft-aura-eap-noob-03

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. 

Since the previous version, we have improved the clarity of the specification 
and resolved minor issues that were found in the implementation and formal 
modeling of the protocol. The quality of the protocol specification has 
improved a lot and it should now be quite easy to read and implement. The list 
of updates can be found from the version history in the appendix of the draft. 
We are still on the process of modeling various failure conditions, such as 
intentionally dropped messages, and might make minor modifications for the next 
version to improve the robustness of failure recovery in some special cases. 

The open source implementation has been updated to match the new version, and 
the mCRL2 formal model is also available:
https://github.com/tuomaura/eap-noob 

We look forward to your feedback and comments here or on the SAAG mailing list.

Regards,
Tuomas


-Original Message-
From: internet-dra...@ietf.org  
Sent: Monday, 2 July, 2018 15:04
To: Mohit Sethi ; Aura Tuomas 
Subject: New Version Notification for draft-aura-eap-noob-03.txt


A new version of I-D, draft-aura-eap-noob-03.txt has been successfully 
submitted by Mohit Sethi and posted to the IETF repository.

Name:   draft-aura-eap-noob
Revision:   03
Title:  Nimble out-of-band authentication for EAP (EAP-NOOB)
Document date:  2018-07-02
Group:  Individual Submission
Pages:  54
URL:https://www.ietf.org/internet-drafts/draft-aura-eap-noob-03.txt
Status: https://datatracker.ietf.org/doc/draft-aura-eap-noob/
Htmlized:   https://tools.ietf.org/html/draft-aura-eap-noob-03
Htmlized:   https://datatracker.ietf.org/doc/html/draft-aura-eap-noob
Diff:   https://www.ietf.org/rfcdiff?url2=draft-aura-eap-noob-03

Abstract:
   Extensible Authentication Protocol (EAP) 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.

  


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

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

[Aura Tuomas]

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:josh.howl...@jisc.ac.uk] 
Sent: Thursday, 18 February, 2016 19:28
To: Mohit Sethi <mohit.m.se...@ericsson.com>; s...@ietf.org; emu@ietf.org
Cc: Aura Tuomas <tuomas.a...@aalto.fi>
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:saag-boun...@ietf.org] On Behalf Of Mohit Sethi
> Sent: 08 February 2016 15:34
> To: s...@ietf.org; emu@ietf.org
> Cc: tuomas.a...@aalto.fi
> 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: internet-dra...@ietf.org
> To:   Tuomas Aura <tuomas.a...@aalto.fi>, Mohit Sethi
> <mo...@piuha.net>
> 
> 
> 
> 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:
> Extensibl