[Emu] Protocol Action: 'Nimble out-of-band authentication for EAP (EAP-NOOB)' to Proposed Standard (draft-ietf-emu-eap-noob-06.txt)

[The IESG]

The IESG has approved the following document:
- 'Nimble out-of-band authentication for EAP (EAP-NOOB)'
  (draft-ietf-emu-eap-noob-06.txt) as Proposed Standard

This document is the product of the EAP Method Update Working Group.

The IESG contact persons are Benjamin Kaduk and Roman Danyliw.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/





Technical Summary

   The 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, speaker or blinking light, which can send or receive
   dynamically generated messages of tens of bytes in length.

Working Group Summary

The document received a detailed early IoT directorate review.

Document Quality

At least three public implementations of the protocol are available:
1. wpa_supplicant - https://github.com/tuomaura/eap-noob
2. contiki - https://github.com/eduingles/coap-eap-noob
3. hostap - https://github.com/Vogeltak/hostap

The protocol has security proofs:
1. Proverif: 
https://github.com/tuomaura/eap-noob/tree/master/protocolmodel/proverif
2. mcrl2: https://github.com/tuomaura/eap-noob/tree/master/protocolmodel/mcrl2

Personnel

Document Shepherd - Joe Salowey

Responsible AD - Roman Danyliw

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

[Emu] I-D Action: draft-ietf-emu-eap-noob-06.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the EAP Method Update WG of the IETF.

Title   : Nimble out-of-band authentication for EAP (EAP-NOOB)
Authors : Tuomas Aura
  Mohit Sethi
  Aleksi Peltonen
Filename: draft-ietf-emu-eap-noob-06.txt
Pages   : 68
Date: 2021-09-03

Abstract:
   The 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 a non-network input or output interface, such as a
   display, microphone, speaker, or blinking light, which can send or
   receive dynamically generated messages of tens of bytes in length.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-noob-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-noob-06


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

[Emu] Benjamin Kaduk's No Objection on draft-ietf-emu-eap-noob-05: (with COMMENT)

[Benjamin Kaduk via Datatracker]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-emu-eap-noob-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/



--
COMMENT:
--

Thanks for the many updates to address my Discuss and Comment points.

Just a few final thoughts from reading the diff from -04 to -05:

Section 5.6

It's interesting to see the eap-noob.arpa registration lose discussion about
who should care and why (i.e., the list from RFC 6761).  I guess I see how
it's not specifically required by 6761 itself, but it seemed useful to think
about.

Section 7.2

The first and second paragraphs both start with the same sentence, which makes
me suspect that there are some editing remnants left.

Section 7.7

Many thanks for adding this treatment of channel binding.  The actual
properties provided are weaker than I'd like, but attempting to diverge from
RFC 6677 in this document seems unlikely to actually be useful, so I'll have
to accept what is possible.



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

Re: [Emu] Benjamin Kaduk's Discuss on draft-ietf-emu-eap-noob-04: (with DISCUSS and COMMENT)

[Benjamin Kaduk]

Hi Mohit,

My apologies for the slow response -- I skimmed the diff when it first
arrived and it didn't look like I had enough time to process it all at that
time, and I didn't get back to it as quickly as I would like.

Following up inline only where I have further comments...

On Fri, Jul 16, 2021 at 03:52:22PM +, Mohit Sethi M wrote:
> Hi Ben,
> 
> Thank you for your usual detailed review. We have uploaded a new version 
> of the draft: https://tools.ietf.org/html/draft-ietf-emu-eap-noob-05. 
> Here is the diff for your convenience: 
> https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-noob-05.
> 
> Answers inline.
> 
> --Mohit
> 
> On 4/22/21 7:26 AM, Benjamin Kaduk via Datatracker wrote:
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-emu-eap-noob-04: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer tohttps://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/
> >
> >
> >
> > --
> > DISCUSS:
> > --
> >
> > The example JWK for cryptosuite 1 in §5.1 is not well-formed.  RFC 8037
> > key-exchange uses a crv of "X25519" and a kty of "OKP".
> > (See COMMENT for more quibbles with §5.1.)
> > I think Appendix E is also using the wrong "kty" for X25519 (but is
> > properly using "X25519" as the "crv").
> 
> Good catch. This is now fixed in the script used to generate the test 
> vectors: 
> https://github.com/tuomaura/eap-noob/commit/a9e8da4ec227b4afe8fb04feb71d76265396882b.
>  
> The example messages in the draft are not yet updated (pending your 
> feedback on our proposal below).
> 
> >
> > I'd also like to discuss our treatment of channel binding, as the
> > current mention seems dangerously incomplete.  I don't remember if there
> > is generic discussion of channel binding in the core EAP RFCs (if so, a
> > specific reference would help), but otherwise if we're going to mention
> > that protocol elements can be used for channel binding we should give
> > some indication of how to actually do so in a secure manner (e.g., what
> > protocol element needs to be verified against external channel
> > information and what to do if they don't match).
> 
> We have added a section on channel binding which should address all the 
> issues: 
> https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-noob-05#section-7.7.

Thanks, this is really helpful.  (I did not know about RFC 6677 previously,
so my expectations for what the channel binding was doing were not quite
correct.)

> >
> >
> > --
> > COMMENT:
> > --
> >
> > Thanks for putting together this pretty comprehensive treatment of a
> > topic that is simple to understand but has a lot of important details.
> > (I do have some comments about a few of those details, just to check
> > that we do have them right.)  I especially appreciate the strong feature
> > set that's been assembled.
> >
> > In Section 3.5 we discuss a key derivation scheme and say to use the
> > one-step KDF from NIST SP 800-56Ar3 §5.8.2.1.  In particular, this is
> > not the two-step (extract-then-expand) KDF of the following section
> > (§5.8.2.2).  Since the (EC)DH shared secret Z is not uniformly random,
> > my understanding was that generally the two-step KDF was needed, since
> > the one-step KDF assumes that the input key is uniformly selected.  I am
> > not balloting Discuss for this point because I assume it was considered
> > in the formal verification, but I would very much appreciate some
> > additional insight into this selection.
> We did not specifically model the security of the KDF itself. The NIST 
> specification defines the one-step key derivation function for use with 
> ECDH shared secrets (NIST calls it 'Z' a byte string that represents the 
> shared secret). In fact RFC 7518 
> (https://datatracker.ietf.org/doc/html/rfc7518#section-4.6.2) uses the 
> same NIST KDF for deriving keys. The one-step may have stronger 
> ass

Re: [Emu] Francesca Palombini's Discuss on draft-ietf-emu-eap-noob-04: (with DISCUSS and COMMENT)

[Francesca Palombini]

Hi Mohit! 

Thanks for your answer and for addressing my DISCUSS, I will go ahead and 
remove the block now. All the rest of the comments also look good, however I am 
not convinced by 7: see my answer below. However this is minor and 
non-blocking, so I will let you and Roman decide if and how to implement a 
change.

Thanks,
Francesca

>
>Hi Francesca,
>
>We have submitted a new version ( 
>https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-noob-05 ) which 
>hopefully addresses your comments. Here is the diff for your 
>convenience: 
>https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-noob-05.txt
>
>See our answers below.
>
>--Mohit
>
>On 4/20/21 1:37 AM, Francesca Palombini via Datatracker wrote:
>> Francesca Palombini has entered the following ballot position for
>> draft-ietf-emu-eap-noob-04: Discuss
>>

...

>> 7. -
>>
>> and truncated to the 16 leftmost bytes of the output.  The message
>>
>> FP: please mention that network byte order is used (either here or in the
>> terminology).
>The byte order is relevant when encoding/decoding things like integers 
>etc. While cryptographic hash functions may use integers or 32- or 
>64-bit words internally, their output is a byte string, and the order of 
>the bytes in that output is defined by each individual hash function 
>specification (e.g. RFC 6234). We don’t think we should say anything 
>that could lead to a programmer mistakenly reordering the bytes in the 
>hash output.

FP: But the fact that you talk about "leftmost" bytes means that you are 
already implying ordering. Talking about leftmost without talking about 
ordering seems imprecise. Maybe you want to talk about the 16 most significant 
bytes instead.


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

Re: [Emu] Erik Kline's No Objection on draft-ietf-emu-eap-noob-04: (with COMMENT)

[Erik Kline]

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

Re: [Emu] Éric Vyncke's No Objection on draft-ietf-emu-eap-noob-04: (with COMMENT)

[Mohit Sethi M]

Hi Éric,

Thanks for the review. Answers below.

--Mohit

On 4/20/21 4:29 PM, Éric Vyncke via Datatracker wrote:
> Éric Vyncke has entered the following ballot position for
> draft-ietf-emu-eap-noob-04: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer tohttps://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/
>
>
>
> --
> COMMENT:
> --
>
> Thank you for the work put into this document. I really like the ideas behind
> this OOB authentication.
>
> Please find below some non-blocking COMMENT points (**but replies would be
> appreciated esp around CBOR**), and some nits.
>
> Special thanks to Dave Thaler for his early IoT directorate review (and the
> CBOR discussion with Carsten):
> https://datatracker.ietf.org/doc/review-ietf-emu-eap-noob-01-iotdir-early-thaler-2020-06-12/
> https://mailarchive.ietf.org/arch/msg/iot-directorate/PNi6nxtR7_1T2rxu7O49HRx5Kdg/
>
> I hope that this helps to improve the document,
>
> Regards,
>
> -éric
>
> PS: when the ballot for this document was created, I failed to spot the DNS &
> IoT aspects of it, hence, the absence of INT and IoT directorates telechat
> reviews.
>
> == COMMENTS ==
>
> Like Carsten, I am really puzzled by the lack of consideration of CBOR to
> replace JSON especially for a protocol aimed at constrained devices. Was this
> discussed at the WG level ? I was unable to read any discussion on the mail
> list except about the IoT directorate thread.
>
> This non-obvious choice of encoding ***should really be discussed*** in the
> document.

The working group had extensive discussion on the issue of CBOR vs JSON 
encoding. See, for example, slide 8 from IETF 108 
(https://datatracker.ietf.org/meeting/108/materials/slides-108-emu-eap-noob-00 
<https://datatracker.ietf.org/meeting/108/materials/slides-108-emu-eap-noob-00>).
 
At the end, there was consensus for using JSON (with the possibility of 
adding CBOR later). There were many reasons for this decision by the 
working group. First, there were several implementations and early 
deployments of EAP-NOOB already using JSON. Second, there is support for 
JSON encoding/decoding in wpa_supplicant. wpa_supplicant is the most 
popular EAP peer implementation. It does not have support for CBOR 
encoding/decoding. Third, devices using EAP are either class 1 or 2, as 
defined in RFC7228. So while the benefits of CBOR would have been nice, 
they can live with JSON.

> -- Section 2 --
> Please apply the current BCP 14 template and not the old RFC 2119 one.
We have updated the text.
> -- Section 3.1 --
> "timeout needs to be several minutes rather than seconds" can this lead to a
> DoS against the server, which potentially needs to keep states for minutes ?
We have added a new sub-section on "Denial of Service" in the security 
considerations section: 
https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-noob-05#section-7.8 

> -- Section 3.2.1 --
> I am not a EAP expert, so bear with my possibly naive question, "based on the
> realm part of the NAI", isn't it always "eap-noob.arpa" in this case ?
That's a good question. You are right that in the default case, it will 
always be eap-noob.arpa. However, EAP-NOOB allows the server to assign a 
new NAI: "the server MAY assign a new NAI to the peer in the Initial 
Exchange or Reconnect Exchange, in the NewNAI field of request types 2 
and 7, to override any previous NAI value.". So it can be different if 
the server assigns something other than eap-noob.arpa.
> -- Section 3.2.2 --
> What happens if the peer does not support any of the server's ciphersuite? Esp
> in the world of IoT where peers are old and cannot always be updated.Should
> there be a forward pointer to section 3.6.4 ?
We have tried to make the text readable by collecting error handling 
into one section (3.6), rather than constantly interrupting the flow of 
the text by mentioning possible error conditions. We hope that the list 
in section 3.6 gives the implementers a more complete picture of error 
handling than if some, but not all, errors were explained in the 
sections where they may occur.
> -- Section 3.2.3 --
> Suggest to give a hint to the reader for "Hoob": is this Hash of OoB ? Same
> comment for "Noob".
We expect those familiar with 

Re: [Emu] Francesca Palombini's Discuss on draft-ietf-emu-eap-noob-04: (with DISCUSS and COMMENT)

[Mohit Sethi M]

Hi Francesca,

We have submitted a new version ( 
https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-noob-05 ) which 
hopefully addresses your comments. Here is the diff for your 
convenience: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-noob-05.txt

See our answers below.

--Mohit

On 4/20/21 1:37 AM, Francesca Palombini via Datatracker wrote:
> Francesca Palombini has entered the following ballot position for
> draft-ietf-emu-eap-noob-04: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer tohttps://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/
>
>
>
> --
> DISCUSS:
> --
>
> Thank you for the work on this document. I have a couple of blocking comments
> related to the IANA section, which should be easy to fix, plus some minor non
> blocking comments below.
>
> Francesca
>
> 1. -
>
> Section 5.
>
> FP: IANA is requested to create a sub registry to the EAP registry, but there
> is no actual "Nimble out-of-band authentication for EAP Parameters" registry
> defined, nor values registered in it. Either this is a new page or (I would
> suggest) the subregistries are just created directly under the EAP page.
This question was also asked by Sabrina during the IANA review.  A 
separate URL (or page) for EAP-NOOB is what we intended. There is 
precedence for such an approach: EAP-FAST. There is a separate URL for 
EAP-FAST parameters: 
https://www.iana.org/assignments/eap-fast-parameters/eap-fast-parameters.xhtml 
but all the sub registries are still listed on the main EAP registry 
with links (such as 
https://www.iana.org/assignments/eap-numbers/eap-numbers.xhtml#eap-numbers-5). 
So we are hoping for the same, i.e.: i) a separate URL for the EAP-NOOB 
registry titled "Nimble out-of-band authentication for EAP Parameters", 
ii) the separate URL should contain sub registries listed in section 5.1 
to 5.5 of the draft, iii) the sub registries are listed in the EAP 
Registry 
(https://www.iana.org/assignments/eap-numbers/eap-numbers.xhtml) only as 
links pointing to the URL to the separate EAP-NOOB registry.
> 2. -
>
> Section 5.1 and following
>
> FP: This document defines several new registry with policy Specification
> required, which will need designated experts.
> https://tools.ietf.org/html/rfc8126#section-5.3  states that:
>
> When a designated expert is used, the documentation should give clear
> guidance to the designated expert, laying out criteria for performing
> an evaluation and reasons for rejecting a request.  In the case where
>
> I believe designated expert guidance should be added to this document.
We have added section "Guidance for Designated Experts": 
https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-noob-05#section-5.7. 
We hope this is sufficient.
> --
> COMMENT:
> --
>
> 3. -
>
> document are to be interpreted as described in [RFC2119].
>
> FP: Please update as indicated by RFC 8174.
Done.
> 4. -
>
> it supports, an indicator of the OOB channel directions it supports
> (Dirs), and a ServerInfo object.  The peer chooses one of the
>
> FP: Please add a reference to where the ServerInfo object is defined, as this
> is its first occurrence.
>
> 5. -
>
>|  (Type=3,PeerId,PKs,Ns,[SleepTime])  |
>
> FP: SleepTime appear in the figure without having been introduced in the
> previous paragraph, as the other parameters. I would suggest adding a sentence
> about it, including a fw reference to where it is explained in detail (3.2.5).
As authors we have tried to strike a careful balance between explaining 
new terms when they are first occur vs. avoiding repetition and 
interruptions to the readability of the text. Therefore, some terms like 
ServerInfo, PeerInfo, SleepTime etc. are not defined immediately. We 
hope this is an acceptable compromise.
> 6. -
>
> use this serve-assigned NAI.  When the peer moves to the Registered
>
> FP: nit - s/serve/server
Fixed.
> 7. -
>
> and truncated to the 16 leftmost bytes of the output.  The message
>
> FP: please mention that network byte order is used (either here

Re: [Emu] Erik Kline's No Objection on draft-ietf-emu-eap-noob-04: (with COMMENT)

[Mohit Sethi M]

Hi Erik,

Thanks for the review. Answers below.

--Mohit

On 4/19/21 1:32 AM, Erik Kline via Datatracker wrote:
> Erik Kline has entered the following ballot position for
> draft-ietf-emu-eap-noob-04: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer tohttps://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/
>
>
>
> --
> COMMENT:
> --
>
> [ section 2 ]
>
> * Do you want to use the 8174 language instead of the 2119 version?
Fixed.
> [ section 5.6 ]
>
> * For eap-noob.arpa (or noob.eap.arpa or whatever), even though
>Application Software, Name Resolution APIs and Libraries, and
>Caching DNS Servers are "not expected to recognize this domain
>name as special", there is no harm if they do recognize it and
>short circuit any resolution attempts, yes?
Earlier versions of the draft were using a different domain name 
(eap-noob.net 
:https://datatracker.ietf.org/doc/html/draft-aura-eap-noob-07#section-4.4). 
Back then, we had added section 5.6 and required authoritative DNS 
Servers to respond with NXDOMAIN. The working group later came to a 
consensus that such individual domain names are not ideal and we should 
instead reserve a special use domain under .arpa. Thus, the requirement 
for responding with NXDOMAIN is no longer needed and section 5.6 is 
redundant. We have now removed the section in latest draft: 
https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-noob-05.
> ___
> 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] I-D Action: draft-ietf-emu-eap-noob-05.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the EAP Method Update WG of the IETF.

Title   : Nimble out-of-band authentication for EAP (EAP-NOOB)
Authors : Tuomas Aura
  Mohit Sethi
  Aleksi Peltonen
Filename: draft-ietf-emu-eap-noob-05.txt
Pages   : 73
Date: 2021-07-12

Abstract:
   The 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 a non-network input or output interface, such as a
   display, microphone, speaker, or blinking light, which can send or
   receive dynamically generated messages of tens of bytes in length.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-noob-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-noob-05


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

[Emu] Genart last call review of draft-ietf-emu-eap-noob-04

[David Schinazi via Datatracker]

Reviewer: David Schinazi
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-emu-eap-noob-04
Reviewer: David Schinazi
Review Date: 2021-05-14
IETF LC End Date: 2021-04-13
IESG Telechat date: Not scheduled for a telechat

Summary: Well-written document.

Major issues: None

Minor issues: In s5.6 "AAA administrators may need to recognize the name" isn't
clear to me. If this document mentions that administrators may need to
recognize the name, it should specify what actions the administrators need to
take.

Nits/editorial comments: None



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

[Emu] Lars Eggert's No Objection on draft-ietf-emu-eap-noob-04: (with COMMENT)

[Lars Eggert via Datatracker]

Lars Eggert has entered the following ballot position for
draft-ietf-emu-eap-noob-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/



--
COMMENT:
--

All comments below are about potential very minor issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools, so there will likely be some false positives. There is no need
to let me know what you did with these suggestions.

Section 8.2, paragraph 2, nit:
>[BluetoothPairing]
>   Bluetooth, SIG, "Simple pairing whitepaper", Technical
>   report , 2007.

Add URL?

Section 1, paragraph 6, nit:
-Many proprietary OOB configuration methods exist for specific IoT
+Many proprietary out-of-band (OOB) configuration methods exist for
specific IoT + +   +

Section 1, paragraph 6, nit:
-use of a user-assisted out-of-band (OOB) channel.  The device
-   -   -
+use of a user-assisted OOB channel.  The device

Section 3.1, paragraph 10, nit:
-Success.  The reason is that, while EAP allows delays between the
--
+Success.  The reason is that while EAP allows delays between the

Section 6.4, paragraph 2, nit:
-process.  For example, we verified the correctness of the tiebreaking
+process.  For example, we verified the correctness of the tie-breaking
+ +

Section 3.3.2, paragraph 3, nit:
> ication | | | channel but it is included in the computation |
>   ^^^
Use a comma before 'but' if it connects two independent clauses (unless they
are closely connected and short).

Section 3.3.2, paragraph 3, nit:
>  to the OOB | | | channel and it is encoded as a JSON object of |
>   ^^^
Use a comma before 'and' if it connects two independent clauses (unless they
are closely connected and short).

Section 3.3.2, paragraph 3, nit:
> r | | | to the OOB channel and it is encoded as a JSON | |
>^^^
Use a comma before 'and' if it connects two independent clauses (unless they
are closely connected and short).

Section 3.4.2, paragraph 11, nit:
> ause the server does not store previous keys and it never rolls back a
cryptosuite up >  Use a comma
before 'and' if it connects two independent clauses (unless they are closely
connected and short).

Section 3.5, paragraph 2, nit:
> on. The auxiliary function H is a hash function and it is taken from the
negotiated cryp > Use a
comma before 'and' if it connects two independent clauses (unless they are
closely connected and short).

Section 3.5, paragraph 8, nit:
>  keys are exchanged. Input Z is the fresh shared secret from the ECDHE
exchange with >  Make sure that
the adjective 'fresh' is correct. Possibly, it should be an adverb (typically
~ly) that modifies 'shared'. Possibly, it should be the first word in a
compound adjective (hyphenated adjective). Possibly, it is correct.

Section 3.5, paragraph 11, nit:
> ed for application- layer security. Further output bytes are used internally
by EAP > ^^^ Did you forget a comma
after a conjunctive/linking adverb?

Section 3.6.5, paragraph 3, nit:
>  device may not have the capability for many different error indications to
the user and it MA > ^
Consider using "many".

Section 3.6.5, paragraph 3, nit:
> y different error indications to the user and it MAY use the same indication
as in >   Use a comma before 'and'
if it connects two independent clauses (unless they are closely connected and
short).

Section 4, paragraph 4, nit:
> ing. The | | | SSID is a ASCII string.
>^
Use "an" instead of 'a' if the following word starts with a vowel sound, e.g.
'an article', 'an hour'.

Section 5.3, paragraph 5, nit:
> tion Required" as defined in [RFC8126], with the exception of the range
6001-6999. This range is res >
 Consider using "except"

[Emu] Zaheduzzaman Sarker's No Objection on draft-ietf-emu-eap-noob-04: (with COMMENT)

[Zaheduzzaman Sarker via Datatracker]

Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-emu-eap-noob-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/



--
COMMENT:
--

Thanks for the effort on this.

Due to lack of time I had to do a quick review and I didn't find any transport
related issues.

However, I do think more guidance need to be added for creating IANA registries
and only referring to RFC8126 is not enough.



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

[Emu] Benjamin Kaduk's Discuss on draft-ietf-emu-eap-noob-04: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-emu-eap-noob-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/



--
DISCUSS:
--

The example JWK for cryptosuite 1 in §5.1 is not well-formed.  RFC 8037
key-exchange uses a crv of "X25519" and a kty of "OKP".
(See COMMENT for more quibbles with §5.1.)
I think Appendix E is also using the wrong "kty" for X25519 (but is
properly using "X25519" as the "crv").

I'd also like to discuss our treatment of channel binding, as the
current mention seems dangerously incomplete.  I don't remember if there
is generic discussion of channel binding in the core EAP RFCs (if so, a
specific reference would help), but otherwise if we're going to mention
that protocol elements can be used for channel binding we should give
some indication of how to actually do so in a secure manner (e.g., what
protocol element needs to be verified against external channel
information and what to do if they don't match).


--
COMMENT:
--

Thanks for putting together this pretty comprehensive treatment of a
topic that is simple to understand but has a lot of important details.
(I do have some comments about a few of those details, just to check
that we do have them right.)  I especially appreciate the strong feature
set that's been assembled.

In Section 3.5 we discuss a key derivation scheme and say to use the
one-step KDF from NIST SP 800-56Ar3 §5.8.2.1.  In particular, this is
not the two-step (extract-then-expand) KDF of the following section
(§5.8.2.2).  Since the (EC)DH shared secret Z is not uniformly random,
my understanding was that generally the two-step KDF was needed, since
the one-step KDF assumes that the input key is uniformly selected.  I am
not balloting Discuss for this point because I assume it was considered
in the formal verification, but I would very much appreciate some
additional insight into this selection.

Section 3.1

   The overall protocol starts with the Initial Exchange, which
   comprises four EAP request-response pairs.  In the Initial Exchange,
   the server allocates an identifier to the peer, and the server and

Is this a DoS risk for state exhaustion on the server?

   The server MUST NOT repeat a successful OOB Step with the same peer
   except if the association with the peer is explicitly reset by the
   user or lost due to failure of the persistent storage in the server.
   More specifically, once the association has entered the Registered
   state, the server MUST NOT delete the association or go back to the
   ephemeral states 0..2 without explicit user approval.  [...]

This also looks like a DoS risk, if a malicious device/user completes
the OOB step then only deletes the association on the device (without
telling the server), then re-registers, deletes again, etc.  The server
is required to maintain state without bound.

   However, it MUST NOT delete or merge redundant associations without
   user or application approval because EAP-NOOB internally has no
   secure way of verifying that the two peers are the same physical
   device.  [...]

No way other than the registered cryptographic key that's used to
authenticate the Reconnect Exchange, that is?

   A special feature of the EAP-NOOB method is that the server is not
   assumed to have any a-priori knowledge of the peer.  Therefore, the
   peer initially uses the generic identity string "n...@eap-noob.arpa"
   as its network access identifier (NAI).  [...]

This looks like codepoint squatting, since we haven't received an early
allocation of this entry in .arpa.

section 3.2.1

   After receiving the EAP-Response/Identity message, the server sends
   the first EAP-NOOB request (Type=1) to the peer, which responds with
   the peer identifier (PeerId) and state (PeerState) in the range 0..3.
   However, the peer SHOULD omit the PeerId from the response (Type=1)
   when PeerState=0.  [...]

Why only SHOULD and not MUST?

Section 3.2.3

Can we give any guidance for how to set OobRetries?

Section 3.2.4

  In the request, the server sends the NoobId
   value, which the peer uses to identify the exact OOB message received
   by the server.  [...]

This is the first time we mention the NoobId value, so some more
explanation or

[Emu] Éric Vyncke's No Objection on draft-ietf-emu-eap-noob-04: (with COMMENT)

[Éric Vyncke via Datatracker]

Éric Vyncke has entered the following ballot position for
draft-ietf-emu-eap-noob-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/



--
COMMENT:
--

Thank you for the work put into this document. I really like the ideas behind
this OOB authentication.

Please find below some non-blocking COMMENT points (**but replies would be
appreciated esp around CBOR**), and some nits.

Special thanks to Dave Thaler for his early IoT directorate review (and the
CBOR discussion with Carsten):
https://datatracker.ietf.org/doc/review-ietf-emu-eap-noob-01-iotdir-early-thaler-2020-06-12/
https://mailarchive.ietf.org/arch/msg/iot-directorate/PNi6nxtR7_1T2rxu7O49HRx5Kdg/

I hope that this helps to improve the document,

Regards,

-éric

PS: when the ballot for this document was created, I failed to spot the DNS &
IoT aspects of it, hence, the absence of INT and IoT directorates telechat
reviews.

== COMMENTS ==

Like Carsten, I am really puzzled by the lack of consideration of CBOR to
replace JSON especially for a protocol aimed at constrained devices. Was this
discussed at the WG level ? I was unable to read any discussion on the mail
list except about the IoT directorate thread.

This non-obvious choice of encoding ***should really be discussed*** in the
document.

-- Section 2 --
Please apply the current BCP 14 template and not the old RFC 2119 one.

-- Section 3.1 --
"timeout needs to be several minutes rather than seconds" can this lead to a
DoS against the server, which potentially needs to keep states for minutes ?

-- Section 3.2.1 --
I am not a EAP expert, so bear with my possibly naive question, "based on the
realm part of the NAI", isn't it always "eap-noob.arpa" in this case ?

-- Section 3.2.2 --
What happens if the peer does not support any of the server's ciphersuite? Esp
in the world of IoT where peers are old and cannot always be updated.Should
there be a forward pointer to section 3.6.4 ?

-- Section 3.2.3 --
Suggest to give a hint to the reader for "Hoob": is this Hash of OoB ? Same
comment for "Noob".

== NITS ==

Global nit: I prefer the use of 'octet' rather than 'byte'.

-- Section 1 --
Please avoid the use of 'we' as in 'We thus do not support'.



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

[Emu] Francesca Palombini's Discuss on draft-ietf-emu-eap-noob-04: (with DISCUSS and COMMENT)

[Francesca Palombini via Datatracker]

Francesca Palombini has entered the following ballot position for
draft-ietf-emu-eap-noob-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/



--
DISCUSS:
--

Thank you for the work on this document. I have a couple of blocking comments
related to the IANA section, which should be easy to fix, plus some minor non
blocking comments below.

Francesca

1. -

Section 5.

FP: IANA is requested to create a sub registry to the EAP registry, but there
is no actual "Nimble out-of-band authentication for EAP Parameters" registry
defined, nor values registered in it. Either this is a new page or (I would
suggest) the subregistries are just created directly under the EAP page.

2. -

Section 5.1 and following

FP: This document defines several new registry with policy Specification
required, which will need designated experts.
https://tools.ietf.org/html/rfc8126#section-5.3 states that:

   When a designated expert is used, the documentation should give clear
   guidance to the designated expert, laying out criteria for performing
   an evaluation and reasons for rejecting a request.  In the case where

I believe designated expert guidance should be added to this document.


--
COMMENT:
--

3. -

   document are to be interpreted as described in [RFC2119].

FP: Please update as indicated by RFC 8174.

4. -

   it supports, an indicator of the OOB channel directions it supports
   (Dirs), and a ServerInfo object.  The peer chooses one of the

FP: Please add a reference to where the ServerInfo object is defined, as this
is its first occurrence.

5. -

  |  (Type=3,PeerId,PKs,Ns,[SleepTime])  |

FP: SleepTime appear in the figure without having been introduced in the
previous paragraph, as the other parameters. I would suggest adding a sentence
about it, including a fw reference to where it is explained in detail (3.2.5).

6. -

   use this serve-assigned NAI.  When the peer moves to the Registered

FP: nit - s/serve/server

7. -

   and truncated to the 16 leftmost bytes of the output.  The message

FP: please mention that network byte order is used (either here or in the
terminology).

8. -

   reasons.  New EAP output values MSK and EMSK may be needed because of

FP: MSK and EMSK appear here for the first time, please expand.

9. -

  Hoob = H(Dir,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,Cryptos
  uitep,Dirp,[NewNAI],PeerInfo,0,PKs,Ns,PKp,Np,Noob).

  ...

  MACs = HMAC(Kms; 2,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,C
  ryptosuitep,Dirp,[NewNAI],PeerInfo,0,PKs,Ns,PKp,Np,Noob).

FP: I would suggest to add a sentence explicitly stating that H and HMAC are
the hash function and HMAC specified in this paragraph:

   The fingerprint Hoob and the identifier NoobId are computed with the
   cryptographic hash function specified in the negotiated cryptosuite
   and truncated to the 16 leftmost bytes of the output.  The message
   authentication codes (MACs, MACp, MACs2, MACp2) are computed with the
   HMAC function [RFC2104] based on the same cryptographic hash function
   and truncated to the 32 leftmost bytes of the output.

10. -

   |  | integer. The registration of cryptosuites is   |
   |  | specified in Section 5.1. Example values are   |
   |  | "[1]" and "1", respectively.   |

FP: not only registration, but also MTI and examples.

11. -

   for EAP Parameters" registry.  Cryptosuites are identified by an
   integer.  EAP-NOOB request and response pairs are identified by an

FP: "Cryptosuite ... integer." I don't understand the point of having this
sentence in this section, is this copy paste? (sections 5.2, 5.3)

12. -

  | 1007   | Invalid ECDHE key  |

FP: Out of curiosity, any special reason why this is not 1005?

13. -

Appendix E.

FP: are the examples generated with any of the implementations mentioned? It
would be good to state that in the first paragraph of the appendix. Also I am
curious if the JSON examples were validated.



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

[Emu] Erik Kline's No Objection on draft-ietf-emu-eap-noob-04: (with COMMENT)

[Erik Kline via Datatracker]

Erik Kline has entered the following ballot position for
draft-ietf-emu-eap-noob-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/



--
COMMENT:
--

[ section 2 ]

* Do you want to use the 8174 language instead of the 2119 version?

[ section 5.6 ]

* For eap-noob.arpa (or noob.eap.arpa or whatever), even though
  Application Software, Name Resolution APIs and Libraries, and
  Caching DNS Servers are "not expected to recognize this domain
  name as special", there is no harm if they do recognize it and
  short circuit any resolution attempts, yes?



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

[Emu] I-D Action: draft-ietf-emu-eap-noob-04.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the EAP Method Update WG of the IETF.

Title   : Nimble out-of-band authentication for EAP (EAP-NOOB)
Authors : Tuomas Aura
  Mohit Sethi
  Aleksi Peltonen
Filename: draft-ietf-emu-eap-noob-04.txt
Pages   : 70
Date: 2021-03-16

Abstract:
   The 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, speaker or blinking light, which can send or receive
   dynamically generated messages of tens of bytes in length.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-emu-eap-noob-04
https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-noob-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-noob-04


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

[Emu] Publication has been requested for draft-ietf-emu-eap-noob-03

[Joseph Salowey via Datatracker]

Joseph Salowey has requested publication of draft-ietf-emu-eap-noob-03 as 
Proposed Standard on behalf of the EMU working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/


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

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

[Emu] I-D Action: draft-ietf-emu-eap-noob-03.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the EAP Method Update WG of the IETF.

Title   : Nimble out-of-band authentication for EAP (EAP-NOOB)
Authors : Tuomas Aura
  Mohit Sethi
  Aleksi Peltonen
Filename: draft-ietf-emu-eap-noob-03.txt
Pages   : 67
Date: 2020-12-13

Abstract:
   The 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, speaker or blinking light, which can send or receive
   dynamically generated messages of tens of bytes in length.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-emu-eap-noob-03
https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-noob-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-noob-03


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

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

[Eduardo Ingles (UM)]

Hi all,

I have worked with EAP-NOOB and implemented a constrained version for 
Contiki (https://github.com/eduingles/coap-eap-noob). I exposed some 
issues on the list such as adding support for P-256 and clarifying the 
text on waiting exchange and the authors have addressed my issues. The 
draft now has P-256 as one of the curves. I support it and I think it is 
ready for publication.


Best regards,
Eduardo Inglés

El 22/11/2020 a las 0:31, Joseph Salowey escribió:
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.


Thanks,

Joe

[1] https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/ 
<https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/>



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


--
Eduardo Inglés Sánchez
eduardo.ing...@um.es

Department of Information and Communication Engineering
Faculty of Computer Science
University of Murcia
30100 Murcia, Spain

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

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

[Alan DeKok]

> 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

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

[Dan Garcia]

Hello all,

I have read the draft and I think it is useful tool to have within the 
EAP framework. I support its publication.


Regards,
Dan

El 03/12/2020 a las 9:22, Aleksi Peltonen escribió:


I think the draft is ready. I was involved in the formal modeling of 
the protocol with both ProVerif and mCRL2. All issues discovered from 
the modeling phase have been addressed in the current draft. I am also 
working on modeling other protocols, including EAP methods, and will 
share my results when they are published.


Best regards,
Aleksi

On 22/11/2020 01:31, 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.


Thanks,

Joe

[1] https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/ 
<https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/>



___
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 mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Aleksi Peltonen]

I think the draft is ready. I was involved in the formal modeling of the 
protocol with both ProVerif and mCRL2. All issues discovered from the 
modeling phase have been addressed in the current draft. I am also 
working on modeling other protocols, including EAP methods, and will 
share my results when they are published.


Best regards,
Aleksi

On 22/11/2020 01:31, 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.


Thanks,

Joe

[1] https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/


___
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] Working Group Last Call for draft-ietf-emu-eap-noob-02

[Joseph Salowey]

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.

Thanks,

Joe

[1] https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/
___
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

[Carsten Bormann]

The point that came up in the discussion is how deterministic encoding would 
work with the extension points.

I said that it is easy to isolate extension points via encapsulation of an 
encoded CBOR data item in a byte string — that causes a generic decoder to hand 
up that byte string (which can then be decoded separately, and which can go 
into a signature input unchanged).

Tuomas noted that the extension points are not very clearly delineated in the 
document.  My personal recommendation would be to make those very explicit (*).

I maybe didn’t understand part of the discussion; it seemed that you currently 
require something of your JSON libraries that is much less widely implemented 
than canonical/deterministic encoding in CBOR libraries.

I do understand that this change requires work in implementations.  I cannot 
comment on whether getting this right or getting this done quickly is more 
important.

Grüße, Carsten

(*) My personal recommendation would also be to define the data structures and 
their extension points using some formal technique.  Independent of whether 
they are JSON or CBOR, CDDL (RFC 8610) fits the bill.


> On 2020-07-31, at 09:51, Carsten Bormann  wrote:
> 
> On 2020-07-31, at 09:25, Aura Tuomas  wrote:
>> 
>> 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.
> 
> rfc7049bis (in IETF last call, ends 2020-08-14) provides rules for 
> deterministic encoding (called canonical in RFC 7049).
> I am not a big fan of protocols that require its use, but if that is your 
> design, CBOR has the support.
> 
> Grüße, Carsten
> 

___
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

[Carsten Bormann]

On 2020-07-31, at 09:25, Aura Tuomas  wrote:
> 
> 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.

rfc7049bis (in IETF last call, ends 2020-08-14) provides rules for 
deterministic encoding (called canonical in RFC 7049).
I am not a big fan of protocols that require its use, but if that is your 
design, CBOR has the support.

Grüße, Carsten

___
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 
&g

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.   

[Emu] I-D Action: draft-ietf-emu-eap-noob-02.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the EAP Method Update WG of the IETF.

Title   : Nimble out-of-band authentication for EAP (EAP-NOOB)
Authors : Tuomas Aura
  Mohit Sethi
Filename: draft-ietf-emu-eap-noob-02.txt
Pages   : 66
Date: 2020-07-12

Abstract:
   The 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.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-emu-eap-noob-02
https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-noob-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-noob-02


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
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

[Benjamin Kaduk]

On Sat, Jul 11, 2020 at 03:40:25PM +0200, Carsten Bormann wrote:
> Hi Mohit,
> 
> 
> > On 2020-07-11, at 15:27, Mohit Sethi M 
> >  wrote:
> > 
> > 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.

draft-ietf-cose-rfc8152bis-struct and draft-ietf-cose-rfc8152bis-algs have
section structure, too :)

-Ben

___
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

[Mohit Sethi M]

Thanks Carsten. This is very valuable input for the working group before 
it makes a critical decision.

--Mohit

On 7/11/20 4:40 PM, Carsten Bormann wrote:
> 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://protect2.fireeye.com/v1/url?k=be5e912f-e0fe3fe2-be5ed1b4-866132fe445e-d1e084c426bf1ae9=1=3870678c-1f3b-4f09-8cde-269a88395e80=https%3A%2F%2Fw1.fi%2Fcgit%2Fhostap%2Ftree%2Fsrc%2Futils%2Fjson.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://protect2.fireeye.com/v1/url?k=e6a1854a-b8012b87-e6a1c5d1-866132fe445e-29d16d211c0fc3e9=1=3870678c-1f3b-4f09-8cde-269a88395e80=https%3A%2F%2Fcbor.io%2Fimpls.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 to make sure you don’t make your decision for the wrong reasons.
>
> Grüße, Carsten
>
___
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

[Carsten Bormann]

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 to make sure you don’t make your decision for the wrong reasons.

Grüße, Carsten

___
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

[Mohit Sethi M]

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

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.

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.
- Updating and maintaining two components is definitely harder than one.

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

--Mohit


On 7/8/20 8:12 PM, Michael Richardson wrote:


Speaking as a WG participant.

Dave Thaler via Datatracker  wrote:
> 3) Section 3.3.2 says:
>> The in-band messages are formatted as JSON objects [RFC8259]

> So this limits applicability to constrained IoT devices, since JSON can be
> verbose compared to, say, CBOR, and if the IoT device already uses CBOR 
for
> its normal protocol use this requires adding a separate parser for JSON 
which
> may cause code size issues.   Is there a rationale for why CBOR could not 
be
> an option?  E.g., if this protocol is not applicable for constrained 
devices,
> then say so.  (I don’t know whether EAP itself already inherently has
> problems that limit its applicability for constrained devices.)

I think that the document predates widespread availability of CBOR :-)
I think that it would benefit from only using CBOR, as CBOR works into EAP
much better than I think JSON does.
That would be a radical change, but the document as only just been adopted by
the EMU WG.

To the extent that EAP is used more on 802.11 rather than 802.15.4 [not that
you can't do EAP/1x on 15.4, it just hasn't caught on], IoT devices that have
power budget for WiFi can generally do EAP.  There is a large variety of
arduino class devices running FreeRTOS+micropython, for instance, which
already have EAP supplicants.

CBOR would be easier for them in the C code parts of them, while if the
EAP-NOOB were to involve the python code (for callbacks, etc.) it wouldn't
matter much as whether JSON or CBOR, it would likely be presented as python
dict() anyway.

Where there is a problem is a slightly smaller class of device which use
various WiFi *MODULES*.  Usually the microcontroller speaks i2c to this
module, and the module takes care of all the TCP/IP/Ethernet/WiFi stuff.
Those devices do not use EAP today, and they are hard to upgrade.
(and from a security point of view, those architectures concern me greatly)

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







___
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] implementation status for draft-ietf-emu-eap-noob-01

[Max Crone]

Hi all,

The implementation of EAP-NOOB in hostap that I have been working on 
over the past few months is now compliant with the latest draft again. 
The most notable additions include support for the NIST P-256 
cryptosuite and implementation of all the three different keying modes 
for the Reconnect Exchange.


The source code can be found on GitHub for now, where we work to improve 
it. See https://github.com/vogeltak/hostap.


With kind regards,

Max Crone

___
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

[Michael Richardson]

Speaking as a WG participant.

Dave Thaler via Datatracker  wrote:
> 3) Section 3.3.2 says:
>> The in-band messages are formatted as JSON objects [RFC8259]

> So this limits applicability to constrained IoT devices, since JSON can be
> verbose compared to, say, CBOR, and if the IoT device already uses CBOR 
for
> its normal protocol use this requires adding a separate parser for JSON 
which
> may cause code size issues.   Is there a rationale for why CBOR could not 
be
> an option?  E.g., if this protocol is not applicable for constrained 
devices,
> then say so.  (I don’t know whether EAP itself already inherently has
> problems that limit its applicability for constrained devices.)

I think that the document predates widespread availability of CBOR :-)
I think that it would benefit from only using CBOR, as CBOR works into EAP
much better than I think JSON does.
That would be a radical change, but the document as only just been adopted by
the EMU WG.

To the extent that EAP is used more on 802.11 rather than 802.15.4 [not that
you can't do EAP/1x on 15.4, it just hasn't caught on], IoT devices that have
power budget for WiFi can generally do EAP.  There is a large variety of
arduino class devices running FreeRTOS+micropython, for instance, which
already have EAP supplicants.

CBOR would be easier for them in the C code parts of them, while if the
EAP-NOOB were to involve the python code (for callbacks, etc.) it wouldn't
matter much as whether JSON or CBOR, it would likely be presented as python
dict() anyway.

Where there is a problem is a slightly smaller class of device which use
various WiFi *MODULES*.  Usually the microcontroller speaks i2c to this
module, and the module takes care of all the TCP/IP/Ethernet/WiFi stuff.
Those devices do not use EAP today, and they are hard to upgrade.
(and from a security point of view, those architectures concern me greatly)

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





signature.asc
Description: PGP signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] draft-ietf-emu-eap-noob-01 incorrect curve name in example messages

[Mohit Sethi M]

Hi Max,

Good catch. This will be fixed in the next version!

--Mohit

On 7/3/20 12:21 PM, Max Crone wrote:
> Hi,
>
> I noticed that the examples messages in Appendix F 
> (https://tools.ietf.org/html/draft-ietf-emu-eap-noob-01#appendix-F) 
> use the curve name "Curve25519" in the JWK object. However, according 
> to the IANA registry 
> (https://www.iana.org/assignments/jose/jose.xhtml#web-key-elliptic-curve), 
> the curve name should be "X25519".
>
> In the implementation I am working on I will thus use the latter, 
> trusting that the draft will update to conform to the IANA registry.
>
> With kind regards,
>
> Max Crone
>
> ___
> 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] draft-ietf-emu-eap-noob-01 incorrect curve name in example messages

[Max Crone]

Hi,

I noticed that the examples messages in Appendix F 
(https://tools.ietf.org/html/draft-ietf-emu-eap-noob-01#appendix-F) use 
the curve name "Curve25519" in the JWK object. However, according to the 
IANA registry 
(https://www.iana.org/assignments/jose/jose.xhtml#web-key-elliptic-curve), 
the curve name should be "X25519".


In the implementation I am working on I will thus use the latter, 
trusting that the draft will update to conform to the IANA registry.


With kind regards,

Max Crone

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

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

[Mohit Sethi M]

Hi Steve,

I have answered each question in-line.

On 6/29/20 2:54 AM, Steve Hanna via Datatracker wrote:
> Reviewer: Steve Hanna
> Review result: Not Ready
>
> Reviewer: Steve Hanna
> Review result: Not Ready
>
> I have reviewed this document as part of the security directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written primarily for the benefit of the security area 
> directors.
>   Document editors and WG chairs should treat these comments just like any 
> other
> last call comments.
>
> This document defines a new EAP method for bootstrapping IoT devices.
>
> After reading the document, I have many questions:
>
> * Bootstrapping an IoT device involves many tasks that extend far beyond what
> is accomplished by EAP-NOOB: configuring the services that the device
> can/should employ within its new context (including how to reach and
> authenticate them), the networks and protocols that it should use and how it
> should obtain access to those networks, the access control policies that it
> should use (who is permitted to access the device and what operations can they
> perform), as well as many other configuration elements such as which lights a
> switch should control. The current document does not specify how such things
> are provisioned or even hint at this as an important problem. Without
> specifying such things, only a tiny part of the IoT device configuration
> problem has been solved. Perhaps another provisioning protocol could be used
> after EAP-NOOB but that protocol would need to be specified. With this extra
> step would come more complexity and user effort. Why not do this all with one
> protocol?

That's not how the Internet or standardization works.

Why stop here with the requirements. Maybe EAP-NOOB should also address 
how the software on these devices is updated since that is a necessary 
precursor to updating the elliptic curves used by the protocol. Maybe 
EAP-NOOB should also ensure quantum resistance since quantum computers 
will be available any day. Maybe EAP-NOOB should also periodically 
provide verifiable device health reports after the initial configuration 
is complete.

The point I am trying to make here is that there needs to be a careful 
balance between salami style protocol knick knacks that don't fit 
together and a gargantuan all encompassing protocol that is never 
completed (or deployed).

There are over 52 EAP authentication methods. Can you name one which 
also provisions access control policies for resources on the peer 
device. The answer would be a clear no. There is a reason for that. We 
have other protocols to deal with access control policies. For IoT 
devices, we have ACE (Authentication and Authorization for Constrained 
Environments: https://datatracker.ietf.org/wg/ace/charter/) doing that 
work.

You talk about configuring what protocols the IoT device should use 
after obtaining initial network connectivity? I wonder what kind of 
imaginary IoT devices have multiple protocols implemented (for doing the 
same job) that would require some sort of selection.

EAP-NOOB does export a AMSK after successful authentication. Whether 
this AMSK is used for configuring access control policies or for 
protecting higher-layer protocols is up to other protocol specifications 
and device developers. EAP-NOOB also includes exchange of protected 
ServerInfo and PeerInfo JSON objects that can supply deployment specific 
configuration information. Appendix C 
(https://tools.ietf.org/html/draft-ietf-emu-eap-noob-01#appendix-C) even 
suggests that servers can provide a list of SSIDs to the peer that it 
can successfully connect to later on.

>
> * IoT device provisioning is not a new problem. In fact, it has been solved
> hundreds of times. Most of those solutions are proprietary but some standards
> efforts are ongoing now: IoTopia, FIDO IoT, Connected Home over IP, IP-BLiS,
> etc. Why ignore these? Why not reach out and try to help them?

You missed Device Provisioning Protocol (DPP), Amazon Frustration Free 
Setup (https://developer.amazon.com/frustration-free-setup). I sincerely 
hope you have posed the same question of outreach to all them. I 
obviously cannot control (or participate) in all those other standards 
bodies. The fact that there are many people working in this area only 
proves that this is relevant problem and that there is no definite 
solution (not that I expect a single protocol to rule the entire world). 
The EMU working group was chartered to 
(https://datatracker.ietf.org/group/emu/about/) "Define a standard EAP 
method for mutual authentication between a peer and a server that is 
based on an out-of-band channel. The method itself should be independent 
of the underlying OOB channel and shall support a variety of OOB 
channels such as NFC, dynamically generated QR co

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

[Michael Richardson]

Steve Hanna via Datatracker  wrote:
> Reviewer: Steve Hanna
> Review result: Not Ready

Steve thanks for the great review!
I wanted to respond as an IoT onboarding expert and EMU WG member.

> * Bootstrapping an IoT device involves many tasks that extend far beyond 
what
> is accomplished by EAP-NOOB: configuring the services that the device
> can/should employ within its new context (including how to reach and

Hi, so your comments are well taken, but it's really an unreasonably high
standard.  While it is really important to get the configuration mechanisms
in place, they are even more diverse than onboarding.
That's an entire ocean of disagreement here.
I would certainly love to get a handle on this.
When it comes to standardization, really have to be very selective on how big
a thing to bite off.  I think that we can incrementally get to this, but
first we need some success with getting even one onboarding spec working.

So I don't think it's reasonable to evaluate EAP-NOOB (or BRSKI-TEEP) by this 
critiera.

> * IoT device provisioning is not a new problem. In fact, it has been 
solved
> hundreds of times. Most of those solutions are proprietary but some 
standards
> efforts are ongoing now: IoTopia, FIDO IoT, Connected Home over IP, 
IP-BLiS,
> etc. Why ignore these? Why not reach out and try to help them?

Well, of those groups, many of them are completely pay-to-play fora, and do
all of their work behind closed doors. In many cases, they look to the IETF
for components, such as EAP-NOOB, BRSKI, etc. that they can incorporate into
their designs.  Some are actively hostile towards an an actual written
standard, preferring that everyone license a particular software stack instead.
I think that EAP-NOOB has benefited greatly from academic and industrial review.

> * This proposal assumes that the IoT device has a user interface (camera,
> screen, etc.). What about those that don’t?

Yup. Some don't, and you need to do something else.
But, a lot of devices *do* have displays.
Think about any industrial or hospital instrument.
They all go "ping", and have a cool display to put a graph on :-)

> * Won’t this protocol apply to a relatively small subset of the networks 
that
> IoT devices will need to connect to? Few IoT networks run EAP.

EAP is very popular in industrial and enterprise situations.
EAP can be easily introduced into home network, with the Authentication
Server running locally.  Many have done this, and it is supported in Openwrt 
today.

> * How will the device know which network to connect to, in the first
> place?

This is a good question, and I can offer no answer for the EAP-NOOB case, and
I leave it to the authors to respond to your other comments.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[


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





signature.asc
Description: PGP signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Secdir early review of draft-ietf-emu-eap-noob-01

[Steve Hanna via Datatracker]

Reviewer: Steve Hanna
Review result: Not Ready

Reviewer: Steve Hanna
Review result: Not Ready

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat these comments just like any other
last call comments.

This document defines a new EAP method for bootstrapping IoT devices.

After reading the document, I have many questions:

* Bootstrapping an IoT device involves many tasks that extend far beyond what
is accomplished by EAP-NOOB: configuring the services that the device
can/should employ within its new context (including how to reach and
authenticate them), the networks and protocols that it should use and how it
should obtain access to those networks, the access control policies that it
should use (who is permitted to access the device and what operations can they
perform), as well as many other configuration elements such as which lights a
switch should control. The current document does not specify how such things
are provisioned or even hint at this as an important problem. Without
specifying such things, only a tiny part of the IoT device configuration
problem has been solved. Perhaps another provisioning protocol could be used
after EAP-NOOB but that protocol would need to be specified. With this extra
step would come more complexity and user effort. Why not do this all with one
protocol?

* IoT device provisioning is not a new problem. In fact, it has been solved
hundreds of times. Most of those solutions are proprietary but some standards
efforts are ongoing now: IoTopia, FIDO IoT, Connected Home over IP, IP-BLiS,
etc. Why ignore these? Why not reach out and try to help them?

* This proposal assumes that the IoT device has a user interface (camera,
screen, etc.). What about those that don’t? Many small IoT devices do not have
a user interface of any sort or they only have a very primitive UI: a
temperature sensor, motion detector, wall switch, light bulb, circuit breaker,
etc.

* Won’t this protocol apply to a relatively small subset of the networks that
IoT devices will need to connect to? Few IoT networks run EAP. Mainly, EAP
seems to be used in cellular networks and enterprise Ethernet and Wi-Fi
networks. How will EAP-NOOB work in the Smart Home, where Wi-Fi is the most
common network type and EAP is not used?

* How will the device know which network to connect to, in the first place? At
most locations, there are many wireless networks. Do you envision the user
selecting from a list of Wi-Fi SSIDs and entering the network password with a
touchscreen and keypad? What about the small IoT devices that don’t have a
touchscreen and keypad? The server can’t help because the device is not yet
connected to the network.

* How will the user get OOB Output from the OOB sender to the OOB receiver? The
specification doesn’t seem to  As an IoT device maker, what am I supposed to
put into the instructions? Ask your local network administrator what to do?

* If the server indicates that it can handle peer-to-server OOB, what does that
mean? Must the server have a camera? If so, what is it expected to scan and
process? And if the peer prints out a page with a QR code, what should go into
the code? The same questions apply to OOB implemented with audio, flashing
LEDs, NFC, etc. In order to achieve interoperability, all of the details of
these OOB methods would need to be specified exactly. The current specification
includes no information like this. Without this information, multi-vendor
interoperability is highly unlikely. Even if each OOB method was fully
specified, consumers would still be frustrated if their server only supports QR
codes and their device only supports NFC or audio.

In my view, this protocol as currently specified is mainly of theoretical
interest. I could not recommend that the IETF adopt it as an RFC as it would
have almost no practical value.



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

Re: [Emu] Early allocation request for an EAP Method Type number for draft-ietf-emu-eap-noob

[Joseph Salowey]

There have been some recent reviews  for EAP-NOOB.  I think it would be
prudent to wait until this round of comments are resolved before moving
forward with the request for early allocation.

On Tue, May 26, 2020 at 1:53 AM Mohit Sethi M 
wrote:

> I would add that there is also an early implementation of EAP-TLS-PSK:
> https://github.com/rohitshubham/EAP-TLS-PSK
>
> We had agreed that external PSK authentication for EAP-TLS will use a new
> method type number. The draft for EAP-TLS-PSK (
> https://tools.ietf.org/html/draft-mattsson-emu-eap-tls-psk-00) is still
> in the early stages and will undergo many changes before it can be
> considered for adoption by the working group. However, allocating a method
> type number for EAP-NOOB now would ensure that EAP-TLS-PSK doesn't use the
> same code point.
>
> --Mohit
> On 5/26/20 6:56 AM, Joseph Salowey wrote:
>
> The authors of EAP-NOOB (draft-ietf-emu-eap-noob) have requested early
> allocation of the EAP type code value 56.  If you object to the early code
> point assignment please let the list know why by June 14, 2020.
>
> The criteria for early assignment includes the following:
>
> A.The code points must be from a space designated as "RFC Required",
> "IETF Review", or "Standards Action".  Additionally, requests for early
> assignment of code points from a "Specification Required" registry are
> allowed if the specification will be published as an RFC.
>
> EAP Methods have an allocation policy of Designated Expert, with
> Specification Required.  The specification in this case the
> draft-ietf-emu-eap-noob.
>
> B.  The format, semantics, processing, and other rules related to handling
> the protocol entities defined by the code points henceforth called
> "specifications") must be adequately described in an Internet-Draft.
>
> The specification draft-ietf-emu-eap-noob-00 contains the protocol
> specifics.  There are implementations based on this specification listed
> below
>
> C. The specifications of these code points must be stable; i.e., if there
> is a change, implementations based on the earlier and later specifications
> must be seamlessly interoperable.
>
> Although the document is a 00 document, the predecessor document
> draft-aura-eap-noob
> <https://datatracker.ietf.org/doc/draft-aura-eap-noob/> has been
> discussed for over a year.  This call is a request for working group
> members to review the document and object if the specification is not
> stable.
>
> D. There is sufficient interest in the community for early (pre-RFC)
> implementation and deployment, or that failure to make an early allocation
> might lead to contention for the code point in the field.
>
> Several implementations exist, but it would be good to see if there is
> additional interest in implementing this protocol
>
> The authors note that currently, the following implementations of EAP-NOOB
> exist:
>
> 1. Implementation with wpa_supplicant (client) and hostapd (server):
> https://github.com/tuomaura/eap-noob
>
> 2. Lightweight implementation on Contiki (client only):
> https://github.com/eduingles/coap-eap-noob (Tested with server
> implementation from #1)
>
> 3. Minimal EAP-NOOB (based on #1 with cleaner code and updates to match
> current draft version): https://github.com/Vogeltak/eap-noob
>
> Thanks,
>
> Joe
>
> ___
> Emu mailing listEmu@ietf.orghttps://www.ietf.org/mailman/listinfo/emu
>
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Dave Thaler via Datatracker]

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 like EAP (RFC 3748) section 1.3 has.

3) Section 3.3.2 says:
> The in-band messages are formatted as JSON objects [RFC8259]

So this limits applicability to constrained IoT devices, since JSON can be
verbose compared to, say, CBOR, and if the IoT device already uses CBOR for
its normal protocol use this requires adding a separate parser for JSON which
may cause code size issues.   Is there a rationale for why CBOR could not be
an option?  E.g., if this protocol is not applicable for constrained devices,
then say so.  (I don’t know whether EAP itself already inherently has
problems that limit its applicability for constrained devices.)

4) Appendix E says:
> The ServerInfo in this case includes a JSON member called ServerUrl
> of the following format with maximum length of 60 characters:

Just an observation: This limits applicability to servers that can get short
hostnames (and paths), which might make it less applicable users in some
cultures/languages.


Interoperability


5) Section 3.1 says:
> The server and peer MAY implement user reset of 
> the association by deleting the state data from that endpoint.  If an
> endpoint continues to store data about the association after the user
> reset, its behavior SHOULD be equivalent to having deleted the
> association data.

As phrased, there are 3 compliant behaviors:
Behavior 1) Follow the MAY and delete the data
Behavior 2) Don’t follow the MAY, do follow the If, and follow the SHOULD
and act as if data was deleted
Behavior 3) Don’t follow the MAY, do follow the If, and don’t follow the
SHOULD and hence act in any other way.  In my experience, such
undefined behavior can cause interoperability issues.

Is there any reason to permit behavior 3?   Why can’t you make the SHOULD be
a MUST (since the If already makes it conditional on implementations that
don’t follow the MAY).

6) Section 3.2.5 says:
> If the server has not sent any SleepTime
> value, the peer SHOULD wait for an application-specified minimum time
>  (SleepTimeDefault).

Since the minimum time is app-specified as this sentence says, what does it
mean to not follow this SHOULD?  I.e., why is it not a MUST?

7) Section 3.4.2 says:
> The endpoints MAY send updated Realm, ServerInfo and PeerInfo objects
> in the Reconnect Exchange.  

So if this MAY is not followed, does that mean any updates are not sent at
all, or that they are sent via some other mechanism?

8) Appendix C says:
> They contain
> JSON objects whose structure may be specified separately for each
> application and each type of OOB channel.  

It doesn’t look like you’re specifying an IANA registry to contain field
names.  Given that, how do you get interoperability?   If every app and type
of OOB channel specifies a different structure, how do you do capability
negotiation to agree on which structure definition is being used?  (Since
two specifications might use the same field names for very different purposes,
in theory.)   I didn’t see any identifier that can be used as the “type” of
the ServerInfo or PeerInfo data.


Attacks and mitigations
---

9) Section 3.1 says:
> For example, consider a printer
> (peer) that outputs the OOB message on paper, which is then scanned
> for the server.

Elaborate on this use case… Is the assumption that the printer would
automatically consume paper in response to any unauthenticated message
(hence being a resource consumption attack)?  Or that it would only do so
after getting approval from a human to output the OOB message?

10) Section 6.3 discusses mi

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] eap-noob

[Hannes Tschofenig]

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.

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.

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.

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?

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.

Ciao
Hannes
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] draft-ietf-emu-eap-noob-01: Outdated statement in Initial Exchange description

[Max Crone]

Hi,

I noticed that the current draft version of EAP-NOOB still contains an 
outdated sentence in the description of the Initial Exchange.


3.2.2
The server allocates a new PeerId in the Initial Exchange regardless
of any old PeerId in the username part of the received NAI.

However, the PeerId is not sent as part of the NAI anymore because of 
earlier privacy concerns. I would suggest to change it to the following.


The server allocates a new PeerId in the Initial Exchange regardless
of any old PeerId sent by the peer during the common handshake.

With kind regards,

Max Crone

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

[Emu] I-D Action: draft-ietf-emu-eap-noob-01.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the EAP Method Update WG of the IETF.

Title   : Nimble out-of-band authentication for EAP (EAP-NOOB)
Authors : Tuomas Aura
  Mohit Sethi
Filename: draft-ietf-emu-eap-noob-01.txt
Pages   : 63
Date: 2020-06-01

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.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-emu-eap-noob-01
https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-noob-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-noob-01


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

Re: [Emu] Early allocation request for an EAP Method Type number for draft-ietf-emu-eap-noob

[Mohit Sethi M]

I would add that there is also an early implementation of EAP-TLS-PSK: 
https://github.com/rohitshubham/EAP-TLS-PSK

We had agreed that external PSK authentication for EAP-TLS will use a new 
method type number. The draft for EAP-TLS-PSK 
(https://tools.ietf.org/html/draft-mattsson-emu-eap-tls-psk-00) is still in the 
early stages and will undergo many changes before it can be considered for 
adoption by the working group. However, allocating a method type number for 
EAP-NOOB now would ensure that EAP-TLS-PSK doesn't use the same code point.

--Mohit

On 5/26/20 6:56 AM, Joseph Salowey wrote:
The authors of EAP-NOOB (draft-ietf-emu-eap-noob) have requested early 
allocation of the EAP type code value 56.  If you object to the early code 
point assignment please let the list know why by June 14, 2020.

The criteria for early assignment includes the following:

A.The code points must be from a space designated as "RFC Required", "IETF 
Review", or "Standards Action".  Additionally, requests for early assignment of 
code points from a "Specification Required" registry are allowed if the 
specification will be published as an RFC.

EAP Methods have an allocation policy of Designated Expert, with Specification 
Required.  The specification in this case the draft-ietf-emu-eap-noob.

B.  The format, semantics, processing, and other rules related to handling the 
protocol entities defined by the code points henceforth called 
"specifications") must be adequately described in an Internet-Draft.

The specification draft-ietf-emu-eap-noob-00 contains the protocol specifics.  
There are implementations based on this specification listed below

C. The specifications of these code points must be stable; i.e., if there is a 
change, implementations based on the earlier and later specifications must be 
seamlessly interoperable.

Although the document is a 00 document, the predecessor document 
draft-aura-eap-noob<https://datatracker.ietf.org/doc/draft-aura-eap-noob/> has 
been discussed for over a year.  This call is a request for working group 
members to review the document and object if the specification is not stable.

D. There is sufficient interest in the community for early (pre-RFC) 
implementation and deployment, or that failure to make an early allocation 
might lead to contention for the code point in the field.

Several implementations exist, but it would be good to see if there is 
additional interest in implementing this protocol

The authors note that currently, the following implementations of EAP-NOOB 
exist:

1. Implementation with wpa_supplicant (client) and hostapd (server):
https://github.com/tuomaura/eap-noob

2. Lightweight implementation on Contiki (client only):
https://github.com/eduingles/coap-eap-noob (Tested with server
implementation from #1)

3. Minimal EAP-NOOB (based on #1 with cleaner code and updates to match
current draft version): https://github.com/Vogeltak/eap-noob

Thanks,

Joe



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

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

[Emu] Early allocation request for an EAP Method Type number for draft-ietf-emu-eap-noob

[Joseph Salowey]

The authors of EAP-NOOB (draft-ietf-emu-eap-noob) have requested early
allocation of the EAP type code value 56.  If you object to the early code
point assignment please let the list know why by June 14, 2020.

The criteria for early assignment includes the following:

A.The code points must be from a space designated as "RFC Required",
"IETF Review", or "Standards Action".  Additionally, requests for early
assignment of code points from a "Specification Required" registry are
allowed if the specification will be published as an RFC.

EAP Methods have an allocation policy of Designated Expert, with
Specification Required.  The specification in this case the
draft-ietf-emu-eap-noob.

B.  The format, semantics, processing, and other rules related to handling
the protocol entities defined by the code points henceforth called
"specifications") must be adequately described in an Internet-Draft.

The specification draft-ietf-emu-eap-noob-00 contains the protocol
specifics.  There are implementations based on this specification listed
below

C. The specifications of these code points must be stable; i.e., if there
is a change, implementations based on the earlier and later specifications
must be seamlessly interoperable.

Although the document is a 00 document, the predecessor document
draft-aura-eap-noob <https://datatracker.ietf.org/doc/draft-aura-eap-noob/> has
been discussed for over a year.  This call is a request for working group
members to review the document and object if the specification is not
stable.

D. There is sufficient interest in the community for early (pre-RFC)
implementation and deployment, or that failure to make an early allocation
might lead to contention for the code point in the field.

Several implementations exist, but it would be good to see if there is
additional interest in implementing this protocol

The authors note that currently, the following implementations of EAP-NOOB
exist:

1. Implementation with wpa_supplicant (client) and hostapd (server):
https://github.com/tuomaura/eap-noob

2. Lightweight implementation on Contiki (client only):
https://github.com/eduingles/coap-eap-noob (Tested with server
implementation from #1)

3. Minimal EAP-NOOB (based on #1 with cleaner code and updates to match
current draft version): https://github.com/Vogeltak/eap-noob

Thanks,

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

[Emu] I-D Action: draft-ietf-emu-eap-noob-00.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the EAP Method Update WG of the IETF.

Title   : Nimble out-of-band authentication for EAP (EAP-NOOB)
Authors : Tuomas Aura
  Mohit Sethi
Filename: draft-ietf-emu-eap-noob-00.txt
Pages   : 62
Date: 2020-05-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.  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.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-emu-eap-noob-00
https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-noob-00


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

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

[philipginzboorg]

Hi Tuomas,

We are OK with solving credential provisioning to the peer in EAP level (rather 
than just in EAP-NOOB).
How exactly to do credential provisioning needs further thought. We will be 
happy to discuss this further.


Philip

From: Aura Tuomas [mailto:tuomas.a...@aalto.fi]
Sent: 9 March, 2020 19:57
To: philipginzboorg ; emu@ietf.org
Cc: emu-cha...@ietf.org
Subject: RE: EAP-NOOB: request for optional message pair to configure EAP Peer

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 mailto:emu-boun...@ietf.org>> On Behalf Of 
philipginzboorg
Sent: Friday, 6 March, 2020 15:27
To: emu@ietf.org<mailto: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] 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

[Emu] EAP-NOOB at the IETF 104 hackathon

[Aleksi Peltonen]

Dear all,

My colleagues and I will be working on the EAP-NOOB protocol during the 
hackathon. Feel free to join our table!


Please find the project details below or in the hackathon wiki 
https://trac.ietf.org/trac/ietf/meeting/wiki/104hackathon.


 *
   Champions:
 o Aleksi Peltonen 
 o Eduardo Inglés Sánchez 
 o Tuomas Aura 
 *
   Project:
 o
   EAP-NOOB
 +
   EAP-NOOB is 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.
 o
   Working open source implementation with wpa_supplicant and
   hostapd on github: https://github.com/tuomaura/eap-noob
 o
   During the hackathon we plan to work on the following:
 +
   Various bug fixes
 + Interop testing between implementations
 +
   Testing the code with new kinds of IoT devices and OOB
   channels such as audio
 +
   User experience in real deployment

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