Re: [Emu] Questions about EAP-NOOB

[Shiva Prasad Thagadur Prakash]

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,

Re: [Emu] Questions about EAP-NOOB

[Aura Tuomas]

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

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

Tuomas


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

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

Eliot

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

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

Re: [Emu] Questions about EAP-NOOB

[Eliot Lear]

Hi Aura,

Just on this one point:

> On 6 Mar 2019, at 13:23, Aura Tuomas  wrote:
> 
> 
> The realm used by the peer is initially “eap-noob.net 
> ”. The server can assign another realm in Initial 
> Exchange. The main purpose for assigning another realm is that the peer can 
> later use it for roaming in access networks that have AAA routing set up for 
> the assigned realm.
> 

Since this is going to be somewhat common between new mechanisms as a routing 
function (and it’s a very good idea!), it makes sense for the realm to be 
properly registered as a protocol parameter.  A few of us had a discussion 
about this.  The suggestion was made that this should fall under the .ARPA 
domain, so that it is properly reserved.  I propose that we discuss this a bit 
in Prague.  (FWIW, I didn’t come up with the .ARPA idea, but I like it).

Eliot



signature.asc
Description: Message signed with OpenPGP
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Questions about EAP-NOOB

[Eliot Lear]

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

Eliot

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



signature.asc
Description: Message signed with OpenPGP
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Questions about EAP-NOOB

[Alan DeKok]

On Mar 6, 2019, at 7:23 AM, Aura Tuomas  wrote:
> The realm used by the peer is initially “eap-noob.net”. The server can assign 
> another realm in Initial Exchange. The main purpose for assigning another 
> realm is that the peer can later use it for roaming in access networks that 
> have AAA routing set up for the assigned realm. 

  This is fine for an initial draft.  I'd avoid implementing anything that uses 
"eap-noob.net", though.

  The correct domain to use is .arpa:

   https://www.iana.org/domains/arpa

  The controlling document here is RFC 3172.

  It looks like EAP-TEAP-BRSKI requires a similar NAI for provisioning.  So it 
would best best to coordinate both the name, and the use of it.  Perhaps 
"provisioning.arpa" could be used as a generic name, and then subdomains within 
that could be used for particular purposes.

  Alan DeKok.

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

Re: [Emu] Questions about EAP-NOOB

[Aura Tuomas]

Hi Dan and Rafa,

Thank you for the questions!

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

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

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

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

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

Regards,
Tuomas


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

Dear Toumas, Mohit,

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


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

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

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

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

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



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


--
=

Dan Garcia Carrillo, Ph.D.
Doctorado Industrial (MINECO)
E-mail: dgar...@odins.es<mailto: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<http://www.odins.es>
=

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

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

Re: [Emu] Questions about EAP-NOOB draft

[Eduardo Inglés UM]

Hi Tuomas,

Thanks for taking the time to respond.

In the first question I was wondering if there was any debate about the 
inclusion of other algorithms. Especially in terms of interoperability 
with, for example, TLS. You're right that low-end devices can do ECDHE. 
Therefore, it would not make sense to decrease the level of security. In 
addition, I have seen that the new version TLS 1.3 includes a derivation 
function with HKDF [RFC5869], which is could be compatible with ECDH.


Regarding the problem of the proposed scenario, it is a very interesting 
solution. A good option to take into account.


Best regards.


El 30/01/2019 a las 11:35, Aura Tuomas escribió:

Hi Eduardo,

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

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

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

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

Regards,
Tuomas



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

Dear Tuomas,

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

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

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

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

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


Regards,
Eduardo Inglés.

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


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

Re: [Emu] Questions about EAP-NOOB draft

[Aura Tuomas]

Hi Eduardo,

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

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

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

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

Regards,
Tuomas



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

Dear Tuomas,

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

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

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

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

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


Regards,
Eduardo Inglés.

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

[Emu] Questions about EAP-NOOB

[Dan Garcia]

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.

--
Firma Correo 
=


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

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

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


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


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

[Emu] Questions about EAP-NOOB draft

[Eduardo Inglés UM]

Dear Tuomas,

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


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


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


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


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



Regards,
Eduardo Inglés.

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