Re: [Emu] [Ace] [core] Proposed charter for ACE (EAP over CoAP?)

[Dan Garcia]

 Hi Michael,


"/1) .../"

For onboarding a new device, where there is no connectivity after 
authentication, you propose to use 802.1X, which is an EAP lower layer. 
EAP over CoAP is in fact a proposal for a application level EAP lower 
layer that overcomes the limitation that 802.1X works on an inferior 
layer, hence, giving the possibility to perform the network 
authentication through nodes.


This idea is not new, in fact, you have PANA, another EAP lower layer 
that works on top of UDP.


As you comment , draft-ietf-6tisch-minimal-security - offers minimal 
security and has several deficiencies that can be solved by using EAP 
and AAA infrastructures.


Regarding your second point

"/2) If it for application authentication, then you need to use EAP to 
setup MSK for later use by a context. We do this in IKEv2, (D)TLS already./"


Our proposal is to define an EAP lower layer that is specifically 
designed for constrained devices and networks. The setup of the MSK for 
later use, is what the EAP KMF does, and  this key material is used to 
run a security association protocol, that could be DTLS or OSCORE.  That 
is why it is not an afterthought as you say. I wrote could, because is 
one of the possibilities. That is another benefit of using EAP.


With respect to do this with IKEv2, EAP already has an EAP method for 
IKE. Why limit the options when EAP gives you more. What will you do if 
the specific network does not support running IKEv2 due to severe 
constrains in the network or any other reason?


That is why I believe the flexibility EAP gives you is worth considering.

Best Regards,
Dan.



On 9/12/20 19:55, Michael Richardson wrote:

Dan Garcia  wrote:
 > EAP can be used in the context of IoT for authentication.

But, to what end?

1) If it is onboarding a new device, then there is no connectivity until after 
authentication.
so you can't use CoAP, you have to use 802.1x, or some equivalent, or
create a system such as draft-ietf-6tisch-minimal-security.
Which does use CoAP and OSCORE already.

2) If it for application authentication, then you need to use EAP to setup
MSK for later use by a context.
We do this in IKEv2, (D)TLS already.

So the only left would be OSCORE, yet you write "could", as if it was an 
afterthought.

Tell me what is your application?  What will be impossible if we don't do
this work?

--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide




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

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

[Éric Vyncke via Datatracker]

Éric Vyncke has entered the following ballot position for
draft-ietf-emu-eap-tls13-13: 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 IESG DISCUSS and COMMENT positions.


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



--
COMMENT:
--

Thank you for the work put into this document. Improving EAP-TLS is indeed
welcome! BTW, I left the security review to the SEC Area Directors.

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

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Abstract --
Should the abstract briefly talk about EAP?

-- Section 1 --
Should "ietf-tls-oldversions-deprecate" be normative ?

-- Section 2 --
Nicely done to have kept the same sub-section numbers with respect to RFC 5216.
Kudos !

-- Section 2.1.1 & 2.1.3 & 2.1.4 --
I find "This section updates Section 2.1.1 of [RFC5216]." a little ambiguous as
it the 'updated section' is not identified clearly. I.e., as the sections in
RFC 5216 are not too long, why not simply providing whole new sections ?

-- Section 5.9 --
What is the added benefit of this section (pervasive monitoring) compared to
section 5.8 (privacy considerations)? Esp when I am afraid that pervasive
monitoring is deeper in the network rather than in the access network (happy to
be corrected)

== NITS ==

None of us are native English speaker, but "e.g." as "i.e." are usually
followed by a comma while "but" has usually no comma before ;-)



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

Re: [Emu] [core] [Ace] Proposed charter for ACE (EAP over CoAP?)

[Mališa Vučinić]

Hi Dan,

 

Could you be more specific on the point below, what deficiencies do you have in 
mind?

 

Mališa 

 

From: core  on behalf of Dan Garcia 
Date: Thursday 10 December 2020 at 10:06
To: Michael Richardson , EMU WG , 
"c...@ietf.org WG (c...@ietf.org)" , "a...@ietf.org" 

Subject: Re: [core] [Ace] Proposed charter for ACE (EAP over CoAP?)

 

As you comment , draft-ietf-6tisch-minimal-security - offers minimal security 
and has several deficiencies that can be solved by using EAP and AAA 
infrastructures. 

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

Re: [Emu] Proposed Resolution for TEAP errata 5768

[Jorge Vergara]

This change looks good to me. Would appreciate a sanity check of another 
implementation by Oleg to make sure I have my facts straight here.

From: Joseph Salowey 
Sent: Sunday, November 22, 2020 9:24 PM
To: Jorge Vergara 
Cc: Oleg Pekar ; EMU WG ; Jouni 
Malinen 
Subject: Re: Proposed Resolution for TEAP errata 5768



On Thu, Nov 19, 2020 at 8:53 PM Jorge Vergara 
mailto:jover...@microsoft.com>> wrote:
Sorry for the last minute comment on this one before the meeting. I would like 
to mark this as a “discuss” - I have some compat concern about making the TLV 
length variable. Current implementations truncate the MAC field at 20 octets. 
Although I agree in spirit with the direction of this change, I think it would 
require changing the version of the Crypto-Binding TLV.

I recognize that most probably won’t have time to review this concern before 
the meeting and so the discussion may not be able to occur there. Apologies 
again as I only realized this concern as I was giving everything a final 
pass-over.


[Joe] Thanks for catching this.  If this is the case then we should have the 
errata resolution reflect what implementations do and leave the rest of the 
change for a document update.

For this I suggest that we leave section 4.2.13 unchanged and make changes to 
5.3.

Section 5.3 Says:

 The Compound MAC computation is as follows:

  CMK = CMK[j]
  Compound-MAC = MAC( CMK, BUFFER )

   where j is the number of the last successfully executed inner EAP
   method, MAC is the MAC function negotiated in TLS 1.2 [RFC5246], and
   BUFFER is created after concatenating these fields in the following
   order:

   1  The entire Crypto-Binding TLV attribute with both the EMSK and MSK
  Compound MAC fields zeroed out.

   2  The EAP Type sent by the other party in the first TEAP message.

It Should say:

 The Compound MAC computation is as follows:

  CMK = CMK[j]
  Compound-MAC = MAC( CMK, BUFFER )

   where j is the number of the last successfully executed inner EAP
   method, MAC is HMAC [RFC2104] using the hash function negotiated in
   TLS [RFC5246].  If the output of the HMAC is greater than 20 bytes then
   it is truncated to 20 bytes.  The BUFFER is created after concatenating
   these fields in the following order:

   1  The entire Crypto-Binding TLV attribute with both the EMSK and MSK
  Compound MAC fields zeroed out.

   2  The EAP Type sent by the other party in the first TEAP message. This
   is a single octet encoded as (0x37)

Jorge Vergara

From: Oleg Pekar mailto:oleg.pekar.2...@gmail.com>>
Sent: Saturday, October 24, 2020 4:30 PM
To: Joseph Salowey mailto:j...@salowey.net>>
Cc: EMU WG mailto:emu@ietf.org>>; Jouni Malinen 
mailto:j...@w1.fi>>; Jorge Vergara 
mailto:jover...@microsoft.com>>
Subject: Re: Proposed Resolution for TEAP errata 5768

> 2  The EAP Type sent by the other party in the first TEAP message. This is a 
> single octet encoded as (0x37)

Shouldn't we clarify the motivation for placing the octet with TEAP type 0x37 
into the BUFFER? Joe, I remember you explained that it is for protection 
against cross protocol attacks if Crypto-Binding TLV was reused (e.g. from 
PEAP).

On Sun, Oct 25, 2020 at 12:45 AM Joseph Salowey 
mailto:j...@salowey.net>> wrote:
Errata 5768:  
https://www.rfc-editor.org/errata/eid5768
Proposed State: Verified
Revision:

Section 4.2.13. Says:

Length

76

It should say:

Length

 36 plus the length of the 2 MAC fields

Section 4.2.13. Says:

   EMSK Compound MAC

  The EMSK Compound MAC field is 20 octets.  This can be the Server
  MAC (B1_MAC) or the Client MAC (B2_MAC).  The computation of the
  MAC is described in Section 5.3.

   MSK Compound MAC

  The MSK Compound MAC field is 20 octets.  This can be the Server
  MAC (B1_MAC) or the Client MAC (B2_MAC).  The computation of the
  MAC is described in Section 5.3.

It Should Say:

   EMSK Compound MAC

  The computation of the MAC is described in Section 5.3.  This can be
  the Server MAC (B1_MAC) or the Client MAC (B2_MAC).

   MSK Compound MAC

  The computation of the MAC is described in Section 5.3.  This can be
  the Server MAC (B1_MAC) or the Client MAC (B2_MAC).

Section 5.3 Says:

 The Compound MAC computation is as follows:

  CMK = CMK[j]
  Compound-MAC = MAC( CMK, BUFFER )

   where j is the number of the last successfully executed inner EAP
   method, MAC is the MAC function negotiated in TLS 1.2 [RFC5246], and
   BUFFER is created after concatenating these fields in the following
   order:

   1  The entir