Re: [Emu] Implementing EAP-NOOB in Contiki - Use of the Realm assigned by the server?
Hi Tuomas, When I had implemented version 03 of the EAP-NOOB draft, I had understood that the new peer device should first be connected to the home network and establish an EAP-NOOB association with its home AAA server before it is able to roam? Except the case where the peer device provides some method for the user to manually configure the Realm of the home network. Thanks, Shiva -Original Message- From: Emu On Behalf Of Aura Tuomas Sent: Wednesday, July 03, 2019 4:24 PM To: Eduardo Inglés UM ; emu@ietf.org Subject: Re: [Emu] Implementing EAP-NOOB in Contiki - Use of the Realm assigned by the server? Yes, the new Realm assigned in the Initial Exchange should be used already during the Waiting Exchange and Completion Exchange. As part of the editorial improvements in draft-06, I edited the specification to be clearer on this point. The reason is better compatibility with roaming implementations, which are not part of the EAP-NOOB protocol but may want to work with it. If the Initial Exchange takes place while roaming, some external mechanism is needed to route the Initial Exchange, where the peer uses the default Realm, from the foreign AAA to the peer's intended home AAA. Since the realm is assigned in the Initial Exchange and taken into use immediately, the AAA routing will work normally for the subsequent Waiting and Completion Exchanges, and the same external mechanism is not needed there. That is, it is easier for foreign network to support Initial Exchange for roaming peer devices. The use case for such roaming support in eduroam was brought forward by Josh Howlett and Rhys Smith. Tuomas -Original Message- From: Emu On Behalf Of Eduardo Inglés UM Sent: Thursday, June 20, 2019 1:20 PM To: emu@ietf.org Subject: [Emu] Implementing EAP-NOOB in Contiki - Use of the Realm assigned by the server? Importance: High Hello all, During the IETF 104 Prague I told you that I am implementing EAP-NOOB in Contiki. During the process I have had few issues that I will send in separate emails for clarifications in the coming weeks. I like the way EAP-NOOB allows the server to send a realm that a peer can use later on during its lifetime. I find it useful when peers are roaming in different networks, for example, in the use case that I sent in a previous email. However, reading the specification it is not clear to me when a device should start using the Realm assigned by the server. Should I use it already during Waiting Exchange? Or only after the device has been successfully authenticated in the Completion Exchange? Regards, Eduardo Inglés. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Questions about EAP-NOOB
Hi Tuomas, See in line. On ke, 2019-03-06 at 12:23 +, Aura Tuomas wrote: > Hi Dan and Rafa, > > Thank you for the questions! > > Yes, the Initial Exchange in EAP-NOOB always ends in EAP-Failure. > Then, we give some time for the user to transfer the OOB message. > After the OOB step, the peer tries again and the Completion Exchange > ends in EAP-Success. > > Yes, the out-of-band (OOB) message is cryptographically bound to the > ECHD result. That, is the message authentication code (Hoob) in the > OOB message takes the ECDH output as one of its inputs. This statement is not completely true. If you look at the Hoob calculation specified in the draft https://tools.ietf.org/html/draft-au ra-eap-noob-05#section-3.3.2: Hoob = H(Dir,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,Cryptos uitep,Dirp,[Realm],PeerInfo,0,PKs,Ns,PKp,Np,Noob). As you can see, the Hoob only confirms the public keys involved in the ECDHE exchange but not actually use the shared secret derived. Thus, it does not use the ECDHE output. However, from my implementation experience, I think this is the correct way to calculate Hoob since it allows applications to externalize the generation of random nonce Noob and the corresponding Hoob. This would allow deployments to choose how often these values are created. For example, some display devices might refersh the QR code containing Noob and Hoob every few minutes. Regards, Shiva > > > Our current implementation opportunistically tries all the W-Fi > network that support WPA2-Enterprise. It definitely would be better > to advertise the capability for EAP-NOOB in IEEE 802.11u, or even > advertise the domain of the EAP-NOOB server. I think it will take > some time before the 802.11 APs start to support EAP-NOOB in that > way, though, and we want the protocol to work with existing Wi-Fi > networks. > > The realm used by the peer is initially “eap-noob.net”. The server > can assign another realm in Initial Exchange. The main purpose for > assigning another realm is that the peer can later use it for roaming > in access networks that have AAA routing set up for the assigned > realm. > > We have only tested EAP-NOOB on Wi-Fi: https://github.com/tuomaura/ea > p-noob. It can be used on any networks that support EAP and where the > user-assisted OOB authentication methods makes sense from the user > experience perspective. > > Regards, > Tuomas > > > From: Emu On Behalf Of Dan Garcia > Sent: Monday, 28 January, 2019 13:39 > To: emu@ietf.org > Subject: [Emu] Questions about EAP-NOOB > Importance: High > > Dear Toumas, Mohit, > > We have been discussing EAP NOOB draft we would like to ask some > questions about it. It is a very interesting approach related to > IoT. > > > In EAP-NOOB as first step the EAP authenticator starts the > authenction (e.g. the AP), eap-noob happens but it seems there will > be a EAP failure , is this correct? > Assuming it is, if you send an EAP failure, will the EAP method still > continue? How would this work? Since we are waiting, we assume, from > an EAP success, or an alternative way of confirmation that the > authentication has been completed. > > It seems that the user gets something from the IoT device this > something is due to the ECDH, right? > > Regarding the discovery of the EAP authenticator. The AP should > announce what are the available domains to where it is connected ( a > solution based on the AAA infraestructure ?) Could this information > be provided to the AP using IEEE 802.11u? > > Related to this, what would be the realm provided by the EAP peer to > the authenticator? > > Another question would be which are the main radio technologies where > EAP NOOB is expected to be used. Are you planning to support > 802.15.4, WIFI, etc? In this line, do you have any EAP-NOOB > implementation in Contiki? > > > > Thank you in advance. > Best Regards. > Dan and Rafa. > > > -- > = > Dan Garcia Carrillo, Ph.D. > Doctorado Industrial (MINECO) > E-mail: dgar...@odins.es > Odin Solutions, S.L. > Polígono Industrial Oeste > C/ Perú, 5, 3º, Oficina 12 > 30820 - Alcantarilla (Murcia) - Spain > Tlf.: +34 902 570 121 > Web: www.odins.es > = > > AVISO LEGAL: La información contenida en este correo electrónico, y > en su caso en los documentos adjuntos, es información privilegiada > para uso exclusivo de la persona y/o personas a las que va dirigido. > No está permitido el acceso a este mensaje a cualquier otra persona > distinta a los indicados. Si usted no es uno de los destinatarios, > cualquier duplicación, reproducción, distribución, así como cualquier > uso de la información contenida en él o cualquiera otra acción u > omisión tomada en relación con el mismo, está prohibida y puede ser > ilegal. En dicho caso, por favor notifíquelo al remitente y proceda a > la eliminación
Re: [Emu] FW: New Version Notification for draft-aura-eap-noob-04.txt
Hi EMU, In my previous job, I was one of the team members implementing EAP- NOOB. I have now changed employers and work on something completely different (Platform Security). I am following this draft out of personal interest. I appreciate the fact that the authors have taken the time to formally verify the protocol. A paper from as recent as CCS 2018 (October): http s://papers.mathyvanhoef.com/ccs2018.pdf, shows new attacks in the Wi-Fi 4-way handshake protocol and recommends formally modelling 802.11. I would however strongly recommend the authors of this document, and others, to encrypt as many EAP messages as possible. For example, error messages sent in EAP-NOOB are still in plain. Since these messages usually cause one or the other side to change states, they should be protected. 802.11, TLS and other protocols have been taking a similar approach of encrypting as much as possible. As an example, 802.11 now uses protected management frames. Regards Shiva On ke, 2018-10-24 at 17:47 +, Aura Tuomas wrote: > Dear all, > > We have submitted a new version of our draft titled “Nimble out-of- > band authentication for EAP (EAP-NOOB)”: > > https://tools.ietf.org/html/draft-aura-eap-noob-04 > > The draft defines an EAP method where the authentication is based on > a user-assisted out-of-band (OOB) channel between the server and > peer. It is intended as a generic bootstrapping solution for > Internet-of-Things devices which have no pre-configured > authentication credentials and which are not yet registered on the > authentication server. > > What is new in version -04? Since the previous version, we have done > extensive modeling and verification of the protocol and worked to > resolve some discovered issues. We especially looked for denial-of- > service conditions that may arise from dropped messages and other > protocol failures, which both could be caused a network attacker. > Based on this analysis, we have rethought the recovery from dropped > final messages. The error handling still needs some attention. In any > case, the specification is a pretty good shape and ready for anyone > to review. > > The open-source implementation and the mCRL2 formal model are still > based on the previous version but work is ongoing to update them: > https://github.com/tuomaura/eap-noob > > Emu is the working group that closest matches our spec. Thus, we look > forward to your feedback and comments here or in the wg meeting in a > couple of weeks. > > Regards, > Tuomas > > > > -Original Message- > From: internet-dra...@ietf.org > Sent: Monday, 22 October, 2018 20:50 > To: Mohit Sethi ; Aura Tuomas > Subject: New Version Notification for draft-aura-eap-noob-04.txt > > > A new version of I-D, draft-aura-eap-noob-04.txt has been > successfully submitted by Tuomas Aura and posted to the IETF > repository. > > Name: draft-aura-eap-noob > Revision: 04 > Title: Nimble out-of-band authentication for EAP (EAP-NOOB) > Document date: 2018-10-22 > Group: Individual Submission > Pages: 58 > URL: https://www.ietf.org/internet-drafts/draft-aura-eap-n > oob-04.txt > Status: https://datatracker.ietf.org/doc/draft-aura-eap-noob/ > Htmlized: https://tools.ietf.org/html/draft-aura-eap-noob-04 > Htmlized: https://datatracker.ietf.org/doc/html/draft-aura-eap- > noob > Diff: https://www.ietf.org/rfcdiff?url2=draft-aura-eap-noob > -04 > > Abstract: > Extensible Authentication Protocol (EAP) provides support for > multiple authentication methods. This document defines the EAP- > NOOB > authentication method for nimble out-of-band (OOB) authentication > and > key derivation. This EAP method is intended for bootstrapping all > kinds of Internet-of-Things (IoT) devices that have a minimal user > interface and no pre-configured authentication credentials. The > method makes use of a user-assisted one-directional OOB channel > between the peer device and authentication server. > > > > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > The IETF Secretariat > > ___ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
