Re: [Emu] TEAP - RFC 7170 - Errata ID 5768

[Joseph Salowey]

On Fri, May 22, 2020 at 1:18 PM Jorge Vergara  wrote:

> My review of this errata and the current responses from Oleg:
>
>
>
>1. I agree with this proposed resolution. I do think this is an
>important omission that needs to be clarified in the RFC. Otherwise it is
>somewhat guesswork that truncation is the right action. I think the current
>wording leans toward truncation, but I definitely asked this question
>myself while implementing.
>
> [Joe]  Why not just change the TLV to be variable length?  It seems if we
hardcode the length to 100 we risk having the same problem in the future?


>
>1.
>2. This bleeds into Alan’s TLS 1.3 document somewhat, but I agree with
>Jouni that this will need to change when the rest of the document is
>eventually updated to TLS 1.3. There are enough TLS 1.3 related things to
>address in TEAP that I don’t exactly view this as an errata. I view it as a
>needed update, whether in this document, Alan’s document, or both.
>
> [Joe]  I tend to agree that this is not an errata.  However an update to
TEAP should address these.


>
>1.
>2. Agree with Jouni that I don’t see the point of the 0x37 octet, but
>regardless this clarification of how it is encoded is positive (minor)
>change.
>
> [Joe] I think the original reason to include the TEAP method ID in the
specification was to make sure that we differentiated between similar
crypto binding implementations in other protocols such as EAP-FAST.   I
don't think there is much ambiguity here, but I am OK with including 0x37
in the description.


>
>
> Thanks,
>
> Jorge
>
>
>
> *From:* Emu  *On Behalf Of * Oleg Pekar
> *Sent:* Tuesday, May 5, 2020 6:27 AM
> *To:* Jouni Malinen ; EMU WG 
> *Subject:* [Emu] TEAP - RFC 7170 - Errata ID 5768
>
>
>
> Hi Jouni,
>
> I propose the following fix for the issues described in this errata id:
>
> 1) In Section "4.2.13.  Crypto-Binding TLV" make "EMSK Compound MAC" and
> "MSK Compound MAC" fields 32 octets long (currently 20 octets). The MAC
> value is truncated at 32 octets if it is longer than 32 octets or padded to
> a length of 32 octets with zeros to the right if it is less than 32 octets.
> The length of the TLV should be changed to 100 bytes (currently 76).
>
>
>
> The motivation is to keep collision-resistance strength of MAC on 128 bit..
> Hash value truncation is described in "NIST Special Publication 800-107
> Revision 1: Recommendation for Applications Using Approved Hash Algorithms"
> 
>
>
>
>
> 2) In Section "5.3.  Computing the Compound MAC" specify that "MAC is the
> MAC function negotiated in TLS of TEAP Phase 1" (currently it says TLS
> 1.2)
>
>
>
> The motivation is to support TLS 1.2, 1.3 and possibly later TLS versions..
>
>
>
> 3) In Section "5.3.  Computing the Compound MAC" when specifying the list
> of field to be placed in the BUFFER" should say "...2  A single octet
> contains TEAP EAP method type 0x37". Alternatively it could be "...2  A
> single octet contains EAP Type of the inner EAP method related to the
> calculation or 0 if no inner EAP method was executed" (currently "...2  The
> EAP Type sent by the other party in the first TEAP message")
>
>
>
> Please note that there's still a discussion on sending Crypto-Binding TLV
> on "Authentication inner EAP method" or "Inner EAP method that exports MSK"
> only.
>
>
>
> Thanks
>
> Oleg
> ___
> 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] 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  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