Subject: Re: [Emu] New Version Notification for draft-ietf-ace-wg-coap-eap-04.txt

From: Dan Garcia Carrillo <[email-masked]>
Date: Thu, 2 Dec 2021 10:53:46 +0100

Dear John,

Thank you for taking the time to review the document. I think with this 
the next version would be much more accurate.

Please find responses to your comments inline.

Best Regards,

CoAP-EAP authors.

On 25/10/21 17:02, John Mattsson wrote:
>
> Thanks,
>
> I think this is a very useful mechanism and a well written draft. Some 
> quick comments.
>
> - "ciphersuite"
>
> Note that both TLS and EDHOC spells this with space "cipher suite"
>
  [authors] We will change the wording, thank you

> - Section 2. I don't understand what "SM" in Figure 1 is an 
> abbrevation for.
>
  [authors] SM stands for State Machine, we will explain that in the 
text, thank you for pointing that out.
>
> - Section 2. "UDP/TCP/Websockets" Why is the Websocket protocol in plural?
>
  [authors] Probably a typo, thanks
>
> - Section 3. "EAP method that exports cryptographic material"
>
> This can probably be reformulated in terms of MSK, EMSK or "Key 
> derivation" which
>
> is the property that RFC 3748 uses.
>
  [authors] We will rephrase using key derivation.
>
> - "EAP-MD5 cannot be used since it does not export key material"
>
> MD5 should really not be used at all for security resons. Highlighting 
> it like this might
>
> be the idea that it would be ok if EAP-MD5 had the "Key derivation" 
> property.
>
[authors] That’s correct. Most probably is better to just mentioned that 
any EAP method that does not export key material MUST NOT be used. It is 
worth mentioning that the goal of this statement was, as the document 
defines an EAP lower layer, not so much as trying to make 
recommendations on which EAP methods are secure or should be considered 
deprecated. We just intend to provide information on which EAP methods 
are suitable for its use with this particular EAP lower layer.

> - "The required key, the Master Session Key (MSK), will be available 
> once the
>
> EAP authentication is successful."
>
>    Does this belong in step 2?
>
[authors] It is a clarification to highlight that the MSK is used to 
derive key material for the OSCORE context. We can remove it if it 
clarifies the paragraph or even to point to step 7.
>
> - In Figure 2. I do not think you have to wait until EAP-SUCCES to 
> make MSK available.
>
> The authentication can be successful before EAP-SUCCES.
>
[authors] This is an interesting comment that we already commented on 
EMU WG, though we do not receive any comment. In fact, we tend to agree 
with you. All the details are in this e-mail we sent:

https://mailarchive.ietf.org/arch/msg/emu/bnMFV4_1uTW7sSwVOp7WzVZZCAI/

In summary, the EAP peer state machine does not inform the EAP lower 
layer that the key is available in eapKeyData until it is in SUCCESS 
state. In this final state, the eapKeyAvailable is set to TRUE.

In any case, everything is now solved because the arrival of 
OSCORE-protected CoAP message is considered as an alternate success 
indication.

> - In section 3.3. it might be good to state that "Reauthentication" 
> might be needed to rekey MSK/EMSK and to increase protection against 
> key leakage.
>
> (An important mitigation of pervasive monitoring is to force attackers 
> to do dynamic key exfiltration instead of static key exfiltration. 
> Dynamic key exfiltration increases the risk of discovery for the 
> attacker [RFC7624]. While OSCORE will soon be augmented with a 
> rekeying mechanism with forward secrecy, attackers can still get away 
> with doing static key exfiltration. This is similar to TLS 1.3 with 
> KeyUpdate, after leakage of application_traffic_secret_N, a passive 
> attacker can passively eavesdrop on all future application data sent 
> on the connection including application data encrypted with 
> application_traffic_secret_N+1, application_traffic_secret_N+2, etc.)
>

[authors] Yes, sure. We will add this comment to the text. In fact that 
is the intention to the reauthentication: to refresh the MSK/EMSK. In 
fact, the EAP Key Management Framework establishes a default value of 8 
hours to refresh the MSK/EMSK. Therefore that would be the default value 
each time the OSCORE key material is refreshed.

> - "4.  The values from 65000 to 65535 are reserved for experimentation"
>
> what does "The values" refer to? Lifetime? In that case it would fit 
> better under 3.
>
[authors] Thank you for pointing that out. The CBOR structure is 
intended to be extensible. We have the values for what is currently 
expected in the protocol, but we want to keep the structure open for 
future additions if they are needed.

The values from 65000 to 65535are referring to  the index of the values 
that are not yet assigned, for extensibility. Those indexes are reserved 
for experimentation.

> - In addition to AES-CCM-16-64-128, only ciphersuites only cipher 
> suites with AES-GCM is included. My feeling was that most IoT people 
> are more interested in ChaCha20-Poly1305 than AES-GCM. I don't have a 
> strong personal opinion.
>
> - "which is considered fresh key material"
>
> “considered fresh”? Maybe "uniformally random"?
>
[authors] Basically, the EAP Key Management Framework uses that specific 
terminology (RFC 5274- 5.7 
<https://datatracker.ietf.org/doc/html/rfc5247#section-5.7>.  Key 
Freshness”). That is why we used this term.  “While preserving algorithm 
independence, session keys MUST be strong and fresh.  Each session 
deserves an independent session key.”
>
> - With normal use of DTLS, Appendix A violates “The CoAP-EAP operation 
> is intended to be compatible with the use of intermediary entities 
> between the IoT device and the Controller”. This limitation should be 
> clearly stated.
>

[authors] We agree. that this consideration applies. We will add that to 
the DTLS annex.

> - Probably good if the labels have “CoAP-EAP” in all the labels to 
> guarantee that they do not collide with anything else.
>

[authors] Thank you for this point. We will apply this change when using 
labels for key derivation to avoid confusion.

> Cheers,
>
> John
>
> *From: *Emu <[email-masked]> on behalf of Dan Garcia Carrillo 
> <[email-masked]>
> *Date: *Monday, 25 October 2021 at 13:27
> *To: [email-masked] <[email-masked]>, EMU WG <[email-masked]>
> *Subject: *Re: [Emu] New Version Notification for 
> draft-ietf-ace-wg-coap-eap-04.txt
>
> Dear ACE and EMU WG,
>
> We have submitted a new version of the draft (draft-ietf-ace-wg-coap-eap)
>
> This version provides information on the different comments, from the
> reviews and interim meetings.
>
> Best Regards.
>
>
> El 10/25/2021 a las 1:23 PM, [email-masked] escribió:
> > A new version of I-D, draft-ietf-ace-wg-coap-eap-04.txt
> > has been successfully submitted by Dan Garcia-Carrillo and posted to the
> > IETF repository.
> >
> > Name:         draft-ietf-ace-wg-coap-eap
> > Revision:     04
> > Title:                EAP-based Authentication Service for CoAP
> > Document date:        2021-10-25
> > Group:                ace
> > Pages:                29
> > URL: https://www.ietf.org/archive/id/draft-ietf-ace-wg-coap-eap-04.txt
> > Status: https://datatracker.ietf.org/doc/draft-ietf-ace-wg-coap-eap/
> > Htmlized: 
> https://datatracker.ietf.org/doc/html/draft-ietf-ace-wg-coap-eap
> > Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-wg-coap-eap-04
> >
> > Abstract:
> >     This document specifies an authentication service that uses the
> >     Extensible Authentication Protocol (EAP) transported employing
> >     Constrained Application Protocol (CoAP) messages. As such, it
> >     defines an EAP lower layer based on CoAP called CoAP-EAP.  One 
> of the
> >     primer goals is to authenticate a CoAP-enabled IoT device (EAP peer)
> >     that intends to join a security domain managed by a Controller (EAP
> >     authenticator).  Secondly, it allows deriving key material to 
> protect
> >     CoAP messages exchanged between them based on Object Security for
> >     Constrained RESTful Environments (OSCORE), enabling the 
> establishment
> >     of a security association between them.
> >
> >
> >
> >
> > The IETF Secretariat
> >
> >
>
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu
>

---

From: Dan Garcia Carrillo <[email-masked]>
Date: Thu, 2 Dec 2021 12:29:13 +0100

Dear Göran,

Thank you for taking the time to review the document. We found your 
comments very helpful to improve the text.

Please find the responses to your comments inline.

Best Regards,

CoAP-EAP authors.

On 25/11/21 10:09, Göran Selander wrote:
>
> Hello authors of draft-ietf-ace-wg-coap-eap,
>
> Thanks for working with this draft. Here is a mix of nits/editorials 
> and more substantial comments in the order as they appear in the draft.
>
> Abstract
>
> OLD
>
> One of the primer goals is to
>
> NEW
>
> One of the main goals is to
>
  [authors] Fixed.
>
> Section 1.
>
> "EAP methods transported in CoAP MUST generate cryptographic material
>
>    [RFC5247] for this specification. "
>
> The term “cryptographic material” is used multiple times in this 
> document but is not defined. RFC 5247 uses “keying material”, does 
> that match the intended meaning?
>
  [authors] Yes, we agree on this.  We will use “keying material” instead.
>
> Section2.
>
> Figure 1 is perhaps too informative containing endpoints, stacks, what 
> is CoAP, and scope of this document. There is no line/arrow between 
> IoT Device and Controller, presumably because there is too much other 
> information. Section 2 don’t talk about the stack at all.
>
> * Proposal: Make two figures: one with nodes and lines/arrows 
> (“architecture”); another with the stack, which is essentially the 
> same in the two nodes in scope of this document.
>
  [authors] This is a very good point. Thank you for the suggestion. We 
will do that for the next version.

> *  It is confusing that CoAP role allocation is shown in the figure 
> since those only apply to one step of the operation in section 3.2. In 
> all other steps the roles are reversed. Proposal: omit the CoAP roles 
> in the figure, and/or provide an explanation in section text or 
> caption. The section text talking about CoAP client also needs to be 
> modified accordingly.
>
  [authors] This could indeed improve the text, we will simplify this in 
the figure and explain it in the text. In fact, Fig. 2 does not show the 
CoAP role.
>
> * Nit: RFC8323 calls the layer between request/response and reliable 
> transport “message framing”. Perhaps you want to have a common layer 
> renaming the "Messages" layer with “Message /framing/”.
>
   [authors] Yes, that’s right. We will apply this change..

> Section 3.
>
> "It is RECOMMENDED a light EAP method for the case of constrained link 
> and constrained IoT devices."
>
> If this will remain a normative recommendation, then there needs to be 
> a definition (reference) of "light EAP method". Perhaps consider just 
> explain the intention of "light" ("lightweight"?) and remove the 
> normative recommendation?
>
  [authors] Yes, your suggestion makes sense. We will apply it.
>
> ---
>
> OLD
>
> The article [eap-framework], highlights the benefits of the EAP
>
>    framework.
>
> NEW
>
> The benefits of the EAP framework are highlighted in [eap-framework].
>

[authors] Thank you. We will rephrase it that way.

> 3.1
>
> "resource directory"
>
> Provide a reference or at least as an example, like 
> draft-ietf-core-resource-directory,
>
> ---
>
> OLD
>
> Example of this protocols
>
> NEW
>
> Example of such protocols
>
  [authors] Thank you. We will rephrase it that way.
>
> 3.2
>
> Step 0
>
> "The message also includes an URI in the payload of the message to 
> indicate to what resource (e.g. '/a/x') the Controller MUST send the 
> first message with the EAP authentication"
>
> The DoS issues with requiring the Controller to send a message to an 
> unknown URI need to be considered.
>
  [authors] Yes, we will add this to the security considerations section
>
> Step 1
>
> "the Sender ID for OSCORE selected by the Controller"
>
> Is this the Sender ID *of the IoT device* selected by the Controller? 
> In other words, is it the Recipient ID of the Controller selected by 
> the Controller? That would correspond to how OSCORE identifiers are 
> chosen in EDHOC:
>
> https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-12#section-3.3.2
>
> Best not to use the terms "SID" or "RID" unqualified in message fields 
> since they are reversed on the IoT device and Controller. Better use 
> terminology like e.g. RID-I and RID-C for RID of IoT device and 
> Controller, respectively.
>
  [authors] Yes, we understand this might be confusing and we agree with 
you that using RID-I and RID-C is the right way of expressing it to 
avoid this confusion.
>
> Step 2
>
> "the EAP response, the Recipient ID and the selected ciphersuite for 
> OSCORE are in the payload."
>
> Is this the Recipient ID *of the IoT device*? See comment above.
>
  [authors] We believe that with your suggestion this ambiguity will 
disappear.

> ---
>
> OLD
>
> In this step, the IoT device MAY create a OSCORE security context with 
> the Sender ID and Recipient ID.
>
> NEW
>
> In this step, the IoT device MAY create a OSCORE security context with 
> its Sender ID and Recipient ID.
>
[authors] Thank you. We will rephrase it that way.
>
> Step 7
>
> OLD
>
> The reception of the POST message protected with OSCORE using the 
> Sender ID sent in Step 1 is considered by the IoT device as an 
> alternate indication of success ([RFC3748]).
>
> The unqualified "Sender ID" is confusing here. Why does the ID sent in 
> step 1 indicate success to the IoT device? I would expect the ID 
> selected by the IoT device itself and sent in step 2, if used by the 
> Controller to derive the OSCORE security context to protect the 
> message in step 7 would be a stronger indication of success. Proposal 
> (check if this is correct):
>
> NEW
>
> The reception of the POST message protected with an OSCORE security 
> context derived using the Recipient ID of the IoT device sent in Step 
> 2 is considered by the IoT device as an alternate indication of 
> success ([RFC3748]).
>
[authors] Yes, it is correct.  Having qualified the names, the message 
that is sent in the EAP success, would be using the Sender ID of the 
Controller -- Recipient-ID of the IoT device.

> ---
>
> "The communication with the last resource (e.g. '/a/w') from this 
> point MUST be protected with OSCORE except during a new 
> (re)authentication (see Section 3.3)."
>
> I don't understand why there is an exception. OSCORE seems to be 
> applied to communication with the last resource in all cases:
>
> * In the case of new authentication the procedure explained in Section 
> 3.2 applies protection with OSCORE in communication with the last 
> resource.
>
> * In the case of re-authentication, the procedure is explained in 
> Section 3.3 to be "exactly the same" as in Section 3.2.
>
[authors] Yes, we agree. We can remove that part from the sentence to 
avoid any confusion. Nevertheless, after your comment, it would be worth 
stating that if the access to any other resource requires OSCORE 
protection can use the generated OSCORE context. Does it sound reasonable?
>
> Also I find the expression "new (re)authentication" confusing - what 
> is the the difference between "re-authentication" and "new 
> re-authentication"?
>
[authors] Yes, just saying re-authentication is enough. In any case, 
that sentence will be removed as per your suggestion above.

> Section 4.
>
> "  1.  SID: It contains the Identifier for the Sender ID to be used in
>
>        the OSCORE security context.
>
>    2.  RID: It contains the Identifier for the Recipient to be used in
>
>        the OSCORE security context."
>
> Same comment as above to qualify SID and RID: is SID the Sender ID of 
> the IoT device or of the Controller?
>
  [authors] Solved now using qualifies RID-I and RID-C.
>
> Section 5.1
>
> "If the Controller sends a restricted list
>
>    of ciphersuites that is willing to accept, and the ones supported by
>
>    the IoT device are not in that list, the IoT device will respond with
>
>    a '4.00 Bad Request', expressing in the payload the ciphersuites
>
>    supported. "
>
> Make clear (here or in a security consideration) that in case of an 
> error message containing a cipher suite, the exchange of cipher suites 
> between EAP authenticator and EAP peer cannot be verified. For 
> example, a man-in-the-middle could replace cipher suites in either 
> message which would not be noticed if the protocol is ended after step 2.
>
[authors] That’s right. However, after your comments, we believe this 
could be improved. The reason is that by default we can assume that at 
least cipher suite 0. AES-CCM-16-64-128, SHA-256 is implemented in both 
entities. As such, if the controller includes option 0 in the list of 
cipher suites, the controller will not receive a bad request since at 
least the IoT device can select cipher suite 0 and therefore the 
authentication will follow until the end cipher suite negotiation can be 
verified.  We think it is simpler and we can get rid of a bad request. 
Does it sound reasonable?

> Best regards
>
> Göran
>
> *From: *Ace <[email-masked]> on behalf of John Mattsson 
> <john.mattsson=[email-masked]>
> *Date: *Monday, 25 October 2021 at 17:03
> *To: *Dan Garcia Carrillo <[email-masked]>, [email-masked] 
> <[email-masked]>, EMU WG <[email-masked]>
> *Subject: *Re: [Ace] [Emu] New Version Notification for

---

From: Göran Selander <[email-masked]>
Date: Mon, 6 Dec 2021 11:13:31 +0000

Hi Dan,

Please find my replies to your two questions about the update inline below.

Best regards
Göran

From: Dan Garcia Carrillo <[email-masked]>

"The communication with the last resource (e.g. '/a/w') from this point MUST be protected with OSCORE except during a new (re)authentication (see Section 3.3)."

I don't understand why there is an exception. OSCORE seems to be applied to communication with the last resource in all cases:

* In the case of new authentication the procedure explained in Section 3.2 applies protection with OSCORE in communication with the last resource.
* In the case of re-authentication, the procedure is explained in Section 3.3 to be "exactly the same" as in Section 3.2.
[authors] Yes, we agree. We can remove that part from the sentence to avoid any confusion. Nevertheless, after your comment, it would be worth stating that if the access to any other resource requires OSCORE protection can use the generated OSCORE context. Does it sound reasonable?

[GS] Yes, the established security context can be used between other resources if allowed by the application's security policy. Proposed rephrasing of step 8:

OLD

     "The IoT Device answers with '2.04 Changed' if the EAP

      authentication is a success and the verification of the "POST"

      protected with OSCORE in Step 7 is correctly verified.  The

      communication with the last resource (e.g. '/a/w') from this point

      MUST be protected with OSCORE.  Any other resource that requires

      OSCORE protection MAY be protected with this OSCORE security

      context."

NEW

     "If the EAP authentication and the verification of the OSCORE protected "POST" in Step 7 is successful, then the IoT Device answers with an OSCORE protected '2.04 Changed'. From this point on, the communication with the last resource (e.g. '/a/w')

MUST be protected with OSCORE. If allowed by application policy, same OSCORE security context MAY be use to protect communication to other resources between the same endpoints."

----

Another editorial comment refering to the recent update:

OLD
     "The reception of the POST
      message protected with OSCORE with Sender ID equal to RID-I
      (Recipient ID of the IoT device) sent in Step 2 is considered by
      the IoT device as an alternate indication of success ([RFC3748<https://datatracker.ietf.org/doc/html/rfc3748>])."

I would avoid the term Sender ID since it is all about verification of a received message, e.g. like this.

NEW

     "The verification of the received OSCORE protected "POST"

    message using RID-I (Recipient ID of the IoT device) sent in Step 2 is considered by

      the IoT device as an alternate indication of success ([RFC3748<https://datatracker.ietf.org/doc/html/rfc3748>])."

----

Section 5.1

Make clear (here or in a security consideration) that in case of an error message containing a cipher suite, the exchange of cipher suites between EAP authenticator and EAP peer cannot be verified. For example, a man-in-the-middle could replace cipher suites in either message which would not be noticed if the protocol is ended after step 2.

[authors] That’s right. However, after your comments, we believe this could be improved. The reason is that by default we can assume that at least cipher suite 0. AES-CCM-16-64-128, SHA-256 is implemented in both entities. As such, if the controller includes option 0 in the list of cipher suites, the controller will not receive a bad request since at least the IoT device can select cipher suite 0 and therefore the authentication will follow until the end cipher suite negotiation can be verified.  We think it is simpler and we can get rid of a bad request. Does it sound reasonable?

[GS] Sounds OK to me.

---

From: Dan Garcia Carrillo <[email-masked]>
Date: Tue, 7 Dec 2021 23:10:54 +0100

Hi Göran,

Thank you again for your comments.

We have incorporated them into the a new 06 version of the draft that we 
just submitted.

Best Regards,
Dan.

On 6/12/21 12:13, Göran Selander wrote:
> *From: *Dan Garcia Carrillo <[email-masked]>
>
>     * In the case of new authentication the procedure explained in
>     Section 3.2 applies protection with OSCORE in communication with
>     the last resource.
>
> avoid any confusion. Nevertheless, after your comment, it would be 
> worth stating that if the access to any other resource requires OSCORE 
> [GS] Yes, the established security context can be used between other 
> resources if allowed by the application's security policy. Proposed 
> rephrasing of step 8:
>
> OLD
>
>   "If the EAPauthentication and the verification of the OSCORE 
> protected "POST"in Step 7 is successful, thenthe IoT Device answers 
> with an OSCORE protected '2.04 Changed'. From this point on, the 
> communication with the last resource (e.g. '/a/w')
> MUST be protected with OSCORE. If allowed by application policy, 
> sameOSCORE securitycontextMAY be use to protect communication toother 
> resources between the same endpoints."
>
> ----
>
>       the IoT device as an alternate indication of success ([RFC3748 
> <https://datatracker.ietf.org/doc/html/rfc3748>])."
>
>      "The verification of the received OSCORE protected"POST"
> messageusing RID-I(Recipient ID of the IoT device) sent in Step 2 is 
> considered by
>       the IoT device as an alternate indication of success ([RFC3748 
> <https://datatracker.ietf.org/doc/html/rfc3748>])."
>
> ----
>
>     Section 5.1
>
>     Make clear (here or in a security consideration) that in case of
>     an error message containing a cipher suite, the exchange of cipher
>     suites between EAP authenticator and EAP peer cannot be verified.
>     For example, a man-in-the-middle could replace cipher suites in
>     either message which would not be noticed if the protocol is ended
>     after step 2.
>
> least cipher suite 0. AES-CCM-16-64-128, SHA-256 is implemented in 
> both entities. As such, if the controller includes option 0 in the 
> list of cipher suites, the controller will not receive a bad request 
> since at least the IoT device can select cipher suite 0 and therefore 
> the authentication will follow until the end cipher suite negotiation 
> can be verified.  We think it is simpler and we can get rid of a bad 
> request. Does it sound reasonable?
>
> [GS] Sounds OK to me.
>

---

From: Daniel Migault <[email-masked]>
Date: Wed, 8 Dec 2021 10:39:05 -0500

Thanks Dan. It seems we are reaching the point where we can move
the document forward.

Until now in this group, chairs have usually been writing the document
shepherd, but I am wondering if anyone in the WG would be interested in
writing such a document. The reason we are proposing this is to increase
the number of people familiar with WG chairs tasks, and provide more
opportunities for people to show some interest in positions such as chairs,
secretaries, ads...

If anyone is interested in writing the document shepherd please let us know
by the end of the week. Similarly, anyone interested in a chair position,
please let us know so we can make our ADs aware of it.

Yours,
Logan and Daniel

On Tue, Dec 7, 2021 at 5:11 PM Dan Garcia Carrillo <[email-masked]>
wrote:

> *From: *Dan Garcia Carrillo <[email-masked]> <[email-masked]>
>
>
> "The communication with the last resource (e.g. '/a/w') from this point
> MUST be protected with OSCORE except during a new (re)authentication (see
> Section 3.3)."
>
>
>
> I don't understand why there is an exception. OSCORE seems to be applied
> to communication with the last resource in all cases:
>
>
>
> * In the case of new authentication the procedure explained in Section 3.2
> applies protection with OSCORE in communication with the last resource.
>
> * In the case of re-authentication, the procedure is explained in Section
> 3.3 to be "exactly the same" as in Section 3.2.
>
> stating that if the access to any other resource requires OSCORE protection
> can use the generated OSCORE context. Does it sound reasonable?
>
>
>
>       the IoT device as an alternate indication of success ([RFC3748 <https://datatracker.ietf.org/doc/html/rfc3748>])."
>
>
>
>
>
>
>
> ----
>
>
>
> Section 5.1
>
>
>
> Make clear (here or in a security consideration) that in case of an error
> message containing a cipher suite, the exchange of cipher suites between
> EAP authenticator and EAP peer cannot be verified. For example, a
> man-in-the-middle could replace cipher suites in either message which would
> not be noticed if the protocol is ended after step 2.
>
>
>
> cipher suites, the controller will not receive a bad request since at least
> the IoT device can select cipher suite 0 and therefore the authentication
> will follow until the end cipher suite negotiation can be verified.  We
> think it is simpler and we can get rid of a bad request. Does it sound
> reasonable?
>
> [GS] Sounds OK to me.
>
>
>
>
>
>
>
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace
>

-- 
Daniel Migault
Ericsson