[Emu] I-D Action: draft-ietf-emu-eap-tls13-20.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the EAP Method Update WG of the IETF. Title : Using EAP-TLS with TLS 1.3 (EAP-TLS 1.3) Authors : John Preuß Mattsson Mohit Sethi Filename: draft-ietf-emu-eap-tls13-20.txt Pages : 36 Date: 2021-09-03 Abstract: The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. This document specifies the use of EAP-Transport Layer Security (EAP-TLS) with TLS 1.3 while remaining backwards compatible with existing implementations of EAP-TLS. TLS 1.3 provides significantly improved security, privacy, and reduced latency when compared to earlier versions of TLS. EAP-TLS with TLS 1.3 (EAP-TLS 1.3) further improves security and privacy by always providing forward secrecy, never disclosing the peer identity, and by mandating use of revocation checking. This document also provides guidance on authentication, authorization, and resumption for EAP-TLS in general (regardless of the underlying TLS version used). This document updates RFC 5216. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-tls13-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-20 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] I-D Action: draft-ietf-emu-eap-noob-06.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the EAP Method Update WG of the IETF. Title : Nimble out-of-band authentication for EAP (EAP-NOOB) Authors : Tuomas Aura Mohit Sethi Aleksi Peltonen Filename: draft-ietf-emu-eap-noob-06.txt Pages : 68 Date: 2021-09-03 Abstract: The Extensible Authentication Protocol (EAP) provides support for multiple authentication methods. This document defines the EAP-NOOB authentication method for nimble out-of-band (OOB) authentication, and key derivation. The EAP method is intended for bootstrapping all kinds of Internet-of-Things (IoT) devices that have no pre-configured authentication credentials. The method makes use of a user-assisted one-directional OOB message between the peer device and authentication server to authenticate the in-band key exchange. The device must have a non-network input or output interface, such as a display, microphone, speaker, or blinking light, which can send or receive dynamically generated messages of tens of bytes in length. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-noob-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-noob-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] [Ace] CoAP-EAP draft
Dear Christian, Thank you for your detailed review. You are raising indeed very interesting points. Just came back from vacation and we will respond as soon as possible. Best Regards. On 16/8/21 16:40, Christian Amsüss wrote: Hello CoAP-EAP authors and involved groups, (CC'ing core@ as this is a review on CoAP usage), I've read the -03 draft and accumulated a few comments; largely in sequence of occurrence. Over all, the protocol has improved a lot since I've last had my eyes on it. Several comments below are about how prescriptive the message types are. I believe that this should be resolved towards generality, or else the usability of this protocol with generic CoAP components will be limited (or, worse, still implemented and then surprisingly incompatible). * Figure 1: For readers new to the topic of EAP, I think that it might be useful to extend this to cover also the EAP server or AAA infrastructure, if that can be covered without too much complication. Suggestion (without illusions of correctness): IoT deviceController ++++ | EAP peer/ || EAP auth./ |+-+[ AAA infra. ] | CoAP server|+--+| CoAP client|+-+[ EAP server?] ++ CoAP ++ EAP? \_ Scope of this document _/ Figure 1: CoAP-EAP Architecture * `/.well-known/a`: [note: May be irrelevant, see next two items] If the designated experts don't go along with a very-short option (I'd kind of doubt you'd get anything shorter than `/.well-known/eap`) and if that puts you up against practical limits, using a short-hand option might be viable. So far there's no document for it and I've only pitched the idea briefly at an interim[1] (slides at [2]), but if push comes to shove and you need the compactness, let me know and that work can be expedited. [1]: https://datatracker.ietf.org/meeting/interim-2021-core-05/session/core [2]: https://datatracker.ietf.org/meeting/interim-2021-core-05/materials/slides-interim-2021-core-05-sessa-core-option-for-well-known-resources-00 * Discovering the Controller is described rather generically, but with CoAP discovery as an example. As long as CoAP discovery (as per RFC6690/7252) is used, that already produces a URI, which can contain any path the server picked. It has thus no need for a well-known path. Are there other discovery options envisioned that'd only result in a network address? Only for these, a well-known path would make sense. (And then it's up to the envisioned client complexity if one is warranted). For comparison, RD[3] explores some of the options. A path may be discovered using CoAP discovery as `?rt=core.rd*` right away from multicast. Or an address may be discovered using an IPv6 RA option, with CoAP discovery acting on that address. Only for cases of very simple endpoints, it also defines a `/.well-known/rd` name that can be used without CoAP discovery (and thus link parsing) happening beforehand. The same rationales may apply for EAP (the devices using the resource are mostly servers, otherwise, and send a very simple request to start things), but again that's only if the address was discovered through something that's not CoAP discovery already. [3]: https://www.ietf.org/archive/id/draft-ietf-core-resource-directory-28.html#name-rd-discovery-and-other-inte * For message 1, why does this need to go to a fixed resource? There has been previous communication in message 0 in which the resource could have been transported. Granted, it's not as easy as in messages 2-to-3 etc where the Location-* options are around, but the original message 0 POST could just as well contain the path in the payload. There are options as to how to do that precisely (just the URI reference in text form, or a RFC6690 link, or a CBOR list of path segments, or a CRI reference[4] -- if the latter were in WGLC already I'd recommend it wholeheartedly), but either of them would stay more true to the style of the other messages in that the earlier message informs the path choice of the next ones. An upside of this would be that it allows better behavior in presence of proxies (see later), even though it may be practical to not spec that out in full here. (But the path would be open for further specs, and they'd just need some setting down of paving stones). [4]: https://datatracker.ietf.org/doc/draft-ietf-core-href/ * (Bycatch of suggesting URIs): It may be worth mentioning that the NON's source address can easily be spoofed. Thus, any device on the network can trigger what the authenticator may think of as a device-triggered reauthentication, and the device may think of as an authenticator-triggered reauthentication (provided it works that way, see below when
Re: [Emu] [Ace] About securing last exchange CoAP-EAP
Hi Christian: Thank you for comments. See our comments inline. > El 16 ago 2021, a las 16:52, Christian Amsüss > escribió: > > Hello, > > On Sat, Aug 14, 2021 at 01:37:06PM +0200, Dan Garcia Carrillo wrote: >> As such, CoAP server (left side) could not see the content of the CoAP >> message (message 7) without deciphering it. Moreover, as the URI-path is >> also ciphered we cannot point to the right application to process the >> message to achieve an alternate indication of success. > > If the recipient ID were available a bit earlier (and not derived from > the MSK), would it then be viable to infer from the OSCORE ID that this > is the last message, process an "EAP success", and start derivation just > to extract the session lifetime (and thereby confirm the keys)? What you mentioned was something we already considered but we do not see how it would solve the problem. Let me explain. According to OSCORE RFC , Section 8.2 - step 2: "If either the decompression or the COSE message fails to decode, or the server fails to retrieve a Recipient Context with Recipient ID corresponding to the 'kid' parameter received, then the server SHALL stop processing the request.” What you mention solves step 2, however the step 5 says: "If decryption fails, the server MUST stop processing the request and MAY respond with a 4.00 (Bad Request) error message." However, the OSCORE context with Recipient ID does not have any Recipient key yet, correct?. To make this work, we believe this should happen. 1) The CoAP server should create an OSCORE context with ID but without any key material. 2) When the CoAP message contains the OSCORE ID that hits the OSCORE context without any key material, we would have to assume this is CoAP-EAP: the OSCORE implementation should not discard or give a fail for this coap message but "pass the control" to CoAP-EAP so that we send a altAccept to the EAP state machine so we get the MSK. 3) From the MSK, we derive the OSCORE key material for the OSCORE context with the corresponding ID and update the OSCORE context with this key material 4) Verify that the received protected coap-message with OSCORE. 5) Then we can get the cleartext information. For us, this seems a little odd and we do no think it is supported by OSCORE RFC, are we wrong? Any comment is welcome. Best Regards P.D: Dan is processing your review of the I-D. Thank you very much. > > (That'd be all assuming that the "EAP success" contains really just the > EAP success code and no further information, which would be "compressed" > into the "some OSCORE is sent on this" information, and that the > Session-Lifetime does not need to be known to advance the EAP state > machine). > > BR > c > > -- > To use raw power is to make yourself infinitely vulnerable to greater powers. > -- Bene Gesserit axiom > ___ > Ace mailing list > a...@ietf.org > https://www.ietf.org/mailman/listinfo/ace --- Rafa Marin-Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +3486501 Fax: +34868884151 e-mail: r...@um.es --- ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
