[Emu] Updated EMU charter

[Peter Yee]

I've drafted an update to the EMU charter to give us room to work on EAP-EDHOC 
and EAP-FIDO (or whatever we end up calling it). I'd appreciate the WG looking 
over the updated charter 
(https://github.com/emu-wg/charter/blob/master/emu-charter.md) and replying to 
the list with any thoughts you might have on it. I propose to stop taking input 
on the charter one week from today unless there's active discussion taking 
place on the list. That way I can get the revised charter over to Paul Wouters 
(as the relevant Security AD) soon as the next step to getting it approved.

Questions and input most welcome!

-Peter




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

[Emu] [IANA #1359904] expert review for draft-ietf-emu-rfc7170bis (teap-parameters)

[David Dong via RT]

Dear Margaret Cullen and Nancy Cam-Winget (cc: emu WG),

As the designated experts for the TEAP Error TLV (value 5) Error Codes 
registry, can you review the proposed registration in 
draft-ietf-emu-rfc7170bis-15 for us? Please see

https://datatracker.ietf.org/doc/draft-ietf-emu-rfc7170bis/

The due date is March 19.

If this is OK, when the IESG approves the document for publication, we'll make 
the registration at:

https://www.iana.org/assignments/teap-parameters/

Please let us know if you would like for us to wait for both reviewers to 
respond, or if one response is enough.

With thanks,

David Dong
IANA Services Sr. Specialist

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

Re: [Emu] New Version Notification for draft-janfred-eap-fido-02.txt

[Michael Richardson]

Heikki Vatiainen  wrote:
> I haven't worked with CBOR, but I'd be interested to know if, for
> example, how careful we need to be with serialiser/deserialiser to
> avoid problems similar to exponential expansions attacks [1], etc. TLVs

There are no entities like in XML, so that won't work.
CBOR now includes a "packed" format which is essentially a bespoke
compression system for CBOR, with the decompressor defined.
Encoders (compressors) can be as complicated as one likes.

The billion_laughts attack might be possible with packed CBOR, but as a CBOR
Protocol user, you would be justified if you just said, "no packed CBOR"


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






signature.asc
Description: PGP signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New Version Notification for draft-janfred-eap-fido-02.txt

[Michael Richardson]

Alan DeKok  wrote:
>   ALPN would be much simpler, I think.  The downside there is that
> every time you rev the protocol, you have to register a new ALPN name.
> That's annoying.  I don't know if it would be acceptable to register an
> ALPN _prefix_, and then just self-allocate versions.

But, revising the protocol involves a new RFC, so I don't see the logistical
problem of registering a new ALPN.  Maybe it's annoying during development to
have to stick a new value in and not know what it's going to be?


--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



signature.asc
Description: PGP signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New Version Notification for draft-janfred-eap-fido-02.txt

[Jan-Frederik Rieckers]

On 05.03.24 13:40, Alan DeKok wrote:

On Mar 5, 2024, at 5:46 AM, Jan-Frederik Rieckers  wrote:

Well, the beauty of CBOR is that it is very easily extendable.
I completely agree that, with the limited list of map keys, using CBOR instead 
of TLVs seems like shooting cannons at mosquitos, but if in the future we want 
to do more with this, we can.


   Extensibility also has its downsides.  If we're not sure we need the 
functionality, then *unused* functionality is ripe for exploits or issues.


Definitely, and I'm keeping that in mind. (thanks for explicitly 
pointing it out though)


I think there are examples of both. Standards that are too restrictive, 
where people had to misuse some protocol aspects to extend it (or it 
just never reached a noticeable deployment stage, because elements were 
missing and they couldn't extend it without breaking compatibility), and 
too open standards where the extensibility itself was misused and a 
target vector for attacks.


I hope we can find some middle ground where everyone is happy about the 
limitations and the extensibility.





Resource exhaustion is a problem in CBOR, as it is in any other 
serialization/deserialization solution.


   If we only need 3 pieces of data, none nested, then CBOR has more issues 
than TLVs, due to it's inherent nesting.

   i.e. the temptation for implementors is to pass the raw CBOR data to a CBOR 
library.  Which means nested structures, complex maps, etc.  And none of that 
will be used by EAP-FIDO.

   For now I'd suggest concentrating on getting the crypto right, and the 
request / response exchange.  Data encoding can always be changed before it's 
widely implemented.


+1
The current CBOR message format is actually for me too a reminder of 
what data needs to be sent when and by whom, this won't change if we 
switch to TLVs or use base64url-encoded XML for transmission. (/sarcasm 
hint: ok, the XML is maybe a bit too extreme)





They also limit the length of a CBOR message, with a recommendation that every 
authenticator MUST support at least messages of 1024 bytes and that platforms 
have to respect the max message length signaled by the authenticator.


   So EAP-FIDO would also need to negotiate / signal message length?


Not necessarily. The negotiation between Authenticator and platforn in 
FIDO/CTAP is done because the authenticators possibly have very limited 
capabilities, so they need to negotiate that. For EAP-FIDO I think it 
would be reasonable to just go with the 16k limit for TLS record (if I 
remember correctly this is the limit for one TLS record)





We could say something similar about the allowed depth and length of the CBOR 
messages sent in EAP-FIDO.


   Is that fixed, or negotiated?


If we stay with CBOR, I would just have that depth fixed in the 
specification. I think it is reasonable to have a limit on there. And if 
some extension in the future wants to have a deeper CBOR structure, 
there is always the possibility to encode the data as byte sequence, so 
implementations that don't understand this can just skip it, but 
implementations which do understand it can send any data they want.


Cheers,
Janfred

--
Herr Jan-Frederik Rieckers
Security, Trust & Identity Services

E-Mail: rieck...@dfn.de | Fon: +49 30884299-339 | Fax: +49 30884299-370
Pronomen: er/sein | Pronouns: he/him
__

DFN - Deutsches Forschungsnetz | German National Research and Education 
Network

Verein zur Förderung eines Deutschen Forschungsnetzes e.V.
Alexanderplatz 1 | 10178 Berlin
https://www.dfn.de

Vorstand: Prof. Dr.-Ing. Stefan Wesner | Prof. Dr. Helmut Reiser | 
Christian Zens

Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch
VR AG Charlottenburg 7729B | USt.-ID. DE 136623822


smime.p7s
Description: S/MIME Cryptographic Signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New Version Notification for draft-janfred-eap-fido-02.txt

[Alan DeKok]

On Mar 5, 2024, at 5:46 AM, Jan-Frederik Rieckers  wrote:
> Well, the beauty of CBOR is that it is very easily extendable.
> I completely agree that, with the limited list of map keys, using CBOR 
> instead of TLVs seems like shooting cannons at mosquitos, but if in the 
> future we want to do more with this, we can.

  Extensibility also has its downsides.  If we're not sure we need the 
functionality, then *unused* functionality is ripe for exploits or issues.

> Resource exhaustion is a problem in CBOR, as it is in any other 
> serialization/deserialization solution.

  If we only need 3 pieces of data, none nested, then CBOR has more issues than 
TLVs, due to it's inherent nesting.

  i.e. the temptation for implementors is to pass the raw CBOR data to a CBOR 
library.  Which means nested structures, complex maps, etc.  And none of that 
will be used by EAP-FIDO.

  For now I'd suggest concentrating on getting the crypto right, and the 
request / response exchange.  Data encoding can always be changed before it's 
widely implemented.

> They also limit the length of a CBOR message, with a recommendation that 
> every authenticator MUST support at least messages of 1024 bytes and that 
> platforms have to respect the max message length signaled by the 
> authenticator.

  So EAP-FIDO would also need to negotiate / signal message length?

> We could say something similar about the allowed depth and length of the CBOR 
> messages sent in EAP-FIDO.

  Is that fixed, or negotiated?

  Alan DeKok.

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

[Emu] FW: New Version Notification for draft-ar-emu-pqc-eapaka-00.txt

[Aritra Banerjee (Nokia)]

Hello,

We published a new draft titled “Post-Quantum Cryptography enhancement in 
EAP-AKA prime” : draft-ar-emu-pqc-eapaka-00 - Post-Quantum Cryptography 
enhancement in EAP-AKA prime 
(ietf.org)

This draft aims to enhance the security of EAP-AKA' FS by making it 
quantum-safe.

Comments and suggestion are welcome.

Regards,
Aritra.

From: internet-dra...@ietf.org 
Date: Monday, 4. March 2024 at 12:47
To: Tirumaleswar Reddy.K , Aritra Banerjee (Nokia) 
, Tirumaleswar Reddy 
Subject: New Version Notification for draft-ar-emu-pqc-eapaka-00.txt

CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.



A new version of Internet-Draft draft-ar-emu-pqc-eapaka-00.txt has been
successfully submitted by Aritra Banerjee and posted to the
IETF repository.

Name: draft-ar-emu-pqc-eapaka
Revision: 00
Title:Post-Quantum Cryptography enhancement in EAP-AKA prime
Date: 2024-03-04
Group:Individual Submission
Pages:12
URL:  https://www.ietf.org/archive/id/draft-ar-emu-pqc-eapaka-00.txt
Status:   https://datatracker.ietf.org/doc/draft-ar-emu-pqc-eapaka/
HTML: https://www.ietf.org/archive/id/draft-ar-emu-pqc-eapaka-00.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-ar-emu-pqc-eapaka


Abstract:

   Forward Secrecy for the Extensible Authentication Protocol Method for
   Authentication and Key Agreement (EAP-AKA' FS) is specified in
   [I-D.ietf-emu-aka-pfs], providing updates to [RFC9048] with an
   optional extension that offers ephemeral key exchange using the
   traditional Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key
   agreement algorithm for achieving perfect forward secrecy (PFS).
   However, it is susceptible to future threats from Cryptographically
   Relevant Quantum Computers, which could potentially compromise a
   traditional ephemeral public key.  If the adversary has also obtained
   knowledge of the long-term key and ephemeral public key, it could
   compromise session keys generated as part of the authentication run
   in EAP-AKA'.

   This draft aims to enhance the security of EAP-AKA' FS making it
   quantum-safe.



The IETF Secretariat

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

Re: [Emu] New Version Notification for draft-janfred-eap-fido-02.txt

[Jan-Frederik Rieckers]

On 05.03.24 10:33, Heikki Vatiainen wrote:
On Tue, 5 Mar 2024 at 09:56, Alexander Clouter > wrote:


Using an entire serialiser to support only a map carrying attributes
with 1->3 *predetermined* keys seems a bit of a cannon to deal with
a mosquito solution as they go. As a hypothetical, would people have
a stronger opinion here if CBOR was swapped for protocol buffers or
ASN.1 in the document?


Ok, I'll bite. I've worked recently with ASN.1 (hello GSM world) and 
found it much easier to work than I initially though. I found the 
interoperability of different MAP and TCAP (again GSM) implementations 
to work well together. In other words, the software I made successfully 
talked to other software from the beginning. This allowed the work to 
concentrate on the software functionality instead of serialising bits on 
the line.


I'd say the main point is: use encoding that's appropriate for the task. 
ASN.1 suits for 2G/3G complex things. Simple TLVs have so far worked 
well with EAP.


I haven't worked with CBOR, but I'd be interested to know if, for 
example, how careful we need to be with serialiser/deserialiser to avoid 
problems similar to exponential expansions attacks [1], etc. TLVs are 
known for people working on Radius/Diameter/EAP. With CBOR it would be 
useful if the draft were to have information to avoid potential 
problems, especially if the CBOR input can come from untrusted sources. 
I'm sure this information is available, and it would help the 
implementers if they're notified about what to look out for, if needed.


[1] https://en.wikipedia.org/wiki/Billion_laughs_attack 



Well, the beauty of CBOR is that it is very easily extendable.
I completely agree that, with the limited list of map keys, using CBOR 
instead of TLVs seems like shooting cannons at mosquitos, but if in the 
future we want to do more with this, we can.


Resource exhaustion is a problem in CBOR, as it is in any other 
serialization/deserialization solution.


Here a quote from the CTAP2 spec regarding the use of CBOR in CTAP2 and 
how they deal with the problem:


https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.html#message-encoding


Because some authenticators are memory constrained, the depth of nested CBOR 
structures used by all message encodings is limited to at most four (4) levels 
of any combination of CBOR maps and/or CBOR arrays. Authenticators MUST support 
at least 4 levels of CBOR nesting. Clients, platforms, and servers MUST NOT use 
more than 4 levels of CBOR nesting.


They also limit the length of a CBOR message, with a recommendation that 
every authenticator MUST support at least messages of 1024 bytes and 
that platforms have to respect the max message length signaled by the 
authenticator.


We could say something similar about the allowed depth and length of the 
CBOR messages sent in EAP-FIDO.


One thing that I still have to look into is how we would deal with 
multiple Discoverable Credentials registered for the same RPID, one 
solution would be to send a signature from all of them, and at least 
then I would put the tuple (Credential ID, authdata, signature) in a 
CBOR map, and have the possibility to put multiple of these maps in the 
message.



I'll try to get some Face2Face time with some CBOR experts and talk to 
them about the way they would suggest using CBOR in this protocol.



Cheers,
Janfred


--
Herr Jan-Frederik Rieckers
Security, Trust & Identity Services

E-Mail: rieck...@dfn.de | Fon: +49 30884299-339 | Fax: +49 30884299-370
Pronomen: er/sein | Pronouns: he/him
__

DFN - Deutsches Forschungsnetz | German National Research and Education 
Network

Verein zur Förderung eines Deutschen Forschungsnetzes e.V.
Alexanderplatz 1 | 10178 Berlin
https://www.dfn.de

Vorstand: Prof. Dr.-Ing. Stefan Wesner | Prof. Dr. Helmut Reiser | 
Christian Zens

Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch
VR AG Charlottenburg 7729B | USt.-ID. DE 136623822


smime.p7s
Description: S/MIME Cryptographic Signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New Version Notification for draft-janfred-eap-fido-02.txt

[Heikki Vatiainen]

On Tue, 5 Mar 2024 at 09:56, Alexander Clouter 
wrote:


> Using an entire serialiser to support only a map carrying attributes with
> 1->3 *predetermined* keys seems a bit of a cannon to deal with a mosquito
> solution as they go. As a hypothetical, would people have a stronger
> opinion here if CBOR was swapped for protocol buffers or ASN.1 in the
> document?
>

Ok, I'll bite. I've worked recently with ASN.1 (hello GSM world) and found
it much easier to work than I initially though. I found the
interoperability of different MAP and TCAP (again GSM) implementations to
work well together. In other words, the software I made successfully talked
to other software from the beginning. This allowed the work to concentrate
on the software functionality instead of serialising bits on the line.

I'd say the main point is: use encoding that's appropriate for the task.
ASN.1 suits for 2G/3G complex things. Simple TLVs have so far worked well
with EAP.

I haven't worked with CBOR, but I'd be interested to know if, for example,
how careful we need to be with serialiser/deserialiser to avoid problems
similar to exponential expansions attacks [1], etc. TLVs are known for
people working on Radius/Diameter/EAP. With CBOR it would be useful if the
draft were to have information to avoid potential problems, especially if
the CBOR input can come from untrusted sources. I'm sure this information
is available, and it would help the implementers if they're notified about
what to look out for, if needed.

[1] https://en.wikipedia.org/wiki/Billion_laughs_attack

-- 
Heikki Vatiainen
h...@radiatorsoftware.com
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] New Version Notification for draft-janfred-eap-fido-02.txt

[Alexander Clouter]

On Mon, 4 Mar 2024, at 19:11, Alan DeKok wrote:
>   The downside is that CBOR is likely more expressive than TLVs, and 
> perhaps what people should be moving towards.  There's no reason to 
> stick with TLVs simply because we've been using them for years.  It's 
> 2024, new technologies exist.

The problem is the framing does not use any of the expressive parts of CBOR. So 
this is not really relevant here.

>> (I'm not fixed on using CBOR for the message format, but since CTAP2 also 
>> uses CBOR at least the client needs to have a CBOR library anyway.)
>
>   I think tho that the EAP implementations don't need to implement CBOR 
> in order to do CTAP2, right?  They just hand the data to another 
> library, and it does the work.

My understanding here is that the document as it is requires a CBOR serialiser, 
even if you then intend to just  those opaque materials to a CTAP2 library; 
this is why a CBOR framing description is in the document. Right?

Using an entire serialiser to support only a map carrying attributes with 1->3 
*predetermined* keys seems a bit of a cannon to deal with a mosquito solution 
as they go. As a hypothetical, would people have a stronger opinion here if 
CBOR was swapped for protocol buffers or ASN.1 in the document?

EAP-EDHOC on the other hand (which uses CBOR/COSE) allows an EAP implementation 
to readily extract the components of EDHOC without having to understand how to 
serialise EDHOC; enabling straight forward outsourcing to a library.

Cheers

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

[Emu] FW: New Version Notification for draft-yan-emu-eap-multiple-psk-00.txt

[Yanlei(Ray)]

Hi all,

I'd like to bring your attention to the following individual IETF draft.
Your comments are warmly welcome!

The high level summary is as follows:
The existing PSK-based EAP methods, such as EAP-GPSK [RFC5433] and EAP-PSK 
[RFC4764],  assumed that only one PSK had been configured on a pair of EAP peer 
and server.  
Using only one PSK will bring several security issues [RFC5433]. 
One solution is to use multiple PSKs between the EAP peer and server.
This document modifies the EAP-GPSK to support the negotiation of a PSK among 
multiple PSKs.

Regards,
Lei YAN

-Original Message-
From: internet-dra...@ietf.org  
Sent: Monday, March 4, 2024 9:20 PM
To: Yanlei(Ray) 
Subject: New Version Notification for draft-yan-emu-eap-multiple-psk-00.txt

A new version of Internet-Draft draft-yan-emu-eap-multiple-psk-00.txt has been 
successfully submitted by Lei YAN and posted to the IETF repository.

Name: draft-yan-emu-eap-multiple-psk
Revision: 00
Title:EAP Multiple Pre-Shared Keys (EAP-MPSK) Method
Date: 2024-03-04
Group:Individual Submission
Pages:4
URL:  https://www.ietf.org/archive/id/draft-yan-emu-eap-multiple-psk-00.txt
Status:   https://datatracker.ietf.org/doc/draft-yan-emu-eap-multiple-psk/
HTML: https://www.ietf.org/archive/id/draft-yan-emu-eap-multiple-psk-00.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-yan-emu-eap-multiple-psk


Abstract:

   This document defines an Extensible Authentication Protocol (EAP)
   method for supporting the negotiation of a PSK among multiple PSKs.



The IETF Secretariat


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