[Emu] Minutes from EMU @ IETF 111

2021-07-31 Thread Mohit Sethi M
Dear all,

Thank you for participating in the EMU session at IETF 111. Minutes from 
the EMU session at IETF 111 have now been uploaded: 
https://datatracker.ietf.org/meeting/111/materials/minutes-111-emu-00 


Please report any issues by August 8, 2021.

Joe and Mohit

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


Re: [Emu] Benjamin Kaduk's Discuss on draft-ietf-emu-eap-noob-04: (with DISCUSS and COMMENT)

2021-07-16 Thread Mohit Sethi M
Hi Ben,

Thank you for your usual detailed review. We have uploaded a new version 
of the draft: https://tools.ietf.org/html/draft-ietf-emu-eap-noob-05. 
Here is the diff for your convenience: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-noob-05.

Answers inline.

--Mohit

On 4/22/21 7:26 AM, Benjamin Kaduk via Datatracker wrote:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-emu-eap-noob-04: Discuss
>
> 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 tohttps://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/
>
>
>
> --
> DISCUSS:
> --
>
> The example JWK for cryptosuite 1 in §5.1 is not well-formed.  RFC 8037
> key-exchange uses a crv of "X25519" and a kty of "OKP".
> (See COMMENT for more quibbles with §5.1.)
> I think Appendix E is also using the wrong "kty" for X25519 (but is
> properly using "X25519" as the "crv").

Good catch. This is now fixed in the script used to generate the test 
vectors: 
https://github.com/tuomaura/eap-noob/commit/a9e8da4ec227b4afe8fb04feb71d76265396882b.
 
The example messages in the draft are not yet updated (pending your 
feedback on our proposal below).

>
> I'd also like to discuss our treatment of channel binding, as the
> current mention seems dangerously incomplete.  I don't remember if there
> is generic discussion of channel binding in the core EAP RFCs (if so, a
> specific reference would help), but otherwise if we're going to mention
> that protocol elements can be used for channel binding we should give
> some indication of how to actually do so in a secure manner (e.g., what
> protocol element needs to be verified against external channel
> information and what to do if they don't match).

We have added a section on channel binding which should address all the 
issues: 
https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-noob-05#section-7.7.

>
>
> --
> COMMENT:
> --
>
> Thanks for putting together this pretty comprehensive treatment of a
> topic that is simple to understand but has a lot of important details.
> (I do have some comments about a few of those details, just to check
> that we do have them right.)  I especially appreciate the strong feature
> set that's been assembled.
>
> In Section 3.5 we discuss a key derivation scheme and say to use the
> one-step KDF from NIST SP 800-56Ar3 §5.8.2.1.  In particular, this is
> not the two-step (extract-then-expand) KDF of the following section
> (§5.8.2.2).  Since the (EC)DH shared secret Z is not uniformly random,
> my understanding was that generally the two-step KDF was needed, since
> the one-step KDF assumes that the input key is uniformly selected.  I am
> not balloting Discuss for this point because I assume it was considered
> in the formal verification, but I would very much appreciate some
> additional insight into this selection.
We did not specifically model the security of the KDF itself. The NIST 
specification defines the one-step key derivation function for use with 
ECDH shared secrets (NIST calls it 'Z' a byte string that represents the 
shared secret). In fact RFC 7518 
(https://datatracker.ietf.org/doc/html/rfc7518#section-4.6.2) uses the 
same NIST KDF for deriving keys. The one-step may have stronger 
assumptions from the underlying hash function but we thought the hash 
functions currently specified in the draft are safe to use with a 
one-step function. In future, when we move to KMACs and SHA3 family, we 
would not need a two-step KDF.
> Section 3.1
>
> The overall protocol starts with the Initial Exchange, which
> comprises four EAP request-response pairs.  In the Initial Exchange,
> the server allocates an identifier to the peer, and the server and
>
> Is this a DoS risk for state exhaustion on the server?
>
> The server MUST NOT repeat a successful OOB Step with the same peer
> except if the association with the peer is explicitly reset by the
> user or lost due to failure of the persistent storage in the server.
> More specifically, once the association has entered the Registered
> state, the server MUST NOT delete the association or go back to the
> ephemeral states 0..2 without explicit user approval.  [...]
>
> This also looks like a DoS risk, if a malicious device/user completes
> the OOB step then only deletes the association on the device (without
> telling the server), then re-registers, 

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

2021-07-16 Thread Mohit Sethi M
Hi Éric,

Thanks for the review. Answers below.

--Mohit

On 4/20/21 4:29 PM, Éric Vyncke via Datatracker wrote:
> Éric Vyncke has entered the following ballot position for
> draft-ietf-emu-eap-noob-04: 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 tohttps://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/
>
>
>
> --
> COMMENT:
> --
>
> Thank you for the work put into this document. I really like the ideas behind
> this OOB authentication.
>
> Please find below some non-blocking COMMENT points (**but replies would be
> appreciated esp around CBOR**), and some nits.
>
> Special thanks to Dave Thaler for his early IoT directorate review (and the
> CBOR discussion with Carsten):
> https://datatracker.ietf.org/doc/review-ietf-emu-eap-noob-01-iotdir-early-thaler-2020-06-12/
> https://mailarchive.ietf.org/arch/msg/iot-directorate/PNi6nxtR7_1T2rxu7O49HRx5Kdg/
>
> I hope that this helps to improve the document,
>
> Regards,
>
> -éric
>
> PS: when the ballot for this document was created, I failed to spot the DNS &
> IoT aspects of it, hence, the absence of INT and IoT directorates telechat
> reviews.
>
> == COMMENTS ==
>
> Like Carsten, I am really puzzled by the lack of consideration of CBOR to
> replace JSON especially for a protocol aimed at constrained devices. Was this
> discussed at the WG level ? I was unable to read any discussion on the mail
> list except about the IoT directorate thread.
>
> This non-obvious choice of encoding ***should really be discussed*** in the
> document.

The working group had extensive discussion on the issue of CBOR vs JSON 
encoding. See, for example, slide 8 from IETF 108 
(https://datatracker.ietf.org/meeting/108/materials/slides-108-emu-eap-noob-00 
).
 
At the end, there was consensus for using JSON (with the possibility of 
adding CBOR later). There were many reasons for this decision by the 
working group. First, there were several implementations and early 
deployments of EAP-NOOB already using JSON. Second, there is support for 
JSON encoding/decoding in wpa_supplicant. wpa_supplicant is the most 
popular EAP peer implementation. It does not have support for CBOR 
encoding/decoding. Third, devices using EAP are either class 1 or 2, as 
defined in RFC7228. So while the benefits of CBOR would have been nice, 
they can live with JSON.

> -- Section 2 --
> Please apply the current BCP 14 template and not the old RFC 2119 one.
We have updated the text.
> -- Section 3.1 --
> "timeout needs to be several minutes rather than seconds" can this lead to a
> DoS against the server, which potentially needs to keep states for minutes ?
We have added a new sub-section on "Denial of Service" in the security 
considerations section: 
https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-noob-05#section-7.8 

> -- Section 3.2.1 --
> I am not a EAP expert, so bear with my possibly naive question, "based on the
> realm part of the NAI", isn't it always "eap-noob.arpa" in this case ?
That's a good question. You are right that in the default case, it will 
always be eap-noob.arpa. However, EAP-NOOB allows the server to assign a 
new NAI: "the server MAY assign a new NAI to the peer in the Initial 
Exchange or Reconnect Exchange, in the NewNAI field of request types 2 
and 7, to override any previous NAI value.". So it can be different if 
the server assigns something other than eap-noob.arpa.
> -- Section 3.2.2 --
> What happens if the peer does not support any of the server's ciphersuite? Esp
> in the world of IoT where peers are old and cannot always be updated.Should
> there be a forward pointer to section 3.6.4 ?
We have tried to make the text readable by collecting error handling 
into one section (3.6), rather than constantly interrupting the flow of 
the text by mentioning possible error conditions. We hope that the list 
in section 3.6 gives the implementers a more complete picture of error 
handling than if some, but not all, errors were explained in the 
sections where they may occur.
> -- Section 3.2.3 --
> Suggest to give a hint to the reader for "Hoob": is this Hash of OoB ? Same
> comment for "Noob".
We expect those familiar with cryptographic protocol notations to 
interpret the H in Hoob as the common symbol for hash and oob as its 
subscript. In Latex, this would be $H_{\text{oob}}$. Similarly, Noob 
consists of the commonly-used symbol N for a nonce and the oob 
subscript: $N_{\text{oob}}$. While we 

Re: [Emu] Francesca Palombini's Discuss on draft-ietf-emu-eap-noob-04: (with DISCUSS and COMMENT)

2021-07-16 Thread Mohit Sethi M
Hi Francesca,

We have submitted a new version ( 
https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-noob-05 ) which 
hopefully addresses your comments. Here is the diff for your 
convenience: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-noob-05.txt

See our answers below.

--Mohit

On 4/20/21 1:37 AM, Francesca Palombini via Datatracker wrote:
> Francesca Palombini has entered the following ballot position for
> draft-ietf-emu-eap-noob-04: Discuss
>
> 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 tohttps://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/
>
>
>
> --
> DISCUSS:
> --
>
> Thank you for the work on this document. I have a couple of blocking comments
> related to the IANA section, which should be easy to fix, plus some minor non
> blocking comments below.
>
> Francesca
>
> 1. -
>
> Section 5.
>
> FP: IANA is requested to create a sub registry to the EAP registry, but there
> is no actual "Nimble out-of-band authentication for EAP Parameters" registry
> defined, nor values registered in it. Either this is a new page or (I would
> suggest) the subregistries are just created directly under the EAP page.
This question was also asked by Sabrina during the IANA review.  A 
separate URL (or page) for EAP-NOOB is what we intended. There is 
precedence for such an approach: EAP-FAST. There is a separate URL for 
EAP-FAST parameters: 
https://www.iana.org/assignments/eap-fast-parameters/eap-fast-parameters.xhtml 
but all the sub registries are still listed on the main EAP registry 
with links (such as 
https://www.iana.org/assignments/eap-numbers/eap-numbers.xhtml#eap-numbers-5). 
So we are hoping for the same, i.e.: i) a separate URL for the EAP-NOOB 
registry titled "Nimble out-of-band authentication for EAP Parameters", 
ii) the separate URL should contain sub registries listed in section 5.1 
to 5.5 of the draft, iii) the sub registries are listed in the EAP 
Registry 
(https://www.iana.org/assignments/eap-numbers/eap-numbers.xhtml) only as 
links pointing to the URL to the separate EAP-NOOB registry.
> 2. -
>
> Section 5.1 and following
>
> FP: This document defines several new registry with policy Specification
> required, which will need designated experts.
> https://tools.ietf.org/html/rfc8126#section-5.3  states that:
>
> When a designated expert is used, the documentation should give clear
> guidance to the designated expert, laying out criteria for performing
> an evaluation and reasons for rejecting a request.  In the case where
>
> I believe designated expert guidance should be added to this document.
We have added section "Guidance for Designated Experts": 
https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-noob-05#section-5.7. 
We hope this is sufficient.
> --
> COMMENT:
> --
>
> 3. -
>
> document are to be interpreted as described in [RFC2119].
>
> FP: Please update as indicated by RFC 8174.
Done.
> 4. -
>
> it supports, an indicator of the OOB channel directions it supports
> (Dirs), and a ServerInfo object.  The peer chooses one of the
>
> FP: Please add a reference to where the ServerInfo object is defined, as this
> is its first occurrence.
>
> 5. -
>
>|  (Type=3,PeerId,PKs,Ns,[SleepTime])  |
>
> FP: SleepTime appear in the figure without having been introduced in the
> previous paragraph, as the other parameters. I would suggest adding a sentence
> about it, including a fw reference to where it is explained in detail (3.2.5).
As authors we have tried to strike a careful balance between explaining 
new terms when they are first occur vs. avoiding repetition and 
interruptions to the readability of the text. Therefore, some terms like 
ServerInfo, PeerInfo, SleepTime etc. are not defined immediately. We 
hope this is an acceptable compromise.
> 6. -
>
> use this serve-assigned NAI.  When the peer moves to the Registered
>
> FP: nit - s/serve/server
Fixed.
> 7. -
>
> and truncated to the 16 leftmost bytes of the output.  The message
>
> FP: please mention that network byte order is used (either here or in the
> terminology).
The byte order is relevant when encoding/decoding things like integers 
etc. While cryptographic hash functions may use integers or 32- or 
64-bit words internally, their output is a byte string, and the order of 
the bytes in that output is defined by 

Re: [Emu] Erik Kline's No Objection on draft-ietf-emu-eap-noob-04: (with COMMENT)

2021-07-16 Thread Mohit Sethi M
Hi Erik,

Thanks for the review. Answers below.

--Mohit

On 4/19/21 1:32 AM, Erik Kline via Datatracker wrote:
> Erik Kline has entered the following ballot position for
> draft-ietf-emu-eap-noob-04: 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 tohttps://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/
>
>
>
> --
> COMMENT:
> --
>
> [ section 2 ]
>
> * Do you want to use the 8174 language instead of the 2119 version?
Fixed.
> [ section 5.6 ]
>
> * For eap-noob.arpa (or noob.eap.arpa or whatever), even though
>Application Software, Name Resolution APIs and Libraries, and
>Caching DNS Servers are "not expected to recognize this domain
>name as special", there is no harm if they do recognize it and
>short circuit any resolution attempts, yes?
Earlier versions of the draft were using a different domain name 
(eap-noob.net 
:https://datatracker.ietf.org/doc/html/draft-aura-eap-noob-07#section-4.4). 
Back then, we had added section 5.6 and required authoritative DNS 
Servers to respond with NXDOMAIN. The working group later came to a 
consensus that such individual domain names are not ideal and we should 
instead reserve a special use domain under .arpa. Thus, the requirement 
for responding with NXDOMAIN is no longer needed and section 5.6 is 
redundant. We have now removed the section in latest draft: 
https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-noob-05.
> ___
> 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


Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3 (draft-ietf-emu-eap-tls13-17)

2021-07-07 Thread Mohit Sethi M
Hi Oleg, Joe, all,

On 7/8/21 8:06 AM, Joseph Salowey wrote:


On Tue, Jul 6, 2021 at 10:08 PM Joseph Salowey 
mailto:j...@salowey.net>> wrote:


On Mon, Jun 28, 2021 at 8:11 AM Oleg Pekar 
mailto:oleg.pekar.2...@gmail.com>> wrote:
I still see unclearness in Section "2.2. Identity Verification", I'm trying to 
look from the implementer's perspective.

1) "Since EAP-TLS deployments may use more than one EAP
   server, each with a different certificate, EAP peer implementations
   SHOULD allow for the configuration of a unique trusted root (CA
   certificate) to authenticate the server certificate and one or more
   server names to match against the SubjectAltName (SAN) extension in
   the server certificate.  To simplify name matching, an EAP-TLS
   deployment can assign a name to represent an authorized EAP server
   and EAP Server certificates can include this name in the list of SANs
   for each certificate that represents an EAP-TLS server."

--- question: Should the server name match *any* of SAN extensions in the 
server certificate? If so - then suggest to say this explicitly.


[Joe] DOes adding the following sentence help?

"If any of the configured names match any of the names in the SAN extension 
then the name check passes."
This makes sense. I will update the draft in github.


[Joe] yes the behavior is to match any.

2) "If server
   name matching is not used, then peers may end up trusting servers for
   EAP authentication that are not intended to be EAP servers for the
   network."

--- question: It looks like a warning, right? Suggest to make it more explicit. 
Something like "If server name matching is not used, then it essentially 
decreases the level of security of peer's authentication since the peer may end 
up trusting servers for EAP authentication that are not intended to be EAP 
servers for the network."


[Joe] Thanks, I think that is better wording.

I find the text a little hard to parse. I am not sure how comfortable we are 
with defining "levels" of security. Also, "peer's authentication" might confuse 
the reader since we are talking about server name matching. I don't really have 
a better suggestion. Perhaps something along the lines:  it essentially 
degrades the peer's confidence that the EAP server with which it is interacting 
is authoritative for the given network??

--Mohit


Regards,
Oleg

On Mon, Jun 28, 2021 at 2:26 AM Joseph Salowey 
mailto:j...@salowey.net>> wrote:
This is the working group last-call (WGLC) for draft-ietf-emu-eap-tls13.  
Please review the draft, focus on the changes since the last WGLC and submit 
your comments to the list by July 8, 2021.

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-17

A diff from the previous WGLC version (-15):
https://www.ietf.org//rfcdiff?url1=draft-ietf-emu-eap-tls13-17=draft-ietf-emu-eap-tls13-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-17

Thanks,

Joe
___
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 mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


[Emu] Call for agenda items - EMU @ IETF 111

2021-07-06 Thread Mohit Sethi M
EMU @ IETF 111 will be on Thursday, July 29, 2021, from 23:30  to 00:30 
(+1) UTC.

Please send the chairs (emu-cha...@ietf.org) requests for presentation 
slots. Don't forget to include the title of your presentation, related 
drafts, and the approximate amount of time needed.

We have already received a request for presentation of 
draft-chen-emu-eap-tls-ibs. Thank you for sending in your request early.

Joe and Mohit

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


Re: [Emu] draft-ietf-emu-eap-tls13-16.txt

2021-06-11 Thread Mohit Sethi M
Hi Alan,

Response in-line.

On 6/11/21 4:38 PM, Alan DeKok wrote:
>Some comments have been addressed, others not.  The majority of the issues 
> raised in my review have been silently ignored.  Some issues are nits, some 
> affect interoperability and security.
>
>Until these issues are addressed, the document is insufficient to guide a 
> reader into creating a secure and inter-operable implementation.
>
> Unaddressed without any comment or discussion:
>
>> Section 1 says:
>>
>>   While this document updates EAP-TLS [RFC5216], it
>>   remains backwards compatible with it and existing implementations of
>>   EAP-TLS.
>>
>> Other than the abstract, this is the only reference to EAP-TLS 1.3
>> being backwards compatible with older versions of EAP-TLS.  This
>> compatibility is simply asserted, with no further explanation given.
>>
>> Q: What does "backwards compatible" mean?  How is it achieved?
>>
>> Suggestion: add text explaining how it is backwards compatible.  How
>> will EAP-TLS 1.3 implementations negotiate EAP-TLS 1.2?  Perhaps
>> update Section 2.1 with text indicating that TLS version negotiation
>> is handled by the TLS layer, and thus outside of the scope of EAP-TLS.
>> Therefore so long as the underlying TLS implementation correctly
>> implements TLS version negotiation, EAP-TLS will automatically
>> leverage that capability.
The comment here says adding text about "TLS version negotiation". There 
is a comment from you below saying: "I don't understand why it's 
necessary to include discussion of TLS negotiation in EAP, when that 
negotiation does not affect EAP in any way." Am I missing something or 
is there conflicting feedback?
>>
>>
>> Section 2.1.1 says:
>>
>>   TLS 1.3 introduced the Post-Handshake KeyUpdate
>>   message which is not useful and not expected in EAP-TLS.
>>
>> Q: What does it mean that the message is "not expected"?  This seems
>> like a source of implementation-defined behavior, which experience
>> shows has been a source of interoperability and security issues.
>>
>> Suggestion: If there is no use for KeyUpdate messages, then mandate
>> that it SHOULD be ignored, or perhaps connections which use KeyUpdate
>> MUST be closed without updating the keys.  OpenSSL as APIs to
>> determine the status of key updates, so this suggestion is
>> implementable.
>Addressed:
>
>> Section 2.1.3 says this about the session ticket:
>>
>>   ... If the EAP-TLS server
>>   accepts it, then the security context of the new connection is tied
>>   to the original connection and the key derived from the initial
>>   handshake is used to bootstrap the cryptographic state instead of a
>>   full handshake.
>>
>> Nit: This the the only reference to "bootstrap the cryptographic
>> state" in this document.  This text seems like an unnecessary
>> repetition of RFC 8446 Section 2.2.
>>
>> Suggestion: Perhaps say instead
>>
>>   ... If the EAP-TLS server
>>   accepts it, then the resumed session has been deemed to be
>>   authenticated, and securely associated with the prior authentication
>>   or resumption.
>>
>>
>> Section 2.1.4
>>
>>In TLS 1.3 [RFC8446], error alerts are not mandatory to send after a
>>fatal error condition.  Failure to send TLS Error alerts means that
>>the peer or server would have no way of determining what went wrong.
>>EAP-TLS 1.3 strengthen this requirement.
>>
>> NIT: strengthenS this requirement.
> Unaddressed without any comment or discussion:
>
>> Section 2.1.5 is essentially empty.
>>
>> Is there guidance as to when no peer authentication should /
>> should not be used?  Is it possible for an EAP peer to present a
>> client certificate, but have the EAP server ignore it?  What kind of network 
>> access should an EAP peer have if it does not use peer authentication?
>>
>>   Perhaps some of the text from Section 5.6 could be added here.
>>
>> Perhaps suggest that in the normal case, deployments SHOULD use peer
>> authentication.  Also that the "no peer authentication" case be
>> strictly limited in both time, and network access.
>>
>> e.g. The "no peer authentication" situation MUST NOT be used to give
>> normal network access to EAP peers.  Instead, deployments SHOULD
>> provide access which is limited in both time, and in capability.
>> Usually this means a "quarantine" network, or "walled garden", which
>> has only limited capability.
There is text already in the draft which says : "While the EAP server 
SHOULD require peer authentication, this is not mandatory, since there 
are circumstances in which peer authentication will not be needed (e.g., 
emergency services, as described in [UNAUTH]), or where the peer will 
authenticate via some other means.". This is what was said also in RFC 
5216. We also have also have the following text in the draft: "Some 
deployments may permit no peer authentication for some or all 
connections.  When peer authentication is not used, implementations MUST 
take care to limit network access  appropriately for 

Re: [Emu] I-D Action: draft-ietf-emu-eap-tls13-16.txt

2021-06-11 Thread Mohit Sethi M
I have suggested repeatedly that the document contain sufficient information to 
create a secure and inter-operable implementation.  It's not clear to me why 
these suggestions have been ignored, or rejected.

I guess you wanted to say that the document does not? contain sufficient 
information to create a secure and interoperable implementation. I disagree. 
But that doesn't mean your comments will not be addressed. This is after all a 
working group document and should reflect rough consensus. So we will address 
your remaining issues.

 It's not clear to me why these suggestions have been ignored, or rejected.

I find it odd that you claim your suggestions have been ignored or rejected. We 
have created many issues on github  
(https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues?q=is%3Aissue+is%3Aclosed+Alan)
 and submitted many pull requests addressing your comments 
(https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pulls?q=is%3Apr+Alan+is%3Aclosed).

When I merged this PR in the morning: 
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/71, it looked like all 
of your comments had been addressed in the PR. Joe (the other co-chair) had 
approved this PR?

As authors of a working group document of a voluntary standards organization, 
we have been doing voluntary service over the last several years. We started 
working on this document in 2018 
(https://datatracker.ietf.org/doc/html/draft-mattsson-eap-tls13). You have been 
helping us with the document since the beginning. So thank you for your 
voluntary service as well. While it is not mandatory, helping us with github 
issues/PRs related to your reviews can help us ensure that your comments are 
not inadvertently left unaddressed; and that this community effort moves 
forward faster.

--Mohit

On 6/11/21 5:17 PM, Alan DeKok wrote:

On Jun 11, 2021, at 9:56 AM, Mohit Sethi M 
<mailto:mohit.m.se...@ericsson.com> wrote:



I guess you know that there are several implementations of the draft
some of which are already deployed.



   While that's a nice comment telling me what I already know, it doesn't 
address my point.  The fact that implementations exist does not mean that the 
specification is sufficient to create an implementation.

  The implementors have had many "behind the scenes" discussions about how to 
implement EAP-TLS 1.3.   The outcome of those discussions was shared among 
implementors.  That information is largely what enabled inter-operability.  
Information which is not all reflected in the document.

  I have suggested repeatedly that the document contain sufficient information 
to create a secure and inter-operable implementation.  It's not clear to me why 
these suggestions have been ignored, or rejected.



It is of course nice to strive for perfection.



  That comment misrepresents my position.



Could you please submit a pull request addressing your
unaddressed comments.



  I gave suggested text in my messages.  These comments were largely ignored 
across multiple reviews.  This is not how we should work towards consensus.

  If the goal of this document is simply to get it published, then I withdraw 
all of my objections.  Implementors will then share extra knowledge behind the 
scenes.

  If the goal of this document is to enable secure and inter-operable 
implementations, then it would be useful to address comments from major 
implementors.

  Alan DeKok.

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

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


Re: [Emu] I-D Action: draft-ietf-emu-eap-tls13-16.txt

2021-06-11 Thread Mohit Sethi M
I guess you know that there are several implementations of the draft 
some of which are already deployed. It is of course nice to strive for 
perfection. Could you please submit a pull request addressing your 
unaddressed comments.

--Mohit

On 6/11/21 4:39 PM, Alan DeKok wrote:
> On Jun 11, 2021, at 9:08 AM, Mohit Sethi M 
>  wrote:
>> Hi Chair/AD/EMU:
>>
>> We have submitted a new version of draft-ietf-emu-eap-tls13 based on the 
>> extensive feedback from Alan Dekok, Heikki Vatiainen, and Oleg Pekar.
>>
>> Can we somehow prioritize this document and move it forward? The authors 
>> have received several offline emails inquiring about the publication 
>> timeline.
>>
>> Any remaining issues in the current draft can be addressed together with the 
>> comments from the AD review and the IETF last call.
>I have sent a separate message re-iterating my previous detailed review, 
> much of which remains unaddressed.
>
>I suggest that the authors prioritize working towards WG consensus.
>
>Alan DeKok.
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


[Emu] Fwd: I-D Action: draft-ietf-emu-eap-tls13-16.txt

2021-06-11 Thread Mohit Sethi M
Hi Chair/AD/EMU:

We have submitted a new version of draft-ietf-emu-eap-tls13 based on the 
extensive feedback from Alan Dekok, Heikki Vatiainen, and Oleg Pekar.

Can we somehow prioritize this document and move it forward? The authors have 
received several offline emails inquiring about the publication timeline.

Any remaining issues in the current draft can be addressed together with the 
comments from the AD review and the IETF last call.

John and Mohit


 Forwarded Message 
Subject:[Emu] I-D Action: draft-ietf-emu-eap-tls13-16.txt
Date:   Fri, 11 Jun 2021 05:50:55 -0700
From:   internet-dra...@ietf.org
Reply-To:   emu@ietf.org
To: i-d-annou...@ietf.org
CC: emu@ietf.org



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-16.txt
Pages : 35
Date : 2021-06-11

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
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-16

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-16


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 mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


[Emu] Agenda items for EMU @ IETF 111

2021-06-04 Thread Mohit Sethi M
Dear all,

We have a requested a 1 hour session for EMU @ IETF 111. Please send the 
chairs (emu-cha...@ietf.org) requests for presentation slots.

Don't forget to include the title of your presentation, related drafts, 
and the approximate amount of time needed. Even if you don't have all 
the information ready, at least let us know about your intention to 
present. It would let us gauge if a 1 hour session is sufficient.

Joe and Mohit

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


Re: [Emu] Resolving EAP-TLS issues

2021-04-25 Thread Mohit Sethi M
Updates on the actions thus far:

On 3/29/21 12:20 AM, Joseph Salowey wrote:
The authors have been working on the draft-ietf-emu-eap-tls13 in the GitHub 
Repo (https://github.com/emu-wg/draft-ietf-emu-eap-tls13).  Below is a brief 
summary of the Issues and PRs that have recently been merged or ready to be 
merged.  If you are aware of issues that are not currently tracked in the repo 
please add them or let the chairs know.  We are looking to publish a new draft 
in the next few weeks so indicate on the list if there are problems with these 
resolutions.

Thanks,

Joe

PR #44 - Merged - 
Editorial - Clarifies that Message Flows are Examples
PR #50 - Merged - 
Editorial - Moving from Master to Main terminology as in RFC8446bis
PR #51 - Merged - 
Editorial - added text to suggest that one session ticket be sent - Issue 
48
PR #53 - Merged - 
Normative - Uses type code in the context of the key derivation - Issue 
32 - Issue 
56
PR #40 - Ready to 
Merge - Editorial - alignment with EAP State Machine Terminology - Issue 
33 Issue 
36
Merged.
PR #41 - Ready to 
Merge - Editorial - Discussion of packet modification attacks - Issue 
36
Merged.
PR #42 - Ready to 
Merge - Editorial - Reference EAP-Types draft
Merged.
PR #45 - 
Ready to Merge - Editorial - Describes why session resumption is needed - Issue 
34
Merged.
PR #46 - Ready to 
Merge - Normative - Makes it mandatory to send Error Alerts to single EAP 
Failure - Issue 
37 - Issue 
38
Merged.
PR #54 - Ready to 
Merge - Normative - uses protected success indicators as single 0x00 byte of 
application data - Issue 
55
Merged.

Open Issues without proposed Resolution

Issue #52 - Needs 
Discussion and Proposal - Update security considerations with discussion of 
implications no peer authentication

Commit 
(https://github.com/emu-wg/draft-ietf-emu-eap-tls13/commit/c1e648ab9e9f6b44f833689205528f8b53cc7db0)
 with the following text pushed:

   EAP servers will usually require the EAP peer to provide a valid
   certificate and will fail the connection if one is not provided.
   Some deployments may permit no peer authentication for some or all
   connections.  When peer authentication is not used, implementations
   MUST take care to limit network access appropriately for
   unauthenticated peers and implementations MUST use resumption with
   caution to ensure that a resumed session is not granted more
   privilege than was intended for the original session.


Issue #47 - Needs 
DIscussion and proposal - how does the peer validate the identity of the server?

Commit 
(https://github.com/emu-wg/draft-ietf-emu-eap-tls13/commit/d0c3d6f04c97a62ef80002d2f32622b5e8b5fbd6)
 with the following text merged:

  The EAP server identity in the TLS server certificate is typically a
   fully qualified domain name (FQDN).  EAP peer implementations SHOULD
   allow users to configuring a unique trust root (CA certificate) and a
   server name to authenticate the server certificate and match the
   subjectAlternativeName (SAN) extension in the server certificate with
   the configured server name.  In the absence of a user-configured root
   CA certificate, implementations MAY rely on system-wide root CA
   certificate bundles for authenticating the server certificate.  If
   server name matching is not used, then peers may end up trusting
   servers for EAP authentication that are not intended to be EAP
   servers.  If name matching is not used with a public CA bundle, then
   effectively any server can obtain a certificate which will be trusted
   for EAP authentication by the Peer.

   The process of configuring a root CA certificate and a server name 

Re: [Emu] Call with 3GPP on draft-ietf-emu-rfc5448bis

2021-03-18 Thread Mohit Sethi M
The meeting attendees included many 3GPP SA3 participants and several IETF EMU 
working group participants (such as Roman Danyliw, Joe Salowey, and Sean 
Turner). Here are the abridged minutes from the meeting:

Noamen (3GPP SA3 chair): welcomes the meeting.

Vesa Lehtovirta presents the draft, various changes in the different revisions, 
and the current state.

James (NCSC) inquires if directorate reviews have been addressed.

Andreas (Lenovo): Editorial comments on privacy identifiers. Authors will 
address them in the next version.

Lots of discussion from several meeting attendees on how the published RFC will 
be referenced in 3GPP releases 15, 16, and 17. Some questions on the impact of 
the draft on existing implementations. Some clarifications on the relationship 
between old and new RFCs.

No technical issues identified. IETF will continue with the RFC publication 
(once the editorial comments are addressed). 3GPP has several different options 
for updating their own specifications and those discussions will continue in 
SA3.

--Mohit

On 3/16/21 9:57 PM, Mohit Sethi M wrote:

Reminder: Jari mentioned during the EMU session @ IETF 110 about a conference 
call between 3GPP and IETF regarding draft-ietf-emu-rfc5448bis. This call is 
tomorrow Wed, Mar 17, 2021 3:00 PM - 5:00 PM (CET).

Meeting link:
https://www.gotomeet.me/MirkoCano/sa3ietf-conference-call-on-draft-rfc5448bis

I will post the meeting minutes to the EMU mailing list after the meeting.

--Mohit

PS: I have also attached the document discussing this draft and its relation to 
3GPP

On 3/12/21 1:18 PM, Jari Arkko wrote:
And here are the conference call details:

SA3/IETF Conference call on draft-rfc5448bis
Wed, Mar 17, 2021 3:00 PM - 5:00 PM (CET)

Please join my meeting from your computer, tablet or smartphone.
https://www.gotomeet.me/MirkoCano/sa3ietf-conference-call-on-draft-rfc5448bis


New to GoToMeeting? Get the app now and be ready when your first meeting 
starts: https://global.gotomeeting.com/install/573986821

On 8 Mar 2021, at 17.33, Jari Arkko 
mailto:jari.ar...@piuha.net>> wrote:

As mentioned in the meeting today, there will be a call with 3GPP folks around 
the RFC5448bis details on Wednesday the 17th of March 15:00 to 17:00 CET. The 
goal is to ensure that 3GPP does the right thing with regards to their 
specifications and references, as well as make sure the IETF draft and upcoming 
RFC are right. There’s been email discussion but this is an opportunity to see 
“in person” if everything is now ok.

I don’t have a call parameters link yet, but will send it when we get it.

This is what Noamen Ben Henda, chair of 3GPP SA3 (Security) group provided as 
agenda:

What:
   • SA3/IETF Conference call on draft-rfc5448bis
   • Duration is 2 hours on March 17, 15-17 CET
   Scope:
   • draft-rfc5448bis

Deadline:
   • Proposals or input documents to the agenda are to be circulated on the 
reflector latest 24 hours before the opening

Setup:
   • We will use the tag [SA3/IETF][EAP] in the subject line for email 
discussion
   • Please make sure to forward the invitation to your relevant IETF colleagues
   • For the conference call we will use GoToMeeting in combination with TOHRU 
(https://www.3gpp.org/tohru/) for hand raising:
   o Call and meeting session details are to be set up by MCC
   o When editing your details in the tools (GTM and TOHRU), please follow the 
convention: Affiliation - Name

Agenda:
   1. Opening at TBC
   2. Main topics
   - Topic 1 (based on input)
   - Topic 2 (based on input)
   - Etc.
   3. Closing at TBC + 2 h




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




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

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


[Emu] Minutes from EMU @ IETF 110

2021-03-10 Thread Mohit Sethi M
Dear all,

Thank you for participating in the EMU session at IETF 110. And a big 
thank you to Watson Ladd for detailed meeting minutes.

Minutes from the EMU session at IETF 110 have now been uploaded:
https://datatracker.ietf.org/meeting/110/materials/minutes-110-emu-00

Please report any issues by March 20, 2021.

Joe and Mohit

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


[Emu] A big thank you to Watson Ladd

2021-03-08 Thread Mohit Sethi M
I'd like to give a big shout-out to Watson Ladd who took incredibly 
detailed meeting minutes: https://codimd.ietf.org/notes-ietf-110-emu

Juggling between the chat, mic queue, and note taking; he has set an 
extremely high bar for others like me to follow.

--Mohit

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


Re: [Emu] EAP-TLS key derivation resolution

2021-03-01 Thread Mohit Sethi M
FYI: the latest update of wolfSSL (February 16, 2021) now claims to implement 
RFC 5705: Keying Material Exporters for TLS. See: 
https://github.com/wolfSSL/wolfssl/blob/ef916df1b1f9f9678fe7787e3b864a4b015fe569/README.md#wolfssl-release-470-february-16-2021

The TLS 1.3 exporter here: 
https://github.com/wolfSSL/wolfssl/blob/94a23c1d4891b750110c6b806181628bffe782cf/src/tls13.c#L763
 allows context, but the exporter function defined separately for EAP-TLS does 
not allow context: 
https://github.com/wolfSSL/wolfssl/blob/f0ce6ada0fcf99a15b85ddac951e46376df96e4d/src/tls.c#L632.
 Anyhow, my initial concern that some popular TLS libraries don't support 
context may not be valid as implementations are updated. I'll check wolfssl 
more soon.

The reason for moving the Type-Code to the label was also based on Ben and 
Martin's comments. Ben's IESG review for example notes:

Section 2.3

The use of a constant 0x0D (the "Type-Code") as the TLS-Exporter context
is rather unusual; per RFC 8446 this value is intended to be a
"per-association context value provided by the application using the
exporter" per RFC 5705 -- this value is not a per-association value but
rather a global one.

--Mohit

On 2/28/21 12:58 PM, Alan DeKok wrote:




On Feb 27, 2021, at 7:10 PM, Joseph Salowey 
 wrote:

The current draft test specifies the following for key derivation:
   Type-Code  = 0x0D
   MSK= TLS-Exporter("EXPORTER_EAP_TLS_MSK_"+Type-Code,
   "",64)
   EMSK   = TLS-Exporter("EXPORTER_EAP_TLS_EMSK_"+Type-Code,
   "",64)
   Method-Id  = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id_"+Type-Code,
   "",64)
   Session-Id = Type-Code || Method-Id

   A zero-length context (indicated by "") is used in the TLS exporter
   interface.  The EAP-TLS Type-Code of '0D' (in hexadecimal) is
   appended to the label strings.  Other TLS based EAP methods can use
   exporters in a similar fashion by replacing the EAP-TLS Type-Code
   with their own Type-Code (encoded as a hexadecimal string).



  Unless I'm greatly mistaken, the WG already has a draft which updates other 
TLS-based EAP types.  Text about other EAP types does not belong in a document 
which updates EAP-TLS.

  If this document should not give advice about TLS internals, then it should 
not give advice about other TLS methods.

  The text referring to other EAP types should be removed.



The main alternative proposals are to 1) include identity information in the 
context and 2) include the type code in the context instead of the label.
1) has not received support from the working group
2) is a viable alternative, but it really isn't in the spirit of the context.



  RFC 8446 Section 7.5 is entirely silent on the subject of what context is 
for.  It refers instead to RFC 5705, which has this to say in Section 4:

3.  Binding to Application Contexts

   In addition to using an exporter to obtain keying material, an
   application using the keying material has to securely establish the
   upper-layer context where the keying material will be used.  The
   details of this context depend on the application, but it could
   include things such as algorithms and parameters that will be used
   with the keys, identifier(s) for the endpoint(s) who will use the
   keys, identifier(s) for the session(s) where the keys will be used,
   and the lifetime(s) for the context and/or keys.

  The EAP type code is well within the definition of "algorithms and parameters 
that will be used with the keys".  RFC 5705 continues to describe the context 
as:

   o  Information about the upper-layer context can be included in the
  optional data after the exporter label (see Section 4).

  And Section 4 says:

   The context value allows the application using the exporter to mix
   its own data with the TLS PRF for the exporter output.  One example
   of where this might be useful is an authentication setting where the
   client credentials are valid for more than one identity; the context
   value could then be used to mix the expected identity into the keying
   material, thus preventing substitution attacks.

  Using an identity in the context might be useful, except that it is very 
difficult to define which identity is used.  Certificates have multiple fields 
which could be used, not all fields are required, and many fields can have 
multiple values.

  From a practical point of view, it is nearly impossible to include identity 
information in the context in an inter-operable manner.

  It doesn't seem to make sense to leave the context blank, and instead 
shoe-horn more data into the label field.  We have the context, nothing else 
can go there, using the EAP type-code follows RFC 5705, so why not use it?



The proposed resolution is to use the type-code in the label as defined above 
and in draft-14.  Please comment on this thread if you disagree.



  Mixing the type-code in 

Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

2021-02-08 Thread Mohit Sethi M
Bernard:

RFC 4137 says:

   altAccept (boolean)

  Alternate indication of success, as described in 
[RFC3748].

   altReject (boolean)

  Alternate indication of failure, as described in 
[RFC3748].

Is it referring to section 7.16 of RFC 3748:

7.16.  Protected Result Indications

or section 3.4 of RFC 3748:

3.4.  Lower Layer Indications

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


Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

2021-02-07 Thread Mohit Sethi M
Hi all,

I have now read both the papers. I am not sure the attacks in [2] are anymore 
possible:

- The first attack described in section 4.1.1 shows that an EAP-Success leads 
to an unconditional transition to the Authenticated state irrespective of the 
current state. However, I am not sure this is the case anymore as RFC 4137 
(https://tools.ietf.org/html/rfc4137#appendix-A.1) now says :

 |+--
 |  rxSuccess &&  |
 |  (reqId == lastId) &&  |   SUCCESS
 |   (decision != FAIL)   |
 |+--

The peer cannot simply transition to SUCCESS state as the decision is 
initialized to FAIL. The decision is set to COND_SUCC or UNCOND_SUCC only after 
the peer decides that the server has sufficiently been authenticated (for EAP 
methods with mutual authentication).

- The second attack described in section 4.2 relies on the adversary sending a 
disassociate management frame and then uses the MAC address of the 
authenticated supplicant to gain network access. This again should not work as 
a) 802.11w-2009 protects disassociate management frame, and b) EAP-Success is 
followed by 4-way handshake after which there is per packet authenticity and 
integrity (with Key Confirmation Key). The attacker cannot gain network access 
without knowing the PMK (derived from the MSK) and performing the 4-way 
handshake.

The attacks in [1] are not specific to EAP. The attacks relate to Denial of 
Service (DoS) by injecting spoofed alerts in TLS. John has suggested the 
following text for the draft (which I think is sufficient):

Protected TLS Error alerts are protected failure result indications and enables 
the EAP-TLS peer and EAP-TLS server to determine that the failure result was 
not spoofed by an attacker. Protected failure result indications provide 
integrity protection and replay but MAY be unauthenticated. Protected failure 
result does not significantly improve availability as TLS 1.3 treats most 
malformed data as a fatal error.
--Mohit

[1] Extensible Authentication Protocol Vulnerabilities and Improvements : 
https://scholarworks.sjsu.edu/cgi/viewcontent.cgi?article=1431=etd_projects
[2] An Initial Security Analysis of the IEEE 802.1X Standard : 
http://www.cs.cornell.edu/people/egs/615/mishra-arbaugh.pdf

On 2/4/21 2:18 PM, John Mattsson wrote:
Hi Bernard,

I (re-)read the papers you send.

- "Extensible Authentication Protocol Vulnerabilities and Improvements 
Improvements"

  This paper talks attacks on availability by spoofing messages. It looks into 
a small amount of ways where spoofed messages causes the TLS connection to 
fail, especially it focus on alert messages.

  TLS and EAP-TLS is trivial for an on-path attacker to shut down. Basically 
any small error is fatal in TLS. Focusing on alert messages does not seem 
correct. An attacker can e.g. at any time send a small record with length 2^15, 
which causes TLS to terminate the connection. I think the only thing that can 
be achieved without rewriting TLS is that availability attacks does not cause 
long-term damage, i.e. the nodes can retry the handshake.

- "An Initial Security Analysis of the IEEE 802.1X Standard"

  This paper discusses attacks on 801.11. The weaknesses described seems to 
come from 802.11 / EAP interactions.

The discussions around IETF 102 was that the uncertainty (NewSessionTicket or 
not) in TLS 1.3 was "inconvinient" and that it would be convient to get rid of 
the uncertainty. Bernard then pointed out that any message changing the state 
need to be authenticated to that it is not possible to spoof. I think that both 
the application layer commit message as well as close_notify fulfill these old 
requirements.


I think your analysis is correct.

1. What constitutes an "alternative success" indication in the EAP-TLS 1.3 
protocol?

The -13 commitment message verifies that both sides are in possession of a 
derived key. But the server finished already does that. As you state, the -13 
commitment message is not an alternative success indication. I think it would 
be easy to make it an alternative success indication be mandating that the 
EAP-TLS server must only send it after verifying the client finished. I do not 
think defining a new exporter is needed.

The -14 close_notify is also not an alternative success indication and can not 
be made into one either.

If the requirement is that an alternative authenticated success indication is 
needed. Then I think:

- We need to have an extra roundtrip.
- close_notify does not work and cannot be made to work
- Application data commit message could work as an alternative success 
indication. TLS would have to be profiled so the alternative success is only 
send be EAP-TLS server after client finished processed successfully.

2. At what point should keys be pushed down to 

Re: [Emu] General EAP discussion of protected alternate indication of success, RFC 4137, and IEEE 802.1X

2021-02-07 Thread Mohit Sethi M
Hi all,

I am catching up on all the discussion of protected indication of success. I 
think it is important to note that protected indication of success can be 
exchanged in both directions (i.e. peer to server and server to peer). For 
example, RFC 3748 says:

   For example, within EAP-TLS [RFC2716], 
in the client authentication
   handshake, the server authenticates the peer, but does not receive a
   protected indication of whether the peer has authenticated it.  In
   contrast, the peer authenticates the server and is aware of whether
   the server has authenticated it.  In the session resumption
   handshake, the peer authenticates the server, but does not receive a
   protected indication of whether the server has authenticated it.  In
   this mode, the server authenticates the peer and is aware of whether
   the peer has authenticated it.


The discussion thus far has mostly focused on protected indication of success 
from the server to peer. I think in EAP-TLS 1.3 it is useful to have a 
protected indication of success from the server to the peer. Whether this is 
close_notify or one byte of application data can be discussed. The reason for 
having such a protected indication of success from the server to peer is 
because it also indicates that no more post handshake messages will be sent.

But I disagree that such protected indication of success is needed for all EAP 
methods. Note RFC 3748 says:

Result indications improve resilience to loss
   of Success and Failure packets when EAP is run over lower layers
   which do not support retransmission or synchronization of the
   authentication state.  In media such as IEEE 802.11, which provides
   for retransmission, as well as synchronization of authentication
   state via the 4-way handshake defined in 
[IEEE-802.11i], additional
   resilience is typically of marginal benefit.

   Depending on the method and circumstances, result indications can be
   spoofable by an attacker.  A method is said to provide protected
   result indications if it supports result indications, as well as the
   "integrity protection" and "replay protection" claims.  A method
   supporting protected result indications MUST indicate which result
   indications are protected, and which are not.

   Protected result indications are not required to protect against
   rogue authenticators.  Within a mutually authenticating method,
   requiring that the server authenticate to the peer before the peer
   will accept a Success packet prevents an attacker from acting as a
   rogue authenticator.

Also note that spoofing an EAP-Success will still not force the peer to 
transition to the SUCCESS state. As shown in appendix A.1 of RFC 4137:

  rxSuccess &&  |
|  (reqId == lastId) &&  |   SUCCESS
|   (decision != FAIL)

The peer cannot simply transition to SUCCESS state as the decision will still 
be set to FAIL. The decision is set to COND_SUCC or UNCOND_SUCC only after the 
peer decides that the server has sufficiently been authenticated (for EAP 
methods with mutual authentication).

Additionally, the protected indication of success can help with synchronization 
of authentication result as noted in RFC 3748:

   While result indications may enable synchronization of the
   authentication result between the peer and server, this does not
   guarantee that the peer and authenticator will be synchronized

EAP-NOOB even models an attacker which can selectively drop the last message to 
cause a synchronization failure and has a mechanism to recover, see: 
https://tools.ietf.org/html/draft-ietf-emu-eap-noob-03#section-6.7

Finally, as noted in RFC 3748:

   Success indications may be explicit or implicit.

So in some cases, receipt of a message from the server is sufficient to 
indicate that the peer was authenticated.

To summarize, we should have a protected success indication for EAP-TLS but 
there is no reason to panic and modify all other specifications.

--Mohit
On 2/6/21 11:43 AM, John Mattsson wrote:

Hi,

Bernard brought up compability with RFC 4137 and the need for protected 
alternate indication of success in the context of EAP-TLS 1.3

https://mailarchive.ietf.org/arch/msg/emu/F-LcEX3UbAEX20Amk0xBBqfPQNQ/

I think we need to discuss this in a general EAP setting as this in not EAP-TLS 
specific at all but also related to all other EAP methods including 
draft-ietf-emu-rfc5448bis, draft-ietf-emu-aka-pfs, draft-ietf-emu-eap-noob, and 
draft-ingles-eap-edhoc.

The need for anprotected alternate indication of success in IEEE 802.1X is as 
described in [1]

  "lack of per-packet authenticity and integrity in IEEE 802.11 frames (data 
and management) has been a key contributor in many of the protocol's security 
problems."

  "due to a series of flaws in the composition of protocols that make up RSN".

Regarding solutions [1] states

  

Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

2021-01-29 Thread Mohit Sethi M
Hi Ben,

On 1/29/21 8:32 PM, Benjamin Kaduk wrote:

Hi Alan,

I see that the thread is continuing and that perhaps my reply will even
become stale as I write it, but I'm replying to your note instead of the
tip of the thread because it has good context for making some broader
points that I would like to make.

On Sat, Jan 23, 2021 at 05:28:10PM -0500, Alan DeKok wrote:


  We're approaching 2 weeks since the last discussion of this topic.  This 
document has been in development for 3 years.  We desperately need to finish 
it.  IMHO waiting another 6 months is not an option.  Even 3 would be worrying.



My understanding of the discussions involving the TLS WG are that we forked
off into two sub-threads: one about the use of TLS Exporters for key
derivation (the one this is a reply to), that largely concluded with
agreement on a simple change to make, and the other sub-thread about the
protocol element known in -13 as the "commitment message".

With respect to the exporter usage, I do see you had asked about using the
type-code as the exporter context value that Martin didn't see much value
in, but I am willing to accept that as a boon for safety of portability to
other TLS-using EAP mechanisms.  (I do note that the current editor's copy
shows calls to TLS-Exporter() with only two arguments, but three are
required; the construction there also seems to include a propspect for
violation of the requirement that "one label is not a prefix of any other
label" when both regular one-byte and extended type codes are used, but if
the type code is meant to be the context argument I believe that risk goes
away.)

RFC 5705 says:

   If no context is provided, it then computes:

   PRF(SecurityParameters.master_secret, label,
   SecurityParameters.client_random +
   SecurityParameters.server_random
   )[length]

   If context is provided, it computes:

   PRF(SecurityParameters.master_secret, label,
   SecurityParameters.client_random +
   SecurityParameters.server_random +
   context_value_length + context_value
   )[length]


We use only two arguments and say "No context data is used in the TLS exporter 
interface.". We could show the context argument as empty in the calls to make 
things clearer. By the way, this is what is done by TEAP also. RFC 7170 says 
"TEAPv1 makes use of the TLS Keying Material Exporters defined in [RFC5705] to 
derive the session_key_seed.  The label used in the derivation is "EXPORTER: 
teap session key seed".  The length of the session key seed material is 40 
octets.  No context data is used in the export process."

The change of moving the type-code from the context to the label was made based 
on your review (comments from Martin) and the fact that some libraries such as 
wolfssl don't support passing a context (so far). See: 
https://w1.fi/cgit/hostap/tree/src/crypto/tls_wolfssl.c#n1996



With respect to the "commitment message", I thought we had a discussion
that revealed that the mechanism in the -13 could not fulfil its stated
purpose, and that also called into question whether that stated purpose was
actually the right thing that the protocol needed.  My understanding,
therefore, was that the TLS WG could not contribute further insight until
there was a revised proposal from people who understand the needs of the
EAP-TLS protocol from TLS that would both satisfy the needs of EAP and
actually be achievable.



  We have multiple inter-operable implementations which have implemented 
draft-13.  That work over the last few months have resulted in implementors 
making plans to do beta testing in the next few weeks.  Those plans have been 
put on indefinite hold, due to the recent request for changes.

  I understand getting feedback from the TLS WG is useful.  But I would prefer 
to have consensus on a *solution*. Right now, we just have a series of proposed 
changes, with little to no discussion.



I think this is becaues the TLS WG members (in aggregate) do not have a
clear picture of what property or properties EAP-TLS will require from TLS
that led to the need for an additional message when using TLS 1.3 as
opposed to the RFC 5216 case with TLS 1.2.  The prospect of an
"authenticated signal from TLS to EAP-TLS that the authentication completed
successfully" was mentioned, but I did not have the sense that there was
universal agreement of that as the sole relevant property.

I think there was a misunderstanding that an authenticated signal of 
authentication completed was needed. Only a signal of no more post handshake 
messages was needed. I think Alan's summary might also explain the situation 
better.

--Mohit





  We're getting to the point where we have to ship code as promised to 
customers soon (weeks, not months).  We therefore need consensus, as soon as 
possible.

  My preference is to implement draft-13.  We know the code works.  People are 
ready to ship it.  Any 

Re: [Emu] Alissa Cooper's No Objection on draft-ietf-emu-eap-tls13-13: (with COMMENT)

2021-01-08 Thread Mohit Sethi M
Hi Alissa,

Thanks for your review. I think this commit should address your 
comments: 
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/commit/69dab07b0b1c4dbb303e757c7e06ec6f4775e960

I have also explained the changes made in-line.

--Mohit

On 1/6/21 8:15 PM, Alissa Cooper via Datatracker wrote:
> Alissa Cooper 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:
> --
>
> Section 2.1.3:
>
>   “When NAI reuse can be done without privacy implications,
> it is RECOMMENDED to use the same anonymous NAI in the resumption, as
> was used in the original full authentication.  E.g. the NAI @realm
> can safely be reused, while the NAI ZmxleG8=@realm cannot.”
>
> I think it would help to make this recommendation more specific. Does “without
> privacy implications” mean without the username part? Or does it mean 
> something
> else?
>
> Should this text reference RFC 7542 for further context?
The text is now updated to "When NAI reuse can be done without privacy 
implications, it is RECOMMENDED to use the same anonymous NAI in the 
resumption, as was used in the original full authentication [RFC7542].  
For example, the NAI @realm can safely be reused since it does not 
provide any specific information to associate a user's resumption 
attempt with the original full authentication.  However, reusing the NAI 
P2ZIM2F+OEVAO21nNWg2bVpgNnU=@realm can allow a potential attacker to 
associate a resumption attempt with the original full authentication."
>
> Section 5.7:
>
> “Where a good decision is unclear” —> “Where the decision is in doubt” (or
> something like that; it isn’t obvious what a “good” decision is)
The text is now updated to : " If a safe decision is not possible, 
EAP-TLS servers SHOULD reject the resumption and continue with a full 
handshake."
>
>
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

2021-01-08 Thread Mohit Sethi M
Hi Ben,

On 1/7/21 9:21 AM, Benjamin Kaduk wrote:
> On Tue, Jan 05, 2021 at 10:41:50AM -0500, Alan DeKok wrote:
>> On Jan 5, 2021, at 4:47 AM, Mohit Sethi M  wrote:
>>> What I am gathering is that this commitment message should instead be
>>> made into a confirmation message, i.e. it should only be sent after
>>> receiving TLS Finished from the client? This would result in one extra
> I forget if it has been explicitly mentioned in the thread so far, but
> https://tools.ietf.org/html/rfc8446#section-4.4.4 is pretty clear that
> "Servers MAY send data after sending their first flight, but because the
> handshake is not yet complete, they have no assurance of either the peer's
> identity or its liveness (i.e., the ClientHello might have been replayed)."
> In particular, "no assurance of the peer's identity" means that the server
> is at this point sending to an unauthenticated client.  If the goal of
> EAP-TLS is to ascertain that there is in fact an authenticated client, it
> may be ill-advised to send indications of overall success to an
> unauthenticated client.  Part of what Martin alluded to with the situation
> being lousy overall is that there are basically two things that can
> cryptographically confirm that the client has authenticated: successful
> processing of the client Finished, and values derived from the resumption
> master secret.  In "normal" TLS usage the server will bail out if the
> client Finished doesn't validate, so continued receipt of application data,
> including application data bearing application-protocol responses to data
> the client sent in 1-RTT after client Finished, effectively implies that
> the server validated the client Finished, but the EAP-TLS usage is quite
> different from that.  There's not a cryptographic way to tell whether 0x00
> application data was generated before or after the client Finished was
> processed.
Yes, this was discussed. See email from Hannes 
(https://mailarchive.ietf.org/arch/msg/emu/Vf4Zor-xIDVZLQB-BE9mPvlDZMM/) 
where we did look at the text from RFC 8446 about the peer being 
unauthenticated. It was (at that time) accepted since the server was 
only committing to not sending more post-handshake messages (rather than 
indicating successful completion of handshake).
>
>>> round trip to both figure 1 and 3 in the current draft. So we would end
>>> up with the same number of messages as RFC 5216 for full authentication
>>> (https://tools.ietf.org/html/rfc5216#section-2.1.1) and actually do
>>> worse than RFC 5216 (one extra round trip) in case resumption
>>> (https://tools.ietf.org/html/rfc5216#section-2.1.2).
>>That sounds right.
> While counting arrows in the diagram like this is definitely useful, part
> of my concerns related to the need (in non-resumption flows) to convey the
> entire (enlarged) server Certificate chain in individual 1020-byte
> EAP-Requests.  My understanding was that the server had to send a single
> 1020-byte EAP-Request and wait for the corresponding EAP-Response before
> sending the next chunk of the certificate chain.  It was in that scenario
> that I expected a substantial difference between resumption and
> non-resumption.
>
>>> Maybe this is acceptable? The draft anyway notes that "Sending the
>>> Commitment Message in a separate EAP-Request adds an additional
>>> round-trip, but may be necessary in TLS implementations that only
>>> implement a subset of TLS 1.3.". In which case, I am not sure if the
>>> reasons against using close_notify apply anymore.
>>I won't offer opinions on TLS internals, as I'm out of my depth there.
>>
>>As an implementor, the priority is getting TLS alerts (expired cert, 
>> etc.) back from the EAP server to the EAP peer.  Those messages can then be 
>> used to debug deployment issues.
>>
>>The exact method of doing this is less important.  The "0x00" octet works 
>> now, so I'm happy with it.  But if TLS review decides that should change, 
>> that's fine, too.
> It's pretty much guaranteed that we can get the TLS alerts if we always
> wait for client Finished to be processed (whatever signal we end up
> choosing to send after that occurs).  Have we reached agreement on whether
> we should always wait for client Finished?

I hope so. I'll try to submit an update next week.

--Mohit

>
> -Ben
>
> ___
> TLS mailing list
> t...@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

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


Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

2021-01-05 Thread Mohit Sethi M
Hi Alan,

Cleaning up the email. The current draft says the exporter should be called 
once as:

   Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material",
   Type-Code, 128)

and then split the 128 into MSK (64) and EMSK (64). As said, from initial 
glance, it seems the exporter is called twice (once in eap_tls_get_emsk and 
once in eap_tls_getKey). Both the calls are with exactly the same context, 
context length, and labels. In getKey, the EMSK parts are cleared with

os_memset(eapKeyData + EAP_TLS_KEY_LEN, 0, EAP_EMSK_LEN);

while in get_emsk, they are read with

os_memcpy(emsk, eapKeyData + EAP_TLS_KEY_LEN,
  EAP_EMSK_LEN);

Maybe we can live with this. But if exporter is called twice, we should use 
different labels as suggested by Martin?

Regarding the Enc-Recv-Key and Enc-Send-Key, you obviously know more. I was 
thrown off by Joe's comment "The mechanism for splitting the MSK into 
Enc-RECV-Key and Enc-SNED-Key I believe is only used in specific legacy cases 
(WEP, MPPE?)" and the fact that other EAP methods only export MSK. Other EAP 
methods leave it to the AAA architecture for splitting up the MSK. Why should 
EAP-TLS be different?

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


Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

2021-01-05 Thread Mohit Sethi M
Hi Joe,

On 1/5/21 8:44 AM, Joseph Salowey wrote:


On Mon, Jan 4, 2021 at 6:08 AM Alan DeKok 
mailto:al...@deployingradius.com>> wrote:
On Jan 3, 2021, at 10:44 PM, Martin Thomson 
mailto:m...@lowentropy.net>> wrote:
> # Key Schedule
>
> The other thing I observe is the way that this slices up the exporter output. 
>  This was something that old versions of TLS did, but TLS 1.3 did away with.  
> Though RFC 5216 did this, EAP-TLS for TLS 1.3 doesn't need to.  This could - 
> and should - do the same.  All it means is having more exporter labels.

  That's easy enough to change at this state.  The question is what are those 
labels?
  And, we're getting very close to needing an implementation soon.  RFC 8446 is 
over two years old.  Web services have started serious migration to TLS 1.3.  
But we still don't even have a standard for EAP.  I suggest that this is an 
issue.

  At this point, we have inter-operability of TLS 1.3 for EAP-TLS, with the 
major EAP peer / server implementations.  This code is alpha, and not in any 
major release.  But we need to decide fairly soon what we're doing, as testing 
and releases take time.

  The alternative is to dither around for another year or two, all the while 
relying on legacy TLS versions for 802.1X / WiFi authentication.  i.e. packets 
which are trivially monitored by anyone with a WiFi card.

> I appreciate that this uses exporters now rather than abusing the internal 
> PRF.  That's good.  The next step is to dispense with the intermediate values 
> (Key_Material, MSK, EMSK, IV) and all the slicing that occurs and use the TLS 
> exporter for each of the six values that the protocol requires.  I also note 
> that the 0x0D value is used multiple times, unnecessarily, both as a context 
> strong to the exporter and as a prefix to the session ID.

  If EAP-TLS was the only TLS-based EAP method, I would agree with you.  But 
it's not.  Historically, each TLS-based EAP method uses it's own key 
derivations, using method-specific strings.  This practice made implementations 
more difficult and error-prone.

[Joe] It may be worth having separate exporter tags for EMSK and MSK.  
(EXPORTER_EAP_TLS_MSK and EXPORTER_EAP_TLS_EMSK).   I believe current 
applications define the use EAP key material based on the MSK or EMSK.   The 
mechanism for splitting the MSK into Enc-RECV-Key and Enc-SNED-Key I believe is 
only used in specific legacy cases (WEP, MPPE?) and may still be the radius 
attributes used in some deployments, so I don't think we should alter that 
derivation.   I'm not sure where the IV is used, but I don't think splitting it 
up more will be helpful.

This sounds reasonable. I was initially hesitant to change because we have 
working implementations. But after a brief glance at the current hostap 
implementation: 
https://w1.fi/cgit/hostap/tree/src/eap_server/eap_server_tls.c#n356; I am 
convinced that using separate labels for MSK and EMSK is better. The current 
implementation seems incorrect.

About the IV: RFC 5247 (published after RFC 5216) says the following 
(https://tools.ietf.org/html/rfc5247#section-1.2):

As a result, its use has been deprecated and it is
  OPTIONAL for EAP methods to generate it.  However, when it is
  generated, it MUST be unpredictable.

Should we still export it in EAP-TLS with TLS 1.3?

And the same question for Enc-SEND-Key and Enc-RECV-Key. They are defined in 
RFC 2548: https://tools.ietf.org/html/rfc2548, but not exported or used in 
hostap/freeradius implementations. It could be that they are still used by 
Microsoft but I am unsure?

--Mohit




  The use of 0x0D is to allow standard key derivations across TLS-based EAP 
methods.  The other methods replaced the 0x0D byte with their own EAP type 
value.  This practice greatly simplifies implementations.

  See https://tools.ietf.org/html/draft-dekok-emu-tls-eap-types-00 for more 
information.

  Alan DeKok.

___
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 mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

2021-01-05 Thread Mohit Sethi M
Hi again,

The following issues are related but not exactly the same:
1. indication from the server that the handshake is complete and it is 
okay to tear down the tunnel
2. indication from the server that no more post-handshake messages 
(containing NewSessionTicket or something else) will be sent.

We can't rely on EAP-Success as an indication of either since that 
message is never delivered to EAP-TLS and it maybe lost or spoofed. 
Ben's discuss arises from 2 and not 1. More at the end of the email.

On 1/5/21 7:26 AM, Benjamin Kaduk wrote:
> Hi Martin,
>
> Thanks for chiming in here; your insight has been quite helpful already.
> (I am going to reply to the thread in reverse order so as to not duplicate
> what you've already said.)
>
> On Tue, Jan 05, 2021 at 02:50:15PM +1100, Martin Thomson wrote:
>> Hi Alan,
>>
>> On Tue, Jan 5, 2021, at 14:05, Alan DeKok wrote:
>>> On Jan 4, 2021, at 6:26 PM, Martin Thomson  wrote:
 Your point about reliability is confusing.  I've read Section 4.2 of RFC 
 3748 and while it says "A peer MUST allow for this circumstance as 
 described in this note.", I see no explanation of how to concretely make 
 that allowance.  Are you saying that EAP methods don't really use 
 EAP-Success and condition their behaviour on other signals?
>>>EAP-Success by itself is *not* a reliable indication of Success.  See
>>> RFC 3748 Section 4.2:
>>>
>>> Success and Failure packets MUST NOT be sent by an EAP authenticator
>>> if the specification of the given method does not explicitly permit
>>> the method to finish at that point.
>> This is fine.  What you might be concerned about is the nature of the 
>> signals that the EAP authenticator is receiving from TLS.  What you had in 
>> the case of TLS 1.2 was the stack providing bytes to send (which were to go 
>> in EAP-Request) and then, after everything is done, a positive signal saying 
>> that the handshake was complete and satisfactory.  That latter signal is the 
>> important one.
> Yes.  Part of what had me so unhappy about this document is that the
> Commitment Message is discussed only as a "promise to not send more
> handshake messages", not "an indication that the handshake is complete and
> the TLS layer is happy".  (Furthermore, what Alan writes below about
> "cannot distinguish a "finished authentication" EAP-Success from a
> "spoofed" EAP-Success" really needs to make its way into the document.)
>
>> TLS 1.3 muddies things by allowing bytes to be sent *after* the 
>> complete+satisfactory signal from TLS.  That's what you are grappling with 
>> here.  What I'm suggesting is that you don't rely on looking at what bytes 
>> hit the wire, but wait until two conditions are complete:
>>
>> 1. The TLS stack says that it is content: the handshake is complete and it 
>> is OK with whatever the other side has provided.
>> 2. The TLS stack has no more bytes to send.
>>
>> The latter is likely where the confusion comes from, but if the stack 
>> doesn't produce bytes when you give it bytes, then you don't need to keep 
>> waiting.  For what you depend on, that's enough.
> I agree that this is probably good enough.  There may be some complications
> depending on how badly the availability of session resumption is desired (I
> know OpenSSL provides an API to let the application requst a new session
> ticket regardless of whether any were sent with the initial handshake -- I
> wrote it -- though I need to tweak it so that it will not always wait for
> application data to send before sending the ticket), but I believe this
> provides the key functionality.
>
>> The mistake with sending application data is that there is no obligation on 
>> the part of the TLS stack to order its sending of NewSessionTicket relative 
>> to the application data.  Nor is is possible for you to correctly 
>> distinguish TLS data that contains your Confirmation Message from a record 
>> that just contains a little bit of a session ticket.  But you don't need to 
>> worry about that.
>>
>> An example might help illustrate:
>>
>> 1. ... many steps occur
>> 2. Client sends EAP-Response ending in a TLS Finished.
>> 3. Server reads that message, processes it and determines that the handshake 
>> is complete and acceptable (e.g., checks the client certificate against its 
>> policy).
>> 4. As the server is happy, it writes the Confirmation Message to TLS.
>> 5. Server asks TLS stack for outstanding data to write; TLS stack provides a 
>> bunch of application_data records.
> (In particular, this is the TLSCiphext content type that is
> "application_data", and the inner content type could be handshake or
> application data.  The application doesn't have visibility into it.)
>
>> 6. Server writes TLS records into an EAP-Request and sends it.
>> 7. Client receives this and sends an empty EAP-Response.
>> 8. Server sends EAP-Success.
>>
>> This is, I assume what you intend here, with a little more detail around 
>> steps 3-5.  But what 

Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

2021-01-04 Thread Mohit Sethi M
Top posting to explain the need for a reliable notification of protocol 
completion:

On 1/4/21 5:44 AM, Martin Thomson wrote:

 I have a much simpler one: the EAP layer has a signal that the protocol is 
complete: EAP-Success

Alan Dekok explained in a separate email thread why this is not the case 
(https://mailarchive.ietf.org/arch/msg/emu/uMNKV_vfov7ASob6_Qu3FlCNcT0/). He 
wrote: "The EAP-Success and EAP-Failure messages are *not* protected.  i.e. 
they are 4-bytes of data which can be spoofed rather trivially.".

There are two more quirks as to why EAP-Success cannot be used as an indication 
of protocol completion:

a) Section 2.2 of RFC 3748 says https://tools.ietf.org/html/rfc3748#section-2.2:

   EAP packets with Codes of Success or Failure do not include a Type
   field, and are not delivered to an EAP method.

What this means is that the EAP-Success is delivered to EAP (the framework) and 
not to EAP-TLS (the authentication method/protocol). Thus, EAP methods cannot 
rely on EAP-Success or EAP-Failure as an indication of anything since they 
never receive that message.

b) Section 3.1 (https://tools.ietf.org/html/rfc3748#section-3.1)  and 4.2 
(https://tools.ietf.org/html/rfc3748#section-4.2) of RFC 3748 says:

   Note that EAP Success and Failure packets are not retransmitted.
   Without a reliable lower layer, and with a non-negligible error rate,
   these packets can be lost


   Implementation Note: Because the Success and Failure packets are not
   acknowledged, they are not retransmitted by the authenticator, and
   may be potentially lost.  A peer MUST allow for this circumstance as
   described in this note.

The knee-jerk reaction would be that EAP is bad and it should be fixed/updated. 
I have myself wondered if we can add some payload to the EAP-Success message. 
But EAP has been around for over a decade now and is used in many networks so 
the threshold for change is naturally high.

I also think that this should not be treated as an issue for EAP-TLS only. I 
can imagine other deployments which use TLS for making authorization decisions 
but do not use the TLS for sending message. So I am glad that Ben has brought 
this to the TLS working group for further discussion. Whether we use this 
1-byte of application data (as done in this draft) or some other mechanism 
(such as close_notify), we need a reliable way of telling that no further post 
handshake messages will be sent.

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


Re: [Emu] Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

2021-01-01 Thread Mohit Sethi M
Hi Ben,

Thanks for the usual detailed feedback. I haven't yet addressed all the 
comments in your COMMENT section. Below, I copy the comments which have 
now been addressed in github: 
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/commit/901a28578c65b8b483eecf6394cfc218b3d02f2b

> Using BCP195 as the slug is probably preferred, since any RFCs
> associated with the BCP are going to be relevant and topical
Done! I think. Not sure if this is the right way to do it : BCP 195?

> Section 5.9
>
> Pervasive monitoring refers to widespread surveillance of users.  In
> the context EAP-TLS, pervasive monitoring attacks can target EAP-TLS
>
> nit: "context of"
Fixed. Also reported by Erik Kline!

> static RSA based cipher suites without privacy.  This implies that an
> EAP-TLS peer SHOULD NOT continue the handshake if a TLS 1.2 EAP-TLS
> server responds to an empty certificate message with a TLS alert
> message.
>
> Just to check my understanding, this "response" would be an EAP-TLS
> response containing a new ClientHello (that would proceed to do a
> handshake including the client certificate in the unprotected initial
> handshake)?  That is, it would be a response at the EAP layer but not at
> the TLS layer.
In EAP, servers send EAP-Request and peer send EAP-Response. I changed 
the text somewhat. It now reads "Therefore, it is RECOMMENDED for 
EAP-TLS peers to not use EAP-TLS with TLS 1.2 and static RSA based 
cipher suites without privacy. This implies that an EAP-TLS peer SHOULD 
NOT continue the handshake if a TLS 1.2 EAP-TLS server sends an 
EAP-TLS/Request with a TLS alert message in response to an empty 
certificate message from the peer." Other suggestions to improve are 
welcome.

>   and only using the pseudo-random usernames a single time.  Note that
> the privacy-friendly usernames also MUST NOT include substrings that
> can be used to relate the identity to a specific user.  Similarly,
> privacy-friendly username SHOULD NOT be formed by a fixed mapping
> that stays the same across multiple different authentications.
>
> I think that violating the SHOULD NOT would intrinsically violate the
> preceding MUST NOT ... so should they both be MUST NOTs
Changed to MUST NOT.

> Section 5.8
>
> Tracking of users by eavesdropping on identity responses or
> certificates is a well-known problem in many EAP methods.  When EAP-
> TLS is used with TLS 1.3, all certificates are encrypted, and the
> username part of the identity response is always confidentiality
> protected (e.g. using anonymous NAIs).  [...]
>
> As written this applies to server certificates as well as TLS client
> certificates.  For which the statement is technically true, but with the
> caveat that it is typically easy to persuade the server to (re-)send
> those same certificates encrypted to a key known to the attacker, so the
> protection provided by the encryption is limited.  (The server has been
> fairly strongly authenticated by the time the EAP peer makes the
> decision to send its certificate, so there the reverse situation is
> different.)
Added a sentence to note this: "When EAP-TLS is used with TLS 1.3, all 
certificates are encrypted, and the username part of the identity 
response is always confidentiality protected (e.g., using anonymous 
NAIs). Note that even though all certificates are encrypted, the 
server's identity is only protected against passive attackers while 
client's identity is protected against both passive and active 
attackers. As with other EAP methods, even when privacy-friendly 
identifiers or EAP tunneling is used, the domain name (i.e., the realm) 
in the NAI is still typically visible."

> Section 4.2.11, 8.1, and 8.2 of [RFC8446] provides security
> considerations for resumption.
>
> I'm curious why specifically § 8.1 and 8.2 were selected, given that §8
> as a whole is about "0-RTT and Anti-Replay", which is a more specific
> topic than just resumption.
Updated to section 2.2 and 4.2.11 of RFC 8446.

> Where a good decision is unclear, EAP-TLS servers SHOULD reject the
> resumption.
>
> I suggest "reject the assumption and continue with a full handshake".
Makes sense. Done!

> If any authorization, accounting, or policy decisions were made with
> information that have changed between the initial full handshake and
> resumption, and if change may lead to a different decision, such
> decisions MUST be reevaluated.  It is RECOMMENDED that authorization,
> accounting, and policy decisions are reevaluated based on the
> information given in the resumption.  [...]
>
> I'm not sure I understand how these two sentences fit together.  Is it
> trying to say that "if there could be a different decision, you
> definitly have to re-check, and we recommend just always re-checking
> since that's timpler"?
Yes.

> Section 5.7
>
> and the authorizations of the other party may have been reduced.  If
> the cached 

Re: [Emu] Erik Kline's No Objection on draft-ietf-emu-eap-tls13-13: (with COMMENT)

2021-01-01 Thread Mohit Sethi M
Hi Erik,

Thanks. These are now fixed in github: 
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/commit/094aacf6826e1edaa4dc102acd683011311aa548

--Mohit

PS: Happy New Year 2021 to colleagues in EMU and IESG!

On 12/31/20 8:11 AM, Erik Kline via Datatracker wrote:
> Erik Kline 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:
> --
>
> [[ nits ]]
>
> [ section 1 ]
>
> * s/and and/and/
>
> [ section 2.1.7 ]
>
> * "Many client certificates contains" -> "Many client certificates contain"
>
> [ section 5.4 ]
>
> * s/EAP--TLS/EAP-TLS/
>
> [ section 5.9 ]
>
> * "In the context EAP-TLS" -> "In the context of EAP-TLS"?
>
>
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


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

2020-12-16 Thread Mohit Sethi M
Hi Éric,

Thank you for your review. Answers in-line:

On 12/10/20 4:13 PM, Éric Vyncke via Datatracker wrote:
> É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?
Good point. I have updated the draft in github: 
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/commit/baaf9a03c5f282e9904da60700687e248bebe28c
>
> -- Section 1 --
> Should "ietf-tls-oldversions-deprecate" be normative ?
I believe that informational is the correct choice. We are only 
informing readers and implementers of this draft that old versions of 
TLS (1.0 and 1.1) are being deprecated. They don't strictly need that 
information for implementing EAP-TLS with TLS 1.3. However, I don't have 
strong opinions and can reconsider.
>
> -- Section 2 --
> Nicely done to have kept the same sub-section numbers with respect to RFC 
> 5216.
> Kudos !
Thank you for the positive feedback.
>
> -- 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 ?
You have a valid point. However, since this document updates and not 
obsoletes RFC 5216, we found it sub-optimal to repeat the text. We have 
written this document for a developer who already has an EAP-TLS 
implementation and wants to update it for use with TLS 1.3. Thankfully, 
large parts of the update complexity are actually handled by the 
underlying TLS library leaving only a small amount of change needed from 
an EAP-TLS developer.
>
> -- 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 ;-)

Good point. I think I have added a comma after all instances now: 
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/commit/7cbce9b8c3ad05a6406a8c48d5b1cbefe23faf47

--Mohit

>
>
>
> ___
> 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


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

2020-12-04 Thread Mohit Sethi M
Hi ACE,

I guess EMU is happy to see new deployments and uses of EAP. I think ACE is 
better suited for taking on this work if there is interest. EMU primarily deals 
with the base EAP protocol and various EAP authentication methods. We can 
obviously help with reviewing the document later on.

I would note that EAP-over-foo is generally defined by the lower-layer. So for 
example, EAP over LAN (EAPOL) is specified by IEEE. In this case, the 
lower-layer is CoAP so we at the IETF are responsible for specifying it (if 
there is a desire to do so). A draft for HTTP authentication with EAP was 
submitted a couple of decades ago: 
https://tools.ietf.org/html/draft-torvinen-http-eap-01. That was unfortunately 
never finished. But maybe CoAP will be different and ACE can finish this work 
item if it chooses to adopt it.


--Mohit

On 12/3/20 3:20 PM, Daniel Migault wrote:
CCing emu, core

It seems ACE to me that ACE could be home for such a document. I am wondering 
if emu core or any other WG believe there is a better place for it.

Regarding ACE I am wondering what is the WG opinion about adding this item to 
the ACE charter.

Yours,
Daniel

From: Ace  on behalf of Dan 
Garcia 
Sent: Thursday, December 3, 2020 6:10 AM
To: a...@ietf.org 
Subject: [Ace] Proposed charter for ACE (EAP over CoAP?)


Dear all:

Regarding the new charter, since ACE is considering the definition of CoAP 
transport for CMPv2 
(https://tools.ietf.org/html/draft-msahni-ace-cmpv2-coap-transport-00), we were 
wondering whethere it could also consider specifying EAP (Extensible 
Authentication Protocol) over CoAP.

In this sense, we proposed this some time ago and we have implementations about 
this.

https://datatracker.ietf.org/doc/html/draft-marin-ace-wg-coap-eap-06
https://www.mdpi.com/1424-8220/16/3/358
https://www.mdpi.com/1424-8220/17/11/2646

The usage of CoAP can provide a very light and link-layer independent (we even 
tested in LoRa networks) EAP lower-layer (transport for EAP) suitable for IoT 
enviroment. We believe this would be really useful since EAP provides 
flexibility for the authentication and it is a well-known protocol.

Therefore, we would like to propose the following modification to the charter:

"The Working Group will examine how to use Constrained Application Protocol 
(CoAP) as a transport medium for certificate enrollment protocols, such as EST 
and CMPv2, as well as a transport for authentication protocols such as EAP, and 
standardize them as needed."

This modification does not necessarily mean the adoption of our draft. After 
all, we completely understand that this would happen only if there is an 
interest in the WG. Nevertheless, we would like to avoid that the charter is a 
barrier later if there is interest in the WG to work in this transport of EAP 
over CoAP:

Any opinion about this?

Best Regards.

El 18/11/2020 a las 8:08, Daniel Migault escribió:
Hi,

Please find the proposed charter we agreed on during the interim meeting. If 
you would like to propose any change, please use the following URL by November 
25:

https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY/edit?usp=sharing

Yours,
Daniel


The Authentication and Authorization for Constrained Environments (ace) WG has 
defined a standardized solution framework for authentication and authorization 
to enable authorized access to resources identified by a URI and hosted on a 
resource server in constrained environments.

The access to the resource is mediated by an authorization server, which is not 
considered to be constrained.


Profiles of this framework for application to security protocols commonly used 
in constrained environments, including CoAP+DTLS and CoAP+OSCORE, have also 
been standardized.  The Working Group is charged with maintenance of the 
framework and existing profiles thereof, and may undertake work to specify 
profiles of the framework for additional secure communications protocols and 
for additional support services providing authorized access to crypto keys 
(that are not necessarily limited to constrained endpoints, though the focus 
remains on deployment in ecosystems with a substantial portion of constrained 
devices).


In addition to the ongoing maintenance work, the Working Group will extend the 
framework as needed for applicability to group communications, with initial 
focus on (D)TLS and (Group) OSCORE as the underlying group communication 
security protocols. The Working Group will standardize procedures for 
requesting and distributing group keying material using the ACE framework as 
well as appropriated 

[Emu] Minutes from EMU @ IETF109

2020-11-22 Thread Mohit Sethi M
Dear all,

Thank you for participating in the EMU session at IETF 109. A special 
thank you to our AD Roman and others for taking notes.

Minutes from the EMU session at IETF 109 have now been uploaded:
https://datatracker.ietf.org/meeting/109/materials/minutes-109-emu-00.md

Please report any issues by November 30, 2020.

Joe and Mohit

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


Re: [Emu] I-D Action: draft-ietf-emu-eaptlscert-07.txt

2020-11-20 Thread Mohit Sethi M
Hi John,

On 11/20/20 7:33 AM, John Mattsson wrote:
> Looking at the references in the document:
>
> "Suppressing Intermediate Certificates in TLS" has not been updated since 
> March 2019. It looks like the TLS working group is not working on this 
> extension. We should maybe ask Martin, if he is planning to drive this in the 
> future, or if it has been replaced by something else.
> https://tools.ietf.org/html/draft-thomson-tls-sic-00
Since this is a non-blocking informational reference, I prefer having it 
in the document (among the list of many other techniques to avoid large 
messages).
>
>
> "CBOR Certificate Algorithm for TLS Certificate Compression" has been 
> replaced by "CBOR Encoding of X.509 Certificates (CBOR Certificates)". This 
> draft does now register a new TLS certificate type instead of a certificate 
> compression. It will be brought up (list or presentation) in the TLS working 
> group when COSE has approved its new charter and adopted the draft.
> https://tools.ietf.org/html/draft-mattsson-tls-cbor-cert-compress-00
> https://datatracker.ietf.org/doc/draft-mattsson-cose-cbor-cert-compress/

I have updated the reference and slightly altered the corresponding text 
in version (-08): 
https://www.ietf.org/archive/id/draft-ietf-emu-eaptlscert-08.txt.

I believe we are now ready to ship this to the RFC editor.

--Mohit

>
> Cheers,
> John
>
>
>
> ___
> 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


Re: [Emu] I-D Action: draft-ietf-emu-eap-tls13-12.txt

2020-11-09 Thread Mohit Sethi M
Hi Hannes,

In short: yes. At least I have encountered similar processes in the TLS 
working group (i.e., authors opening and closing issues based on mailing 
list reviews). We are sorry if you are not happy with the current 
processes. We are of course at your service. How would you like us to 
change? Do you have some better experience from other working groups? 
Perhaps you could consider writing a draft on github issue tracking best 
practices for the IETF? RFC 8875 currently doesn't mandate any specific 
policy for issue tracking: https://tools.ietf.org/html/rfc8875

We had opened issues mostly as an aid for us to keep track of the 
feedback received on the mailing list. Anyone is free to create new 
issues for various drafts that belong to this working group. For 
example, Alan Dekok opened an issue: 
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues/11 which was 
closed by John (one of the authors) after addressing the issue. You can 
obviously comment on a closed issue if you feel it is not adequately 
addressed or alternatively open a new issue.

Also, while most of the drafts from this working group are available in 
github, the EMU working group has also recently published RFC 8940 
(https://tools.ietf.org/html/rfc8940) which was not edited on github. At 
least so far EMU has chosen not to be too process oriented.

Anyhow, I hope we can make progress on draft-ietf-emu-eap-tls13.

--Mohit

On 11/9/20 3:11 PM, Hannes Tschofenig wrote:
> Hi Mohit,
>
> I am not quite sure how the process for Github issues works in this group. It 
> seems that you create the issues based on reviews, then you address them 
> yourself in the draft and you then close the issue yourself.
> Is this how it works?
>
> Ciao
> Hannes
>
>
> -Original Message-----
> From: Emu  On Behalf Of Mohit Sethi M
> Sent: Monday, November 9, 2020 2:08 PM
> To: emu@ietf.org
> Subject: Re: [Emu] I-D Action: draft-ietf-emu-eap-tls13-12.txt
>
> Dear all,
>
> We had submitted a new version before the deadline. This version should 
> address most of the comments received during the last call. Here is the diff 
> for your convenience:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-12.
>
> In particular:
>
> - we have removed some of text in the section on HRR and preventing 
> fragmentation that was repeated from RFC8446 and
> draft-ietf-emu-eaptlscert:
> https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues/15
>
> - we have tried to make the usage of EAP-TLS peer vs. EAP peer vs.
> EAP-TLS client more consistent. Note that RFC5216 had used a mixture of these 
> terms interchangeably. The terminology section now also says "The term 
> EAP-TLS peer is used for the entity acting as EAP peer and TLS client.  The 
> term EAP-TLS server is used for the entity acting as EAP server and TLS 
> server.".
>
> - we have now clarified the discrepancy between the "Commitment Message"
> sending one byte of encrypted application data vs. the statement "EAP-TLS 
> does not protect any application data" in Section 2.4.
>
> - we have updated the text on revocation checking based on the recent 
> discussion.
>
> Let us know if there are some issues that still need to be addressed.
>
> John and Mohit
>
> On 11/3/20 12:26 AM, internet-dra...@ietf.org wrote:
>> 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
>>   Authors : John Preuß Mattsson
>> Mohit Sethi
>> Filename: draft-ietf-emu-eap-tls13-12.txt
>> Pages   : 30
>> Date: 2020-11-02
>>
>> Abstract:
>>  This document specifies the use of 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 further improves security and privacy by mandating use
>>  of privacy and revocation checking.  This document also provides
>>  guidance on 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 are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-12
>> https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-tls13-

Re: [Emu] I-D Action: draft-ietf-emu-eap-tls13-12.txt

2020-11-09 Thread Mohit Sethi M
Dear all,

We had submitted a new version before the deadline. This version should 
address most of the comments received during the last call. Here is the 
diff for your convenience: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-12.

In particular:

- we have removed some of text in the section on HRR and preventing 
fragmentation that was repeated from RFC8446 and 
draft-ietf-emu-eaptlscert: 
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues/15

- we have tried to make the usage of EAP-TLS peer vs. EAP peer vs. 
EAP-TLS client more consistent. Note that RFC5216 had used a mixture of 
these terms interchangeably. The terminology section now also says "The 
term EAP-TLS peer is used for the entity acting as EAP peer and TLS 
client.  The term EAP-TLS server is used for the entity acting as EAP 
server and TLS server.".

- we have now clarified the discrepancy between the "Commitment Message" 
sending one byte of encrypted application data vs. the statement 
"EAP-TLS does not protect any application data" in Section 2.4.

- we have updated the text on revocation checking based on the recent 
discussion.

Let us know if there are some issues that still need to be addressed.

John and Mohit

On 11/3/20 12:26 AM, internet-dra...@ietf.org wrote:
> 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
>  Authors : John Preuß Mattsson
>Mohit Sethi
>   Filename: draft-ietf-emu-eap-tls13-12.txt
>   Pages   : 30
>   Date: 2020-11-02
>
> Abstract:
> This document specifies the use of 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 further improves security and privacy by mandating use
> of privacy and revocation checking.  This document also provides
> guidance on 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 are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-12
> https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-tls13-12
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-12
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> 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 mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Benjamin Kaduk's Yes on draft-ietf-emu-eaptlscert-06: (with COMMENT)

2020-11-04 Thread Mohit Sethi M
Hi Ben,

This should hopefully address your feedback: 
https://github.com/emu-wg/eaptls-longcert/commit/d39c1411c908844cc74bc0a6fa689a73ecd5b7a8

Answers in-line.

--Mohit

On 11/4/20 9:04 AM, Benjamin Kaduk via Datatracker wrote:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-emu-eaptlscert-06: Yes
>
> 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-eaptlscert/
>
>
>
> --
> COMMENT:
> --
>
> Thank you for responding to the secdir review and thanks to Stefan
> Santesson for the review -- the changes staged in github are a
> significant improvement!
>
> Though I am balloting Yes, please see my remarks about
> draft-thomson-tls-sic in the comments on Section 4.2.5 -- it is expired
> and was not adopted by the TLS WG and we should not imply that it is a
> current work item there.
>
> I also made a pull request at
> https://github.com/emu-wg/eaptls-longcert/pull/4 with a few editorial
> fixes/suggestions.
>
> Section 3
>
> o  Multiple user groups in the certificate.
>
> What are "user groups" in a certificate?
The text now says: It can contain multiple organization fields to 
reflect the multiple group memberships of a user (in a client certificate).
>
> A certificate chain (called a certification path in [RFC5280]) can
> commonly have 2 - 6 intermediate certificates between the end-entity
> certificate and the trust anchor.
>
> The '2' here is surprising to me; my understanding was that having just
> 1 intermediate was quite common, especially on the web.
Added that certificate chains in 'EAP-TLS' can have 2-6 intermediate 
certificates.
>
> Many access point implementations drop EAP sessions that do not
> complete within 50 round-trips.  This means that if the chain is
>
> Earlier we said "40 - 50"; we should probably be consistent about it.
Fixed.
>
> Section 4.1
>
> 1.3 [RFC8446] requires implementations to support ECC.  New cipher
> suites that use ECC are also specified for TLS 1.2 [RFC5289].  Using
>
> nit: RFC 8422 might be a better reference than 5289, here.
Updated.
>
> Section 4.1.3
>
> The EAP peer certificate chain does not have to mirror the
> organizational hierarchy.  For successful EAP-TLS authentication,
> certificate chains SHOULD NOT contain more than 2-4 intermediate
> certificates.
>
> This seems equivalent to the shorter "SHOULD NOT contain more than 4
> intermediate certificates".
Changed to 4.
>
> Section 4.2
>
> by updating the underlying TLS or EAP-TLS implementation.  Note that
> in many cases the new feature may already be implemented in the
> underlying library and simply needs to be taken into use.
>
> Hmm, "many" might be a stretch, given that the majority of the
> mechanisms we refer to are still at the internet-draft stage.
Changed to "some"
>
> Section 4.2.2
>
> possible.  An option in such a scenario would be to cache validated
> certificate chains even if the EAP-TLS exchange fails, but this is
> currently not allowed according to [RFC7924].
>
> This is arguably not a strict requirement in 7924; the text in question
> looks to be:
>
> % Clients MUST ensure that they only cache information from legitimate
> % sources.  For example, when the client populates the cache from a TLS
> % exchange, then it must only cache information after the successful
> % completion of a TLS exchange to ensure that an attacker does not
> % inject incorrect information into the cache.  Failure to do so allows
> % for man-in-the-middle attacks.
>
> The normative MUST is for "legitimate sources", and "only after
> successful TLS exchange" uses the lowercase MUST.  Of course, 7924
> predates 8174, so it's not fully clear-cut, but there may be some ground
> to stand on for caching validated certificate chains prior to a
> completed TLS handshake (provided that other validation is performed
> properly).
Updated text says " An option in such a scenario would be to cache 
validated certificate chains even if the EAP-TLS exchange fails, but 
such caching is currently not specified in [RFC7924]."
>
> Section 4.2.4
>
> "known certificates".  Thus, cTLS can provide another mechanism for
> EAP-TLS deployments to reduce the size of messages and avoid
> excessive fragmentation.
>
> cTLS is at a fairly early stage; it might be better to say "could
> provide" rather than "can provide".
Changed to "could provide".
>
> Section 4.2.5
>
> handshake increases the size of the 

Re: [Emu] Agenda Items for virtual IETF 109

2020-11-03 Thread Mohit Sethi M
I think our slot is scheduled for 05:00 - 07:00 UTC. The times shown on the 
agenda: https://datatracker.ietf.org/meeting/109/agenda are in UTC + 7.

--Mohit

On 11/4/20 7:33 AM, Joseph Salowey wrote:

At the virtual IETF 100 meeting, we will have a 2 hour session on
Friday, November 20, between 12:00 - 14:00 UTC.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] draft-ietf-emu-eap-tls13-11: Updates RFC 5216

2020-11-02 Thread Mohit Sethi M
Hi Hannes,

Thanks. I like the friendly banter. I could probably find the commit which says 
"SHOULD mitigate known attacks" and blame it on John. I will change it to MUST. 
:)

I have opened an issue to explain the relationship to RFC 7525: 
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues/16.

Please be rest assured that I don't get any money for publishing RFCs. Let 
alone any extra payment based on the number of pages.

I did not write the code for session resumption but (together with my 
colleague) we have tested wpa_supplicant and freeRadius EAP-TLS resumption and 
it works. As said, Alan wanted the text. Here is one of the long discussion 
threads on this issue: 
https://mailarchive.ietf.org/arch/browse/emu/?q=Notes%20on%20session%20resumption%20with%20TLS-based%20EAP%20methods

Let's wait and see what he has to say. We are happy to update once there is 
some consensus on how much of the text should stay.

--Mohit

On 11/2/20 11:37 AM, Hannes Tschofenig wrote:
Hi Mohit,

I have now read the email from Terry and he is not suggesting the original 
text. He is, in fact, correcting misleading text in your draft.

IMHO the entire text in Section 5.7 reads a bit like you are giving 
implementation guidance. That would be great if John or you had written such 
code. I don’t know whether you have.
You are given the reader the impression that there is a problem with session 
resumption. I don’t believe there is a problem and I gave you reasons in my 
email.

On the second topic. Here is my remark about the wrong reference and my 
suggestion to address it:

Section 5.10 says:
"
EAP-TLS implementations
   SHOULD mitigate known attacks and follow the recommendations in
   [RFC7525] and [I-D.ietf-tls-oldversions-deprecate].
"

Interestingly, RFC 7525 does not talk about EAP (and instead focuses on 
applications like  HTTP, SMTP, IMAP, POP, SIP, and XMPP, as noted in the 
abstract). RFC 7525, for example, does not mandate OCSP. It also recommends 
RSA, which draft-ietf-emu-eaptlscert and this draft does not do. There seems to 
be contradiction here.

At a minimum, I would clarify in the introduction what the updates to RFC 5216 
are. This will help those implementers that focus on a variant of EAP-TLS that 
uses version 1.2. As mentioned above, I don't believe Sections 5.6 and 5.7 
belong to this document. Leave it in there if someone in the group gets paid by 
the number of published pages.

If you want to reference RFC 7525 you should say what recommendation you want 
to carry over. If you don’t do that then the text should not be in 
contradiction of what is said in eap-tls13.

Given your email with the dramatic title “Moving towards less security in 
2020”, I am surprised that the reference to known attacks and the deprecation 
of old TLS versions receives a “SHOULD” rather than a “MUST”. Feels out of 
balance to me and this makes me believe that the update to RFC 5216 has not 
been given too much thoughts by the group and by the authors. My guess is that 
most implementers use the latest version of TLS 1.2 code already anyway, which 
comes with sensible defaults. Do you have a different experience?

Ciao
Hannes

From: Mohit Sethi M 
<mailto:mohit.m.se...@ericsson.com>
Sent: Monday, November 2, 2020 9:59 AM
To: Hannes Tschofenig 
<mailto:hannes.tschofe...@arm.com>; Mohit Sethi M 
<mailto:mohit.m.se...@ericsson.com>; 
emu@ietf.org<mailto:emu@ietf.org>
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: Updates RFC 5216


Hi Hannes,

As said, we added this text based on the request of working group members. 
There were comments and additions to this text by Terry Burton for example: 
https://mailarchive.ietf.org/arch/browse/emu/?q=Client%20re-validation%20of%20server%20authority%20information%20during%20resumption

We are happy to update the draft with whatever the working group decides.

About your comment "Most readers who focus on TLS 1.2 in EAP-TLS will never get 
to  see those because they are hidden in the document.". I certainly hope 
that's not true because: this draft updates RFC 5216, and, the abstract says 
"This document also provides guidance on authorization and resumption for 
EAP-TLS in general (regardless of the underlying TLS version used).  This 
document updates RFC 5216."

Could you also please clarify "You are referencing the wrong documents.". Thank 
you for being patient. :)

--Mohit
On 11/2/20 9:51 AM, Hannes Tschofenig wrote:
Hi Mohit,

I hope you understand that I am worried about three things in my email below:


  1.  You are putting text into an EAP method that applies to EAP itself. 
Nothing prevents the EMU group to work on a document that clarifies EAP usage 
in document that updates the EAP spec, if the described issue is important.
  2.  You are making changes to the use of TLS 1.2 in EAP-TLS in a document 
that focuses on TLS 1.3 use in EAP-TLS.
Most readers who focus on TLS 1.2 in EAP-TLS will 

Re: [Emu] Making Security Practical ... was RE: Moving towards less security in 2020 - OCSP

2020-11-02 Thread Mohit Sethi M
Hi Hannes,

On 11/2/20 11:42 AM, Hannes Tschofenig wrote:
Hi Mohit,


> Et voilà, we seem to be moving towards a consensus!

That’s indeed exciting.



> PS: I would certainly like to help with getting OCSP in mbed TLS. I guess its 
> high time.

Looking forward to it. I would then add the other pieces to TLS 1.3 to make it 
complete.



>  There have been several requests for this already for a few years: 
> https://github.com/ARMmbed/mbedtls/issues/880
3 questions about a feature in 5 years. For an open source project like Mbed 
TLS this is close to “zero interest”.

You are probably right here. This is the unfortunate reality for many open 
source projects. While writing some code with openssl, I (and others) had 
requested a feature to export x25519 public keys: 
https://github.com/openssl/openssl/pull/5520#issuecomment-391088904. Not sure 
how far that has come along.

--Mohit



Ciao

Hannes



IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


___
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


Re: [Emu] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec

2020-11-02 Thread Mohit Sethi M
Done as suggested:

https://github.com/emu-wg/draft-ietf-emu-eap-tls13/commit/8e158b5dc06ab5efd06c130ceffefe8c0cdff8e0

--Mohit

On 11/2/20 11:16 AM, Hannes Tschofenig wrote:
Thanks, Mohit.

You could also delete the entire paragraph because it adds nothing to what is 
already said in the TLS 1.3 spec.
See https://github.com/hannestschofenig/draft-ietf-emu-eap-tls13/pull/1

Ciao
Hannes


From: Mohit Sethi M 
<mailto:mohit.m.se...@ericsson.com>
Sent: Monday, November 2, 2020 9:58 AM
To: Hannes Tschofenig 
<mailto:hannes.tschofe...@arm.com>; Mohit Sethi M 
<mailto:mohit.m.se...@ericsson.com>; 
emu@ietf.org<mailto:emu@ietf.org>
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec


I now understand your issue with the sentence "An EAP-TLS peer and server 
SHOULD support the use of HelloRetryRequest message.". I guess there is no need 
for it, i.e., the section would be just fine without that sentence:
TLS 1.3 [RFC8446] defines that TLS servers can send a HelloRetryRequest message 
in response to a ClientHello if the server finds an acceptable set of 
parameters but the initial ClientHello does not contain all the needed 
information to continue the handshake.  One use case is if the server does not 
support the groups in the "key_share" extension, but supports one of the groups 
in the "supported_groups" extension.  In this case the client should send a new 
ClientHello with a "key_share" that the server supports.

As noted in Section 4.1.4 of [RFC8446], the server MUST provide the 
supported_versions extensions and SHOULD contain the minimal set of extensions 
necessary for the client to generate a correct ClientHello pair.  A 
HelloRetryRequest MUST NOT contain any extensions that were not first offered 
by the client in  its ClientHello, with the exception of optionally including 
the cookie extension.

The case of a successful EAP-TLS mutual authentication after the server has 
sent a HelloRetryRequest message is shown in Figure 8. Note the extra 
round-trip as a result of the HelloRetryRequest.

Commit on git: 
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/commit/d4ac353a90dc7466d6da9deb5f50f4eb7c585e9b

--Mohit
On 11/2/20 9:39 AM, Hannes Tschofenig wrote:
Hi Mohit,

I read Jim’s email and he is not saying that you should make it an optional to 
support feature.

The issue is:

- are you trying to change the functionality of TLS 1.3 with this draft, and
- is there a good reason to do so?

In this case, the “SHOULD” statement gives an implementer absolutely not idea 
when or when it would be good to implement this feature.
Besides this, I don’t even believe that the TLS 1.3 spec gives you that freedom 
for this specific feature anyway.

Ciao
Hannes


From: Mohit Sethi M 
<mailto:mohit.m.se...@ericsson.com>
Sent: Saturday, October 31, 2020 6:04 PM
To: Hannes Tschofenig 
<mailto:hannes.tschofe...@arm.com>; 
emu@ietf.org<mailto:emu@ietf.org>
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec


Hi Hannes,

Jim Schaad had asked for this: 
https://mailarchive.ietf.org/arch/msg/emu/XpRkNN-mh5BuiTD1O8iEfz9sM4M/

It is still optional to use. The figure only shows what the exchange would look 
like if a HRR was sent by the server.

--Mohit
On 10/21/20 12:16 PM, Hannes Tschofenig wrote:
Hi all,

Section 2.1.6 says:

"
   An EAP-TLS peer and server SHOULD support the use of
   HelloRetryRequest message.
"

My understanding of the TLS 1.3 specification is that the HelloRetryRequest is 
not an optional-to-implement message but it is only optional to use.

Is there a reason to deviate from the TLS 1.3 specification? Is there any 
reason to talk about the HRR message? The purpose of the message is given in 
the TLS 1.3 spec and whether you use it or not is up to the deployment.

Ciao
Hannes


IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.



___

Emu mailing list

Emu@ietf.org<mailto:Emu@ietf.org>

https://www.ietf.org/mailman/listinfo/emu
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


___

Emu mailing list

Emu@ietf.org<mailto:Emu@ietf.org>

https://www.ietf.org/mailman/listinfo/emu

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the 

Re: [Emu] draft-ietf-emu-eap-tls13-11: Updates RFC 5216

2020-11-02 Thread Mohit Sethi M
Hi Hannes,

As said, we added this text based on the request of working group members. 
There were comments and additions to this text by Terry Burton for example: 
https://mailarchive.ietf.org/arch/browse/emu/?q=Client%20re-validation%20of%20server%20authority%20information%20during%20resumption

We are happy to update the draft with whatever the working group decides.

About your comment "Most readers who focus on TLS 1.2 in EAP-TLS will never get 
to  see those because they are hidden in the document.". I certainly hope 
that's not true because: this draft updates RFC 5216, and, the abstract says 
"This document also provides guidance on authorization and resumption for 
EAP-TLS in general (regardless of the underlying TLS version used).  This 
document updates RFC 5216."

Could you also please clarify "You are referencing the wrong documents.". Thank 
you for being patient. :)

--Mohit

On 11/2/20 9:51 AM, Hannes Tschofenig wrote:
Hi Mohit,

I hope you understand that I am worried about three things in my email below:


  1.  You are putting text into an EAP method that applies to EAP itself. 
Nothing prevents the EMU group to work on a document that clarifies EAP usage 
in document that updates the EAP spec, if the described issue is important.
  2.  You are making changes to the use of TLS 1.2 in EAP-TLS in a document 
that focuses on TLS 1.3 use in EAP-TLS.
Most readers who focus on TLS 1.2 in EAP-TLS will never get to see those 
because they are hidden in the document.
  3.  You are referencing the wrong documents.

If you look at this case as a working group chair then you might see the points 
I am trying to get across.

Ciao
Hannes


From: Mohit Sethi M 
<mailto:mohit.m.se...@ericsson.com>
Sent: Saturday, October 31, 2020 6:06 PM
To: Hannes Tschofenig 
<mailto:hannes.tschofe...@arm.com>; 
emu@ietf.org<mailto:emu@ietf.org>
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: Updates RFC 5216


Hi Hannes,

This text and guidance was specifically requested by working group members like 
Alan. Unless the text is wrong, I don't see any point in removing it. Other 
TLS-based EAP methods are obviously free to use parts of this text relevant to 
them. Note that their resumption and authorization might be even more complex 
as some decisions may depend on the inner authentication method.

--Mohit
On 10/21/20 12:00 PM, Hannes Tschofenig wrote:
Hi all,

the draft says it updates the earlier EAP-TLS version and claims that the 
updates are related to

* Section 5.6 Authorization
* Section 5.7 Resumption

The content of Section 5.6 actually does not relate to EAP-TLS but is generic 
to all EAP methods. I don't think it even belongs in an EAP method document.

The content of Section 5.7 claims that there are aspects of resumptions that 
are not described in the earlier version of EAP-TLS. The focus is then on the 
way how the cached data is stored, an implementation-specific aspect, that is 
not specific to EAP-TLS because the concept of caching is used by other EAP 
methods too. Then, there is a threat presented whereby the authorization 
information changes between the full handshake and the resumption handshake. I 
believe that this is not a threat that is unique to EAP-TLS because this can 
happen even when there is no resumption. Nothing prevents you from checking 
authorization again when you do resumption though and even during an ongoing 
session. I would argue that there is a lot of text in there that has nothing to 
do with EAP-TLS but rather concerns the whole system in which EAP is used. If 
this is indeed a problem, I believe it should be covered in a separate 
document. I don’t think it is a problem because extensions for RADIUS and 
Diameter have been developed to address this issue to revoke authorization 
during the lifetime of a session.

Here is where it gets confusing. The introduction says "This document defines 
how to use EAP-TLS with TLS 1.3 (or higher) and does not change how EAP-TLS is 
used with older versions of TLS." To me, this does not sound like an update.

Reading more carefully one can notice that the actual update to EAP-TLS is 
hidden in Section 5.8 "Privacy Considerations" and Section 5.10 "Discovered 
Vulnerabilities".

Section 5.8 says:
"
   it is RECOMMENDED for EAP peers to not use EAP-TLS with
   TLS 1.2 and static RSA based cipher suites without privacy.  This
   implies that an EAP peer SHOULD NOT continue the handshake if a TLS
   1.2 EAP server responds to an empty certificate message with a TLS
   alert message.
"

Section 5.10 says:
"
EAP-TLS implementations
   SHOULD mitigate known attacks and follow the recommendations in
   [RFC7525] and [I-D.ietf-tls-oldversions-deprecate].
"

Interestingly, RFC 7525 does not talk about EAP (and instead focuses on 
applications like  HTTP, SMTP, IMAP, POP, SIP, and XMPP, as noted in the 
abstract). RFC 7525, for example, does not

Re: [Emu] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec

2020-11-02 Thread Mohit Sethi M
I now understand your issue with the sentence "An EAP-TLS peer and server 
SHOULD support the use of HelloRetryRequest message.". I guess there is no need 
for it, i.e., the section would be just fine without that sentence:

TLS 1.3 [RFC8446] defines that TLS servers can send a HelloRetryRequest message 
in response to a ClientHello if the server finds an acceptable set of 
parameters but the initial ClientHello does not contain all the needed 
information to continue the handshake.  One use case is if the server does not 
support the groups in the "key_share" extension, but supports one of the groups 
in the "supported_groups" extension.  In this case the client should send a new 
ClientHello with a "key_share" that the server supports.

As noted in Section 4.1.4 of [RFC8446], the server MUST provide the 
supported_versions extensions and SHOULD contain the minimal set of extensions 
necessary for the client to generate a correct ClientHello pair.  A 
HelloRetryRequest MUST NOT contain any extensions that were not first offered 
by the client in  its ClientHello, with the exception of optionally including 
the cookie extension.

The case of a successful EAP-TLS mutual authentication after the server has 
sent a HelloRetryRequest message is shown in Figure 8. Note the extra 
round-trip as a result of the HelloRetryRequest.

Commit on git: 
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/commit/d4ac353a90dc7466d6da9deb5f50f4eb7c585e9b

--Mohit

On 11/2/20 9:39 AM, Hannes Tschofenig wrote:
Hi Mohit,

I read Jim’s email and he is not saying that you should make it an optional to 
support feature.

The issue is:

- are you trying to change the functionality of TLS 1.3 with this draft, and
- is there a good reason to do so?

In this case, the “SHOULD” statement gives an implementer absolutely not idea 
when or when it would be good to implement this feature.
Besides this, I don’t even believe that the TLS 1.3 spec gives you that freedom 
for this specific feature anyway.

Ciao
Hannes


From: Mohit Sethi M 
<mailto:mohit.m.se...@ericsson.com>
Sent: Saturday, October 31, 2020 6:04 PM
To: Hannes Tschofenig 
<mailto:hannes.tschofe...@arm.com>; 
emu@ietf.org<mailto:emu@ietf.org>
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec


Hi Hannes,

Jim Schaad had asked for this: 
https://mailarchive.ietf.org/arch/msg/emu/XpRkNN-mh5BuiTD1O8iEfz9sM4M/

It is still optional to use. The figure only shows what the exchange would look 
like if a HRR was sent by the server.

--Mohit
On 10/21/20 12:16 PM, Hannes Tschofenig wrote:
Hi all,

Section 2.1.6 says:

"
   An EAP-TLS peer and server SHOULD support the use of
   HelloRetryRequest message.
"

My understanding of the TLS 1.3 specification is that the HelloRetryRequest is 
not an optional-to-implement message but it is only optional to use.

Is there a reason to deviate from the TLS 1.3 specification? Is there any 
reason to talk about the HRR message? The purpose of the message is given in 
the TLS 1.3 spec and whether you use it or not is up to the deployment.

Ciao
Hannes


IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


___

Emu mailing list

Emu@ietf.org<mailto:Emu@ietf.org>

https://www.ietf.org/mailman/listinfo/emu

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


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

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


Re: [Emu] Making Security Practical ... was RE: Moving towards less security in 2020 - OCSP

2020-11-02 Thread Mohit Sethi M
Et voilà, we seem to be moving towards a consensus!

--Mohit

PS: I would certainly like to help with getting OCSP in mbed TLS. I guess its 
high time. There have been several requests for this already for a few years: 
https://github.com/ARMmbed/mbedtls/issues/880

On 11/2/20 10:08 AM, Hannes Tschofenig wrote:
Hi Mohit,


  *   I think it is a reasonable compromise for servers to implement OCSP 
stapling. Clients can implement and use it, but they would be compliant even if 
they don't. So the updated text would be (as Joe wrote in his email):
“
EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status Requests 
(OCSP stapling) as specified in Section 4.4.2.1 of [RFC8446]. It is RECOMMENDED 
that EAP-TLS peers and servers use OCSP stapling for verifying the status of 
server certificates as specified in Section 4.4.2.1 of [RFC8446]. When an 
EAP-TLS peer uses OCSP to verify the certificate status of the EAP-TLS server, 
it MUST use Certificate Status Requests for the server's certificate chain and 
it MUST treat a CertificateEntry (except the trust anchor) without a valid 
CertificateStatus extension as invalid and abort the handshake with an 
appropriate alert.
“

This sounds like a good compromise for me.

Ciao
Hannes

PS: Mohit, maybe you can help implement OCSP to EAP-TLS in Mbed TLS. I am 
looking forward to see OCSP supported added to EDHOC by John.

From: Emu <mailto:emu-boun...@ietf.org> On Behalf Of 
Mohit Sethi M
Sent: Saturday, October 31, 2020 2:15 PM
To: emu@ietf.org<mailto:emu@ietf.org>
Subject: [Emu] Moving towards less security in 2020 - OCSP


Dear all,

Sorry for the radio silence. I have over-committed myself to too many things. I 
think I have now read the entire discussion on OCSP.

EAP-TLS with TLS 1.3 is a working group document so the text will reflect 
whatever the working group wants. The authors and contributors are at the 
service of the working group. Obviously it is easy for us to simply change all 
MUSTs to MAYs, make everyone happy, and hand over the document to the IESG.

Yet, I think as a conscientious security person and individual contributor, I 
am saddened by the discussion thus far. To begin with, I assume that everyone 
knows the difference between OCSP and OCSP stapling. I also hope that everyone 
has read RFC 5216 (the previous EAP-TLS specification). In particular I hope 
that the working group has actually read section 5.4 on "Certificate 
Revocation" (https://tools.ietf.org/html/rfc5216#section-5.4). I copy the 
relevant text here for your convenience:

   EAP-TLS peer and server implementations MUST support the use of

   Certificate Revocation Lists (CRLs); for details, see Section 3.3 
of<https://tools.ietf.org/html/rfc3280#section-3.3>

   [RFC3280]<https://tools.ietf.org/html/rfc3280#section-3.3>.  EAP-TLS peer 
and server implementations SHOULD also

   support the Online Certificate Status Protocol (OCSP), described in

   "X.509 Internet Public Key Infrastructure Online Certificate Status

   Protocol - OCSP" [RFC2560<https://tools.ietf.org/html/rfc2560>].  OCSP 
messages are typically much smaller

   than CRLs, which can shorten connection times especially in

   bandwidth-constrained environments.
and

   For this reason, EAP-TLS peers and servers SHOULD implement

   Certificate Status Request messages, as described in "Transport Layer

   Security (TLS) Extensions", Section 3.6 of 
[RFC4366]<https://tools.ietf.org/html/rfc4366#section-3.6>.  To enable

   revocation checking in situations where servers do not support

   Certificate Status Request messages and network connectivity is not

   available prior to authentication completion, peer implementations

   MUST also support checking for certificate revocation after

   authentication completes and network connectivity is available, and

   they SHOULD utilize this capability by default.

So we were already saying "SHOULD" for OCSP in 2008 when RFC 5216 was 
published. And now 12/13 years later, some people in the working group are 
suggesting to make the security stance weaker. For what? Some speculative 
insecure future deployments? Please note that EAP-TLS is currently implemented 
in billions of devices and used in many high security deployments.

It is very surprising to see Hannes wanting to water down security and get rid 
of the text on OCSP. He wrote "I do not understand certificate revocation 
checking is a topic specific to the use of TLS 1.3 in EAP-TLS.". Well, as you 
see, RFC 5216 has quite detailed guidelines on certificate revocation checking 
with CRLs and OCSP so I don't see any sensible reason on why an update to it 
should not contain relevant text. Michael wrote " we are under no additional 
compulsion to support revocation than we were before." Do you see the problem 
here given the text in RFC 5216 shown above?

While Elliot and Hannes have been vocal about their v

Re: [Emu] Moving towards less security in 2020 - OCSP

2020-11-01 Thread Mohit Sethi M
Hi Michael,

Absolutely, the text which Joe sent (with subject Consensus Call on OCSP 
usage), and which I re-iterated in my email is only saying that OCSP stapling 
is mandatory to implement on the server. Clients SHOULD implement and use it 
but of course they are free not do so.

However, you suggested a modification:

I suggest:

“EAP-TLS servers supporting TLS 1.3 that use OCSP to do certificate
recovation checks,  MUST implement Certificate Status Requests using OCSP
stapling as specified in Section 4.4.2.1 of [RFC8446].

I think this is mangled and incorrect. This text doesn't clearly say that OCSP 
stapling is mandatory-to-implement on the server. This text also says "EAP-TLS 
servers . MUST implement Certificate Status Requests using OCSP stapling as 
specified in." whereas the request is sent by the peer.

But thankfully we are in agreement on what the draft should say. I am sure we 
can reach an agreement on the exact wording. How would you want us to update 
the text:

EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status Requests 
(OCSP stapling) as specified in Section 4.4.2.1 of [RFC8446]. EAP-TLS peers and 
servers SHOULD use OCSP stapling for verifying the status of server 
certificates as specified in Section 4.4.2.1 of [RFC8446]. When an EAP-TLS peer 
uses OCSP to verify the certificate status of the EAP-TLS server, it MUST use 
Certificate Status Requests for the server's certificate chain and it MUST 
treat a CertificateEntry (except the trust anchor) without a valid 
CertificateStatus extension as invalid and abort the handshake with an 
appropriate alert.

--Mohit

On 11/1/20 6:48 PM, Michael Richardson wrote:


Mohit Sethi M 
<mailto:mohit.m.sethi=40ericsson@dmarc.ietf.org>
 wrote:
> So we were already saying "SHOULD" for OCSP in 2008 when RFC 5216 was
> published. And now 12/13 years later, some people in the working group
> are suggesting to make the security stance weaker. For what? Some
> speculative insecure future deployments? Please note that EAP-TLS is
> currently implemented in billions of devices and used in many high
> security deployments.

I don't think that people were saying it should be weaker than SHOULD.
I also think that there is a distinction between MTI and mandatory to use
which has gotten lost.

And I think that there is also a significant distinction between a server
supporting answering OCSP staples, vs a client being forced to ask for it.

If the CA doesn't put any OCSP data into a certificate, then it can't be
used. That's a local decision.

--
Michael Richardson <mailto:mcr+i...@sandelman.ca>   . o 
O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide








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

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


Re: [Emu] draft-ietf-emu-eap-tls13-11: Updates RFC 5216

2020-10-31 Thread Mohit Sethi M
Hi Hannes,

This text and guidance was specifically requested by working group members like 
Alan. Unless the text is wrong, I don't see any point in removing it. Other 
TLS-based EAP methods are obviously free to use parts of this text relevant to 
them. Note that their resumption and authorization might be even more complex 
as some decisions may depend on the inner authentication method.

--Mohit

On 10/21/20 12:00 PM, Hannes Tschofenig wrote:
Hi all,

the draft says it updates the earlier EAP-TLS version and claims that the 
updates are related to

* Section 5.6 Authorization
* Section 5.7 Resumption

The content of Section 5.6 actually does not relate to EAP-TLS but is generic 
to all EAP methods. I don't think it even belongs in an EAP method document.

The content of Section 5.7 claims that there are aspects of resumptions that 
are not described in the earlier version of EAP-TLS. The focus is then on the 
way how the cached data is stored, an implementation-specific aspect, that is 
not specific to EAP-TLS because the concept of caching is used by other EAP 
methods too. Then, there is a threat presented whereby the authorization 
information changes between the full handshake and the resumption handshake. I 
believe that this is not a threat that is unique to EAP-TLS because this can 
happen even when there is no resumption. Nothing prevents you from checking 
authorization again when you do resumption though and even during an ongoing 
session. I would argue that there is a lot of text in there that has nothing to 
do with EAP-TLS but rather concerns the whole system in which EAP is used. If 
this is indeed a problem, I believe it should be covered in a separate 
document. I don’t think it is a problem because extensions for RADIUS and 
Diameter have been developed to address this issue to revoke authorization 
during the lifetime of a session.

Here is where it gets confusing. The introduction says "This document defines 
how to use EAP-TLS with TLS 1.3 (or higher) and does not change how EAP-TLS is 
used with older versions of TLS." To me, this does not sound like an update.

Reading more carefully one can notice that the actual update to EAP-TLS is 
hidden in Section 5.8 "Privacy Considerations" and Section 5.10 "Discovered 
Vulnerabilities".

Section 5.8 says:
"
   it is RECOMMENDED for EAP peers to not use EAP-TLS with
   TLS 1.2 and static RSA based cipher suites without privacy.  This
   implies that an EAP peer SHOULD NOT continue the handshake if a TLS
   1.2 EAP server responds to an empty certificate message with a TLS
   alert message.
"

Section 5.10 says:
"
EAP-TLS implementations
   SHOULD mitigate known attacks and follow the recommendations in
   [RFC7525] and [I-D.ietf-tls-oldversions-deprecate].
"

Interestingly, RFC 7525 does not talk about EAP (and instead focuses on 
applications like  HTTP, SMTP, IMAP, POP, SIP, and XMPP, as noted in the 
abstract). RFC 7525, for example, does not mandate OCSP. It also recommends 
RSA, which draft-ietf-emu-eaptlscert and this draft does not do. There seems to 
be contradiction here.

At a minimum, I would clarify in the introduction what the updates to RFC 5216 
are. This will help those implementers that focus on a variant of EAP-TLS that 
uses version 1.2. As mentioned above, I don't believe Sections 5.6 and 5.7 
belong to this document. Leave it in there if someone in the group gets paid by 
the number of published pages.

Ciao
Hannes
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


___
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


Re: [Emu] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec

2020-10-31 Thread Mohit Sethi M
Hi Hannes,

Jim Schaad had asked for this: 
https://mailarchive.ietf.org/arch/msg/emu/XpRkNN-mh5BuiTD1O8iEfz9sM4M/

It is still optional to use. The figure only shows what the exchange would look 
like if a HRR was sent by the server.

--Mohit

On 10/21/20 12:16 PM, Hannes Tschofenig wrote:
Hi all,

Section 2.1.6 says:

"
   An EAP-TLS peer and server SHOULD support the use of
   HelloRetryRequest message.
"

My understanding of the TLS 1.3 specification is that the HelloRetryRequest is 
not an optional-to-implement message but it is only optional to use.

Is there a reason to deviate from the TLS 1.3 specification? Is there any 
reason to talk about the HRR message? The purpose of the message is given in 
the TLS 1.3 spec and whether you use it or not is up to the deployment.

Ciao
Hannes


IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


___
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


Re: [Emu] Secdir last call review of draft-ietf-emu-eaptlscert-06

2020-10-31 Thread Mohit Sethi M
Hi Stefan,

I made a minor update to reflect your feedback 
(https://github.com/emu-wg/eaptls-longcert/compare/3ac0a18..2093026):

Thus, the AIA extension can reduce the size of the certificate chain by only 
including a pointer to the issuer certificate instead of including the entire 
issuer certificate. However, it requires the side receiving the certificate 
containing the extension to have network connectivity (unless the information 
is already cached locally). Naturally, such indirection cannot be used for the 
server certificate (since EAP peers in most deployments do not have network 
connectivity before authentication and typically do not maintain an up-to-date 
local cache of issuer certificates).

Hope this is correct (and sufficient).

--Mohit

On 10/30/20 4:40 PM, Stefan Santesson wrote:

Hi,

I think the text is great.
However I'm not entirely convinced that AIA requires network connectivity at 
all times.
The AIA CA cert url is static and works fine as identifier for a locally cached 
cert
The fact that it is the correct cert is assured by the path validation process.
As such, the AIA works fine with a http cache implementation or similar or any 
other solution using locally stored data.
If used in a local corporate context, a cache mechanism could be provided with 
pre-loaded relevant certs.

But I don’t know how this may or may not interoperate with deployed base of EAP 
implementations.

Stefan Santesson

On 2020-10-30, 14:48, "Mohit Sethi M" 
<mailto:mohit.m.se...@ericsson.com> wrote:

Hi Stefan,

Thank you for the review. I have updated the draft in github
(https://github.com/emu-wg/eaptls-longcert). Here is the diff for your
convenience:

https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-emu-eaptlscert.txt=https://emu-wg.github.io/eaptls-longcert/draft-ietf-emu-eaptlscert.txt.

The following text was added:

>The size of certificates (and certificate chains) may also increase
>manifold in the future with the introduction of quantum-safe
>cryptography.  For example, lattice-based cryptography would have
>public keys of approximately 1000 bytes and signatures of
>approximately 2000 bytes.
and in Section 4.2.5

>The Authority Information Access (AIA) extension specified in
>[RFC5280] can be used with end-entity and CA certificates to access
>information about the issuer of the certificate in which the
>extension appears.  For example, it can be used to provide the
>address of the OCSP responder from where revocation status of the
>certificate (in which the extension appears) can be checked. It can
>also be used to obtain the issuer certificate.  Thus, the AIA
>extension can reduce the size of the certificate chain by only
>including a pointer to the issuer certificate instead of including
>the entire issuer certificate.  However, it requires the side
>receiving the certificate containing the extension to have network
>connectivity.  Naturally, such indirection cannot be used for the
>server certificate (since the EAP peer in most deployments does not
>have network connectivity before authen

Let me know what you think. I am not an expert on quantum cryptography
or on the AIA extension. I will wait for all the comments to come in
before submitting a new version.

--Mohit

On 10/30/20 5:04 AM, Benjamin Kaduk wrote:
> Hi Stefan,
>
> Thanks for the review; it raises some good topics.
> Replying on a couple points...
>
> On Thu, Oct 29, 2020 at 04:13:02PM -0700, Stefan Santesson via 
Datatracker wrote:
>> Reviewer: Stefan Santesson
>> Review result: Has Nits
>>
>> The document in general is good and well written.
>>
>> Some nits needs attention before publication as the general review also 
points
>> out. Ex in the abstract "This document looks at the this problem"
>>
>> Some abbreviations needs to be spelled out at first usage, such as MTU 
(Maximum
>> Transmission Unit)
> MTU may actually be okay; per
> https://www.rfc-editor.org/materials/abbrev.expansion.txt it is marked as
> "well-known" and does not always need to be expanded.
>
>> On the content itself I have two questions:
>>
>> - Wouldn't it be relevant to also discuss the risks with regard to 
introduction
>> of quantum safe crypto, if that leads to significantly increased key 
sizes? It
>> could be troublesome if transition to a safer crypto is made impossible 
due to
>> size limitations. - Would it be relevant to discuss usage of AIA 
extension as
>> means of possibly

[Emu] Moving towards less security in 2020 - OCSP

2020-10-31 Thread Mohit Sethi M
Dear all,

Sorry for the radio silence. I have over-committed myself to too many things. I 
think I have now read the entire discussion on OCSP.

EAP-TLS with TLS 1.3 is a working group document so the text will reflect 
whatever the working group wants. The authors and contributors are at the 
service of the working group. Obviously it is easy for us to simply change all 
MUSTs to MAYs, make everyone happy, and hand over the document to the IESG.

Yet, I think as a conscientious security person and individual contributor, I 
am saddened by the discussion thus far. To begin with, I assume that everyone 
knows the difference between OCSP and OCSP stapling. I also hope that everyone 
has read RFC 5216 (the previous EAP-TLS specification). In particular I hope 
that the working group has actually read section 5.4 on "Certificate 
Revocation" (https://tools.ietf.org/html/rfc5216#section-5.4). I copy the 
relevant text here for your convenience:

   EAP-TLS peer and server implementations MUST support the use of
   Certificate Revocation Lists (CRLs); for details, see Section 3.3 of
   [RFC3280].  EAP-TLS peer 
and server implementations SHOULD also
   support the Online Certificate Status Protocol (OCSP), described in
   "X.509 Internet Public Key Infrastructure Online Certificate Status
   Protocol - OCSP" [RFC2560].  OCSP 
messages are typically much smaller
   than CRLs, which can shorten connection times especially in
   bandwidth-constrained environments.

and

   For this reason, EAP-TLS peers and servers SHOULD implement
   Certificate Status Request messages, as described in "Transport Layer
   Security (TLS) Extensions", Section 3.6 of 
[RFC4366].  To enable
   revocation checking in situations where servers do not support
   Certificate Status Request messages and network connectivity is not
   available prior to authentication completion, peer implementations
   MUST also support checking for certificate revocation after
   authentication completes and network connectivity is available, and
   they SHOULD utilize this capability by default.

So we were already saying "SHOULD" for OCSP in 2008 when RFC 5216 was 
published. And now 12/13 years later, some people in the working group are 
suggesting to make the security stance weaker. For what? Some speculative 
insecure future deployments? Please note that EAP-TLS is currently implemented 
in billions of devices and used in many high security deployments.

It is very surprising to see Hannes wanting to water down security and get rid 
of the text on OCSP. He wrote "I do not understand certificate revocation 
checking is a topic specific to the use of TLS 1.3 in EAP-TLS.". Well, as you 
see, RFC 5216 has quite detailed guidelines on certificate revocation checking 
with CRLs and OCSP so I don't see any sensible reason on why an update to it 
should not contain relevant text. Michael wrote " we are under no additional 
compulsion to support revocation than we were before." Do you see the problem 
here given the text in RFC 5216 shown above?

While Elliot and Hannes have been vocal about their views, we also saw feedback 
from Janfred explaining the situation without OCSP in a live network like 
eduroam: 
https://mailarchive.ietf.org/arch/msg/emu/X9Mm24LSzaq63bHSvmkBbiSsrJc/. He ends 
his email with

All in all, I definitely think that making OCSP Stapling optional will
have a benefit on small devices, but especially for the diverse
environment of eduroam, making OCSP Stapling mandatory will increase the
overall security of this federation.
Maybe it might be a good idea to make OCSP Stapling mandatory for
EAP-TLS Servers?

So where we are with the current draft. The current draft 
(https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-11#section-5.4) says, 
"When EAP-TLS is used with TLS 1.3, the server MUST check the revocation status 
of the certificates in the client's certificate chain.". It doesn't mandate any 
specific technique. You are free to use whatever propriety (potentially 
insecure) method you want. The revocation checking could use the following 
pseudocode for checking the revocation status of client certificates:

fun check_revocation {
return success;
}

and you would comply with specification. Naturally, using CRLs or 
locally-configured OCSP responder on the server (for revocation checking of 
client certificates) will get you better security. The current text in the 
draft does mandate OCSP stapling for clients to verify the revocation status of 
server certificates. Given the resistance in the working group, I think it is a 
reasonable compromise for servers to implement OCSP stapling. Clients can 
implement and use it, but they would be compliant even if they don't. So the 
updated text would be (as Joe wrote in his email):

EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status 

Re: [Emu] Secdir last call review of draft-ietf-emu-eaptlscert-06

2020-10-30 Thread Mohit Sethi M
Hi Stefan,

Thank you for the review. I have updated the draft in github 
(https://github.com/emu-wg/eaptls-longcert). Here is the diff for your 
convenience: 
https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-emu-eaptlscert.txt=https://emu-wg.github.io/eaptls-longcert/draft-ietf-emu-eaptlscert.txt.

The following text was added:

>    The size of certificates (and certificate chains) may also increase
>    manifold in the future with the introduction of quantum-safe
>    cryptography.  For example, lattice-based cryptography would have
>    public keys of approximately 1000 bytes and signatures of
>    approximately 2000 bytes.
and in Section 4.2.5

>    The Authority Information Access (AIA) extension specified in
>    [RFC5280] can be used with end-entity and CA certificates to access
>    information about the issuer of the certificate in which the
>    extension appears.  For example, it can be used to provide the
>    address of the OCSP responder from where revocation status of the
>    certificate (in which the extension appears) can be checked. It can
>    also be used to obtain the issuer certificate.  Thus, the AIA
>    extension can reduce the size of the certificate chain by only
>    including a pointer to the issuer certificate instead of including
>    the entire issuer certificate.  However, it requires the side
>    receiving the certificate containing the extension to have network
>    connectivity.  Naturally, such indirection cannot be used for the
>    server certificate (since the EAP peer in most deployments does not
>    have network connectivity before authen

Let me know what you think. I am not an expert on quantum cryptography 
or on the AIA extension. I will wait for all the comments to come in 
before submitting a new version.

--Mohit

On 10/30/20 5:04 AM, Benjamin Kaduk wrote:
> Hi Stefan,
>
> Thanks for the review; it raises some good topics.
> Replying on a couple points...
>
> On Thu, Oct 29, 2020 at 04:13:02PM -0700, Stefan Santesson via Datatracker 
> wrote:
>> Reviewer: Stefan Santesson
>> Review result: Has Nits
>>
>> The document in general is good and well written.
>>
>> Some nits needs attention before publication as the general review also 
>> points
>> out. Ex in the abstract "This document looks at the this problem"
>>
>> Some abbreviations needs to be spelled out at first usage, such as MTU 
>> (Maximum
>> Transmission Unit)
> MTU may actually be okay; per
> https://www.rfc-editor.org/materials/abbrev.expansion.txt it is marked as
> "well-known" and does not always need to be expanded.
>
>> On the content itself I have two questions:
>>
>> - Wouldn't it be relevant to also discuss the risks with regard to 
>> introduction
>> of quantum safe crypto, if that leads to significantly increased key sizes? 
>> It
>> could be troublesome if transition to a safer crypto is made impossible due 
>> to
>> size limitations. - Would it be relevant to discuss usage of AIA extension as
>> means of possibly excluding intermediary certs from the path as they could be
>> located using AIA?
>>
>> Finally, I agree with the general review that this document reference quite
>> some work in progress. If this document is to be published before these
>> referenced works are concluded, are there alternatives to make the same 
>> point?
> They seem to mostly be informative references, and so would not require us
> to hold publication of this document.  It is probably still worth
> considering if there are alternatives anyway, though.
>
> -Ben
>
> ___
> 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


Re: [Emu] Barry Leiba's No Objection on draft-ietf-emu-eaptlscert-06: (with COMMENT)

2020-10-30 Thread Mohit Sethi M
Hi Barry,

Thank you for the careful review. I have updated the draft in github 
(https://github.com/emu-wg/eaptls-longcert). Here is the diff for your 
convenience: 
https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-emu-eaptlscert.txt=https://emu-wg.github.io/eaptls-longcert/draft-ietf-emu-eaptlscert.txt.
 
I will wait for all the comments to come in before submitting a new version.

Regarding your comment of informational vs. applicability statement: I 
am not opposed to the idea. I am happy to follow whatever the IESG 
recommends.

--Mohit

On 10/28/20 9:21 PM, Barry Leiba via Datatracker wrote:
> Barry Leiba has entered the following ballot position for
> draft-ietf-emu-eaptlscert-06: 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-eaptlscert/
>
>
>
> --
> COMMENT:
> --
>
> Thanks for this; it will be useful to have this issue fixed.
>
> There’s something I’d like to discuss, but without making it a blocking 
> DISCUSS:
> While I understand the reason for putting this forward as Informational, it
> does strike me more as a Standards Track Applicability Statement.  BCP 9 says
> (in RFC 2026 Section 3.2):
>
> An Applicability Statement specifies how, and under what
> circumstances, one or more TSs may be applied to support a particular
> Internet capability.
>
> Reading the rest of Section 3.2 as well, I think that it fits exactly what
> you’re doing with this document: the document is saying that there’s an
> interoperability problem with large certs and long chains, and here are things
> to do in order to make that work.  Let’s please have a brief discussion about
> whether this should instead be published at Proposed Standard as an AS.
>
> —
>
> Below are some nits that I hope you’ll consider, but there’s no need to 
> respond
> in detail here; please do as you think best.
>
> — Section 1 —
>
> vendor specific EAP methods.
>
> Need a hyphen in “vendor-specific”.
>
> EAP-TLS
> deployments typically authenticates both the EAP peer and the EAP
>
> Make it “authenticate”.
>
> Section 3.1 of [RFC3748] states that EAP implementations can assume a
> MTU of at least 1020 octets from lower layers.
>
> Unless you have a way of pronouncing “MTU” that I don’t, make it “an MTU”.
>
> Such fragmentation can not only negatively
> affect the latency, but also results in other challenges.
>
> The “can” is misplaced; make it “not only can affect”.
>
> — Section 2 —
>
> The document additionally uses the terms trust anchor and
> certification path defined in [RFC5280].
>
> I would put “trust anchor” and “certification path” in quotes here.
>
> — Section 3 —
>
> Certificate sizes can however be large
>
> Commas are needed both before and after “however”.  Also, the list talks about
> a singular “certificate”, so the lead-in should match that (and you don’t need
> to say that a *size* can be large): “A certificate can, however, be large for 
> a
> number of reasons:”
>
> The list is also not parallel (the third item, in particular, is not like the
> others).  I would make the whole list be complete sentences, like this,
> referring to “a certificate” in the lead-in:
>
> NEW
> o  It can have a long Subject Alternative Name field.
>
> o  It can have long Public Key and Signature fields.
>
> o  It can contain multiple object identifiers (OID) that indicate the
>permitted uses of the certificate as noted in Section 5.3 of
>[RFC5216].  Most implementations verify the presence of these OIDs
>for successful authentication.
>
> o  It can contain multiple user groups.
> END
>
> — Section 4.1 —
>
> Throughout this paragraph you refer to “size of public keys” and “size of
> digital signatures”.  It’s a really nitty nit, but I would make these all
> singular, because we’re really talking about the size of an individual public
> key or digital signature, not the size of a collection of them.
>
> authentication which can alleviate the problem of authenticators
>
> There needs to be a comma before “which”.
>
> ECC based cipher suites with existing code can significantly
>
> Hyphenate “ECC-based”.
>
> — Section 4.1.1 —
>
> OIDs are used lavishly in X.509 certificates
>
> I like it: “lavishly” is not a word we often see in RFCs.  :-)
>
>DNs
>used in the issuer and subject fields as well as numerous
>extensions.
>
> This is not a complete 

Re: [Emu] Genart last call review of draft-ietf-emu-eaptlscert-05

2020-10-28 Thread Mohit Sethi M
Hi Elwyn,

Thank you for the careful review. We have updated the draft based on 
your feedback. Here is the diff for you convenience: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eaptlscert-06.

See our responses in-line.

--Mohit

On 10/24/20 1:44 PM, Elwyn Davies via Datatracker wrote:
> Reviewer: Elwyn Davies
> Review result: Ready with Nits
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
>
> .
>
> Document: draft-ietf-emu-eaptlscert-05
> Reviewer: Elwyn Davies
> Review Date: 2020-10-24
> IETF LC End Date: 2020-10-28
> IESG Telechat date: Not scheduled for a telechat
>
> Summary:  Ready with nits.  There are quite a number of references to
> associated work that is still in progress as drafts.  Whilst this is unlikely
> to compromise the content of this work, it will potentially delay its
> publication.  In particular I have suggested rewriting s4.2.7 to omit more
> speculative references to incomplete work in favour of a general 
> recommendation
> to make use of relevant new proposals as they become available.
Most of the normative references are to already published RFCs. There is 
only one normative reference to a draft which will also hopefully move 
forward soon. You are right that there are many informational references 
to work in progress. But this is what the working group participants 
wanted. For example, Hannes suggested to add references to new TLS 
certificate types and certificate compression with CBOR: 
https://mailarchive.ietf.org/arch/msg/emu/cIVEGF6eLCvrdCqkA5Zzjxor9vs/. 
I think it can be valuable for a reader to have concrete examples of 
work in progress.
>
> Major Issues:
> None
>
> Minor Issues:
> None
>
> Nits and Editoral Issues:
>
> General:  RFC 2119 key words:  In the document there are two MUSTs and a 
> SHOULD
> NOT none of which are appropriate usages in my opinion (see notes below), 
> aside
> from the  intended infromational status.  The RFC 2119 etc boilerplate in s2
> could be omitted.
Now there is only one SHOULD NOT. I'll let the IESG deliberate if they 
want us to change to "should not" instead. But I think it is an 
important operational guideline and as Alan DeKok noted, administrators 
should really ensure that certificate chains don't contain more than 2-4 
intermediate certificates.
>
> Abstract:  Need to expand EAP-TLS and EAP on first occurrence.
Done.
>
> s1, end of para 2:  Suggest s/involves significantly more octets/involves
> exchange of significantly more octets/
Done.
>
> s2, definition of EAP server:  Where would a reader find a definition of
> "backend authentication"?  Uncle Google was singularly unhelpful.
The text does say "Readers are expected to be familiar with the terms 
and concepts used in EAP [RFC3748]". The term backend authentication 
server is defined there: 
https://tools.ietf.org/html/rfc3748#section-1.2. In this document, we 
only define the terms that are used frequently. And backend 
authentication server wasn't one of them.
>
> s3, last para:  clarify the meaning of kB:  suggest s/~ 60kB/approximately 60
> kbytes/ (I assume).
Done.
>
> s4:  The usage of the form " we look/discuss/etc." typically  used in academic
> papers is not appropriate for standards documents.  Section 4 needs to be
> redrafted to eliminate this usage.  The following may be appropriate:
>
> OLD:
> This section discusses some possible alternatives for overcoming the challenge
> of large certificates and long certificate chains in EAP- TLS authentication.
> In Section 4.1 we look at recommendations that require an update of the
> certificates or certificate chains that are used for EAP-TLS authentication
> without requiring changes to the existing EAP-TLS code base. We also provide
> some guidelines when issuing certificates for use with EAP-TLS. In Section 4.2
> we look at recommendations that rely on updates to the EAP-TLS implementations
> which can be deployed with existing certificates. In Section 4.3 we shortly
> discuss the solution to update or reconfigure authenticator which can be
> deployed without changes to existing certificates or EAP-TLS code.
>
> NEW:
> This section discusses some possible alternatives for overcoming the challenge
> of large certificates and long certificate chains in EAP- TLS authentication.
> Section 4.1 considers recommendations that require an update of the
> certificates or certificate chains that are used for EAP-TLS authentication
> without requiring changes to the existing EAP-TLS code base. The section also
> provides some guidelines that ahould be followed when issuing certificates for
> use with EAP-TLS. Section 4.2 considers recommendations that rely on updates 
> to
> the EAP-TLS implementations which can be deployed with 

Re: [Emu] I-D Action: draft-ietf-emu-eap-tls13-11.txt

2020-10-14 Thread Mohit Sethi M
Dear all,

This version includes additional clarifications on resumption suggested 
by Terry Burton. Based on the mailing list discussion, we still use 
1-byte of encrypted application data as the commitment message: 
https://mailarchive.ietf.org/arch/msg/emu/6f36UTSysJ_xzGdkOtC4TDNTZbI/.

--Mohit

On 10/14/20 8:41 PM, internet-dra...@ietf.org wrote:
> 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
>  Authors : John Preuß Mattsson
>Mohit Sethi
>   Filename: draft-ietf-emu-eap-tls13-11.txt
>   Pages   : 30
>   Date: 2020-10-14
>
> Abstract:
> This document specifies the use of 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 further improves security and privacy by mandating use
> of privacy and revocation checking.  This document also provides
> guidance on 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 are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-11
> https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-tls13-11
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-11
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> 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 mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Appropriate AAA/EAP response to a peer's NAK when there are no overlapping methods

2020-08-23 Thread Mohit Sethi M
Hi again,

On 8/23/20 7:12 PM, Alan DeKok wrote:
> On Aug 23, 2020, at 9:48 AM, Mohit Sethi M  wrote:
>> Sorry, but you are missing context here. The discussion was no longer
>> about sending an EAP failure when no suitable EAP methods are available.
>> Terry and I were discussing the direction of NAK messages in an EAP
>> conversation. I highlighted that a NAK is only sent by the peer to the
>> server (and not in the reverse direction). To this, Terry pointed to the
>> following text in RFC 3579 Section 2.6.2 titled "Role Reversal":
>Ok.
>
>>>  Since EAP is a peer-to-peer protocol, an independent and simultaneous
>>>  authentication may take place in the reverse direction.  Both peers
>>>  may act as authenticators and authenticatees at the same time.
>>>
>>>  However, role reversal is not supported by this specification.  A
>>>  RADIUS server MUST respond to an Access-Request encapsulating an
>>>  EAP-Request with an Access-Reject.  In order to avoid retransmissions
>>>  by the peer, the Access-Reject SHOULD include an EAP-Response/Nak
>>>  packet indicating no preferred method, encapsulated within
>>>  EAP-Message attribute(s).
>FreeRADIUS allows EAP-Request, largely for LEAP.  Tho TBH that should 
> probably be deleted.
>
>> It may seem from this text that a NAK is sent in the reverse direction
>> (i.e. from server to peer). But I was pointing to Terry that this NAK is
>> sent by the RADIUS server (and not the EAP server). So the fact that NAK
>> messages are sent by the EAP peer only still holds true. This protection
>> against retransmissions is not implemented in hostap ( as you can see in
>> https://w1.fi/cgit/hostap/tree/src/radius/radius_server.c#n1437) or
>> FreeRADIUS. I suspect because deployments don't encounter this kind of
>> role reversal in practice.
>Yes, I haven't seen EAP -Request sent to RADIUS servers, other than for 
> LEAP.
>
>I'm not sure what you mean by "protection against retransmissions" though.

Well. I am referring to the text from the RFC 3579: "In order to avoid 
retransmissions by the peer, the Access-Reject SHOULD include an 
EAP-Response/Nak packet indicating no preferred method, encapsulated 
within EAP-Message attribute(s)." It is clear that hostap does not (yet) 
implement this SHOULD. I suspect that FreeRADIUS doesn't either. Maybe 
that's because it needs to allow role reversal (i.e. peer sending an 
EAP-Request) for LEAP?

--Mohit

>
>Alan DeKok.
>
> ___
> 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


Re: [Emu] Appropriate AAA/EAP response to a peer's NAK when there are no overlapping methods

2020-08-23 Thread Mohit Sethi M
Hi Alan,

On 8/21/20 3:50 PM, Alan DeKok wrote:
> On Aug 21, 2020, at 3:27 AM, Mohit Sethi M 
>  wrote:
>> Sorry for nitpicking here. But it is important to distinguish the two
>> components that comprise a AAA server: RADIUS server and EAP server. RFC
>> 3579 briefly alludes to this difference and uses different terms for a
>> RADIUS server and an EAP server. Sure, they will likely run on the same
>> machine and are tightly integrated, yet they are independent components.
>Some minor nit picking here...
>
>In practice, EAP servers are tightly coupled with RADIUS servers.  At 
> least for ones which implement non-trivial EAP methods.
>
>But I agree that they need to be treated as independent components.
Not sure what you are nit picking. Because you essentially agree that 
they are independent components yet tightly integrated in most 
implementations.
>
>FWIW, I've looked for EAP server implementations.  As best I can tell for 
> Open Source, it's just hostap and FreeRADIUS.  Everything else is either 
> dead, or implements only a tiny subset of EAP, such as EAP-MD5.
I bow to you and Jouni for all the hard work in maintaining these 
excellent pieces of software.
>
>> The text you point to in RFC 3579 doesn't imply that the NAK is sent
>> from the EAP server. It only says that to avoid retransmissions, a
>> RADIUS server should generate an Access-Reject containing a
>> EAP-Response/Nak on its own (without involving the EAP server). So
>> technically, this NAK is still not sent by the EAP server in the
>> so-called 'wrong direction'. In common realistic implementations, RADIUS
>> servers only proxy data to/from the EAP server
>I'm wary of the word "proxy".  Proxying implies some kind of transport, as 
> with RADIUS proxying.
>
>The public implementations of RADIUS+EAP  have the two components in the 
> same process, using shared libraries.  The interaction between the two is 
> just API calls.
>
>> and do not generally
>> inject EAP packets on their own. Which is why I suspect that this is not
>> implemented in the radius server of hostap:
>> https://w1.fi/cgit/hostap/tree/src/radius/radius_server.c#n1437
>The RADIUS side of hostap doesn't inject the EAP Failure.  The underlying 
> EAP implementation injects it.
>
>The eap_sm_Policy_getDecision() function returns failure if there are no 
> compatible EAP methods.  The calling function then returns EAP Failure.
>
> https://w1.fi/cgit/hostap/tree/src/eap_server/eap_server.c#n1722
>
>The EAP server implementation in FreeRADIUS also returns an EAP Failure 
> packet  if there are no compatible EAP methods.
>
>The underlying principle here is that silently dropping packets is 
> considered bad.  Therefore, no matter what happens inside of the EAP state 
> machine, the outcome is one of 3 things:
>
> * more EAP negotiation
> * Success
> * Failure
>
>The only time the RADIUS side injects an EAP Failure is if the session is 
> rejected for administrative reasons.  And, the EAP state machine is bypassed. 
>   e.g. deny this particular user on this particular device, even if their EAP 
> credentials are OK.
>
> In that case, the EAP stack is bypassed.  The Access-Reject handler 
> checks for an EAP-Message in the Access-Request.  If found, the RADIUS layer 
> synthesizes an EAP Failure inside of an EAP-Message.
>
>Since hostap doesn't really have policies in it's RADIUS server 
> implementation, it doesn't implement this check.

Sorry, but you are missing context here. The discussion was no longer 
about sending an EAP failure when no suitable EAP methods are available. 
Terry and I were discussing the direction of NAK messages in an EAP 
conversation. I highlighted that a NAK is only sent by the peer to the 
server (and not in the reverse direction). To this, Terry pointed to the 
following text in RFC 3579 Section 2.6.2 titled "Role Reversal":

>  Since EAP is a peer-to-peer protocol, an independent and simultaneous
>  authentication may take place in the reverse direction.  Both peers
>  may act as authenticators and authenticatees at the same time.
>
>  However, role reversal is not supported by this specification.  A
>  RADIUS server MUST respond to an Access-Request encapsulating an
>  EAP-Request with an Access-Reject.  In order to avoid retransmissions
>  by the peer, the Access-Reject SHOULD include an EAP-Response/Nak
>  packet indicating no preferred method, encapsulated within
>  EAP-Message attribute(s).
It may seem from this text that a NAK is sent in the reverse direction 
(i.e. from server to peer). But I was pointing to Terry that this NAK is 
sent by the RADIUS serve

Re: [Emu] Appropriate AAA/EAP response to a peer's NAK when there are no overlapping methods

2020-08-21 Thread Mohit Sethi M
Hi Terry,

On 8/20/20 5:41 PM, Terry Burton wrote:
> On Thu, 20 Aug 2020 at 14:54, Mohit Sethi M
>   wrote:
>> It would be a misinterpretation to say that everything from the
>> authenticator is an EAP-Request hence EAP-Failure is also a Request.
>> It's an EAP packet with a different Code. Thus, it is wrong to say that
>> text "the authenticator SHOULD NOT send another Request" also implies
>> that the authenticator SHOULD NOT send an EAP-Failure.
> You're right. Thanks.
>
>> Also, Section 5 of RFC 3748 says that NAK is response only. So I don't
>> understand what you mean by 'NAK is just a "Type" of Request / Response
>> (depending on direction)'. NAKs are only sent by the peer to the
>> authenticator/server. Sending a NAK in the other direction would be a
>> violation of RFC 3748 and is not supported or implemented.
> I was probably thrown because RFC 3579 section 2.6.2 on Role Reversal has 
> this:
>
> Since EAP is a peer-to-peer protocol, an independent and simultaneous
> authentication may take place in the reverse direction.  Both peers
> may act as authenticators and authenticatees at the same time.
>
> However, role reversal is not supported by this specification.  A
> RADIUS server MUST respond to an Access-Request encapsulating an
> EAP-Request with an Access-Reject.  In order to avoid retransmissions
> by the peer, the Access-Reject SHOULD include an EAP-Response/Nak
> packet indicating no preferred method, encapsulated within
> EAP-Message attribute(s).
>
> Notionally that's an "EAP-Response/NAK" sent in the "wrong" direction:
> AAA --> NAS --> Peer
>
> However I believe that this is considering the case where the peer
> contains an EAP server that is trying to initiate an authentication of
> the NAS (not allowed), and therefore the AAA tells the peer to go
> away.

Sorry for nitpicking here. But it is important to distinguish the two 
components that comprise a AAA server: RADIUS server and EAP server. RFC 
3579 briefly alludes to this difference and uses different terms for a 
RADIUS server and an EAP server. Sure, they will likely run on the same 
machine and are tightly integrated, yet they are independent components. 
The text you point to in RFC 3579 doesn't imply that the NAK is sent 
from the EAP server. It only says that to avoid retransmissions, a 
RADIUS server should generate an Access-Reject containing a 
EAP-Response/Nak on its own (without involving the EAP server). So 
technically, this NAK is still not sent by the EAP server in the 
so-called 'wrong direction'. In common realistic implementations, RADIUS 
servers only proxy data to/from the EAP server and do not generally 
inject EAP packets on their own. Which is why I suspect that this is not 
implemented in the radius server of hostap: 
https://w1.fi/cgit/hostap/tree/src/radius/radius_server.c#n1437

--Mohit

>> On 8/20/20 4:26 PM, Terry Burton wrote:
>>> On Thu, 20 Aug 2020 at 13:34, Mohit Sethi M
>>>   wrote:
>>> <...snip...>
>>>> It's also contrary to...
>>>>
>>>> Type zero (0) is used to indicate that the sender has
>>>> no viable alternatives, and therefore the authenticator SHOULD NOT
>>>> send another Request after receiving a Nak Response containing a
>>>> zero value.
>>>>
>>>>  unless the language is loose and we say that an EAP-Failure
>>>> request isn't actually a "Request", but that's hard to argue due to
>>>> capital "R"equest.
>>>>
>>>> Why is EAP-Failure a request? It's an EAP packet with a different Code? So 
>>>> the SHOULD NOT doesn't forbid the server from sending an EAP-Failure. RFC 
>>>> 3748 even calls Failure as a response: "An authenticator MAY wish to issue 
>>>> multiple Requests before sending a Failure response in order to allow for 
>>>> human typing mistakes."
>>> That's a small "r"esponse and I'd dare to say that even that usage
>>> isn't particularly helpful! :-)
>>>
>>> I think it's well established that any message from the authenticator
>>> to the peer (Code = 1) is an "R"equest and that any message from the
>>> peer to the authenticator (Code = 2) is an EAP "R"esponse. NAK is just
>>> a "Type" of Request / Response (depending on direction). So when the
>>> above text mentions "R"equest it actually refers to EAP packets with
>>> Code = 1, i.e. it says (seemingly erroneously as Alan points out) that
>>> no further messages of any type should be sent from the authenticator
>>> to the peer within the conversation.
> ___
> 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


Re: [Emu] Appropriate AAA/EAP response to a peer's NAK when there are no overlapping methods

2020-08-20 Thread Mohit Sethi M
Hi Terry,

It would be a misinterpretation to say that everything from the 
authenticator is an EAP-Request hence EAP-Failure is also a Request. 
It's an EAP packet with a different Code. Thus, it is wrong to say that 
text "the authenticator SHOULD NOT send another Request" also implies 
that the authenticator SHOULD NOT send an EAP-Failure.

Also, Section 5 of RFC 3748 says that NAK is response only. So I don't 
understand what you mean by 'NAK is just a "Type" of Request / Response 
(depending on direction)'. NAKs are only sent by the peer to the 
authenticator/server. Sending a NAK in the other direction would be a 
violation of RFC 3748 and is not supported or implemented.

--Mohit

On 8/20/20 4:26 PM, Terry Burton wrote:
> On Thu, 20 Aug 2020 at 13:34, Mohit Sethi M
>  wrote:
> <...snip...>
>> It's also contrary to...
>>
>>Type zero (0) is used to indicate that the sender has
>>no viable alternatives, and therefore the authenticator SHOULD NOT
>>send another Request after receiving a Nak Response containing a
>>zero value.
>>
>>  unless the language is loose and we say that an EAP-Failure
>> request isn't actually a "Request", but that's hard to argue due to
>> capital "R"equest.
>>
>> Why is EAP-Failure a request? It's an EAP packet with a different Code? So 
>> the SHOULD NOT doesn't forbid the server from sending an EAP-Failure. RFC 
>> 3748 even calls Failure as a response: "An authenticator MAY wish to issue 
>> multiple Requests before sending a Failure response in order to allow for 
>> human typing mistakes."
> That's a small "r"esponse and I'd dare to say that even that usage
> isn't particularly helpful! :-)
>
> I think it's well established that any message from the authenticator
> to the peer (Code = 1) is an "R"equest and that any message from the
> peer to the authenticator (Code = 2) is an EAP "R"esponse. NAK is just
> a "Type" of Request / Response (depending on direction). So when the
> above text mentions "R"equest it actually refers to EAP packets with
> Code = 1, i.e. it says (seemingly erroneously as Alan points out) that
> no further messages of any type should be sent from the authenticator
> to the peer within the conversation.

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


Re: [Emu] Appropriate AAA/EAP response to a peer's NAK when there are no overlapping methods

2020-08-20 Thread Mohit Sethi M
Hi Terry,

On 8/20/20 3:02 PM, Terry Burton wrote:

On Thu, 20 Aug 2020 at 10:00, Mohit Sethi M
<mailto:mohit.m.sethi=40ericsson@dmarc.ietf.org>
 wrote:


I surely must be missing something here:

Packet 6 is an EAP-Response from the peer. Packet 7 contains another 
EAP-Response inside a RADIUS Access-Request? That doesn't make sense. EAP is 
lock-step request-response protocol. The conversation you describe is incorrect.



Hi,

Maybe you were thrown by my typo (to make sure readers were awake). It
should have read "6. Peer --> NAS", i.e.:

Indeed. I misread the packet sequence to imply that the server was sending an 
EAP-Response (which is why I had a disclaimer at the beginning :)).



6. Peer --> NAS: EAP-Response / EAP-Type=NAK (Methods [Bar])
7. NAS --> AAA: RADIUS Access-Request / EAP-Message / EAP-Response /
NAK ( Methods [ Bar ] )

Packet 7 is just the NAS encapsulating the Peer's NAK within RADIUS
for the AAA, not a separately originating request. The language is the
same as the fourth example in RFC 3579 Appendix A, however that
example skips the identity phase and goes on to successfully negotiate
a method.



My reading of RFC 3748 is clear that after receiving a NAK from the peer, the 
server should send another EAP-Request with a different EAP method if its 
policy allows or then send a failure. The server should also send a failure if 
the peer NAK Type-Data was 0 (indicating no proposed alternative).



I'm still not seeing a clear reference for what to send in the event
of no overlapping methods from the text in these RFCs.



FYI: RFC 4137 says:

   o  Sending a NAK to the authenticator after the authenticator first
  proposes an EAP authentication method to the peer.  When the
  methodState variable has the value PROPOSED, the authenticator is
  obliged to process a NAK that is received in response to its first
  packet of an EAP authentication method.

so the commercial RADIUS server is in violation if it doesn't respond to a NAK 
from the peer with either another EAP-Request or failure.



That's relevant in the sense that it restates that it is appropriate
for a peer to NAK the server's original method selection and that the
server must process the NAK. It doesn't state what happens on the wire
(specifically that an EAP-Failure is sent to the peer, as seems to be
the case in practise) as a result of this processing.

It's also contrary to...



  Type zero (0) is used to indicate that the sender has
  no viable alternatives, and therefore the authenticator SHOULD NOT
  send another Request after receiving a Nak Response containing a
  zero value.



 unless the language is loose and we say that an EAP-Failure
request isn't actually a "Request", but that's hard to argue due to
capital "R"equest.

Why is EAP-Failure a request? It's an EAP packet with a different Code? So the 
SHOULD NOT doesn't forbid the server from sending an EAP-Failure. RFC 3748 even 
calls Failure as a response: "An authenticator MAY wish to issue multiple 
Requests before sending a Failure response in order to allow for human typing 
mistakes."



Nevertheless, RFC 4137 Appendix A.2. and A.3. is clear on what to do:

* When the peer sends a NAK with no alternatives we are in RECEIVED.
* In RECEIVED: respMethod == NAK therefore we transition to NAK.
* In NAK: We update the policy to exclude the NAKed method and
transition to SELECT_ACTION.
* In SELECT_ACTION: the result of Policy.getDecision() is presumably
FAILURE for no overlapping methods. Transition to FAILURE.
* In FAILURE: We build a failure response.

I note that both receiving a NAK (RECEIVED -> NAK -> SELECT_ACTION ->
FAILURE transition) and receiving an unacceptable method response
(RECEIVED -> INTEGRITY_CHECK -> METHOD_RESPONSE -> SELECT_ACTION
transition) ultimately arrive at the same FAILURE state that builds a
EAP-Failure packet. It appears that the agreed upon behaviour is
codified here.

Its behaviour also does not differentiate between a peer NAK of "type
0" and one containing a list of alternative methods.

This seems to be the correct behavior (at least for me).

--Mohit




Terry




On 8/20/20 3:39 AM, Terry Burton wrote:

Hi,

I'm unable to find the authoritative source that state exactly how the
following conversation continues (TL;DR; the peer NAKs the original
method and the AAA doesn't support any of the peer's proposals):

1. NAS --> Peer : EAP-Request / Identity
2. Peer --> NAS : EAP-Response / Identity ( ID )
3. NAS --> AAA: RADIUS Access-Request / EAP-Message / EAP-Response /
Identity ( ID )
4. AAA --> NAS:  RADIUS Access-Challenge / EAP-Message / EAP-Request /
Method Foo
5. NAS --> Peer: EAP-Request / Method Foo
6. Peer --> NAK: EAP-Response / EAP-Type=NAK (Methods [Bar])
7. NAS --> AAA: RADIUS Access-Request / EAP-Message / EAP-Response /
NAK ( Methods [ Bar ] )
(* Let's assume that the AAA

Re: [Emu] Appropriate AAA/EAP response to a peer's NAK when there are no overlapping methods

2020-08-20 Thread Mohit Sethi M
Hi Terry,

I surely must be missing something here:

Packet 6 is an EAP-Response from the peer. Packet 7 contains another 
EAP-Response inside a RADIUS Access-Request? That doesn't make sense. EAP is 
lock-step request-response protocol. The conversation you describe is incorrect.

My reading of RFC 3748 is clear that after receiving a NAK from the peer, the 
server should send another EAP-Request with a different EAP method if its 
policy allows or then send a failure. The server should also send a failure if 
the peer NAK Type-Data was 0 (indicating no proposed alternative).

FYI: RFC 4137 says:

   o  Sending a NAK to the authenticator after the authenticator first
  proposes an EAP authentication method to the peer.  When the
  methodState variable has the value PROPOSED, the authenticator is
  obliged to process a NAK that is received in response to its first
  packet of an EAP authentication method.

so the commercial RADIUS server is in violation if it doesn't respond to a NAK 
from the peer with either another EAP-Request or failure.

--Mohit


On 8/20/20 3:39 AM, Terry Burton wrote:

Hi,

I'm unable to find the authoritative source that state exactly how the
following conversation continues (TL;DR; the peer NAKs the original
method and the AAA doesn't support any of the peer's proposals):

1. NAS --> Peer : EAP-Request / Identity
2. Peer --> NAS : EAP-Response / Identity ( ID )
3. NAS --> AAA: RADIUS Access-Request / EAP-Message / EAP-Response /
Identity ( ID )
4. AAA --> NAS:  RADIUS Access-Challenge / EAP-Message / EAP-Request /
Method Foo
5. NAS --> Peer: EAP-Request / Method Foo
6. Peer --> NAK: EAP-Response / EAP-Type=NAK (Methods [Bar])
7. NAS --> AAA: RADIUS Access-Request / EAP-Message / EAP-Response /
NAK ( Methods [ Bar ] )
(* Let's assume that the AAA does not support Method Bar so we have
derived that there are no overlapping methods.)
8. AAA: Now what?

I've reviewed RFC 3748 (EAP) and RFC 3579 (RADIUS Support For EAP) and
neither seems to be explicit about what the AAA should do in response
to a NAK in the event of no overlapping methods.

In practise:

* FreeRADIUS sends RADIUS Access-Reject / EAP-Message / EAP-Failure.
* hostapd's RADIUS server sends RADIUS Access-Reject / EAP-Message /
EAP-Failure.
* A commercial RADIUS server implementation sends nothing.

It seems right to indicate an EAP-Failure to the peer in the case of
no overlapping methods (as well as to terminate the NAS's outstanding
RADIUS Access-Request with an Access-Reject), as is the case for a
number of other failure conditions, e.g. authentication failure
*within* an EAP method (Appendix A by way of example), invalid packets
leading to a fatal error within an EAP method (section 2.2).

RFC 3748 section 4.2 on Success and Failure introduces these messages
within the context of finalising an ongoing EAP method:

   The Success packet is sent by the authenticator to the peer after
   completion of an EAP authentication method (Type 4 or greater) to
   indicate that the peer has authenticated successfully to the
   authenticator.  The authenticator MUST transmit an EAP packet with
   the Code field set to 3 (Success).  If the authenticator cannot
   authenticate the peer (unacceptable Responses to one or more
   Requests), then after unsuccessful completion of the EAP method in
   progress, the implementation MUST transmit an EAP packet with the
   Code field set to 4 (Failure).

Perhaps one can argue that a NAK is an unacceptable response to an
ongoing method and therefore the method is unsuccessfully completed so
a Failure should be generated? That's not entirely clear, if that is
the case.

RFC 3748 section 5.3.1 throws in some more doubt, having the following
text that deals explicitly with the peer sending a NAK containing "no
desired alternative" method:

  Type zero (0) is used to indicate that the sender has
  no viable alternatives, and therefore the authenticator SHOULD NOT
  send another Request after receiving a Nak Response containing a
  zero value.

That's specific to one case for which a strict reading would indicate
that the EAP server should remain quiet and consider the EAP
conversation to be complete. It's tempting to think that the same
response (i,e. no response!) should apply more broadly as none of the
AAA implementations I've tested actually differentiate between a NAK
with no desired alternative method vs a NAK with an incompatible list
of alternative methods. (A subtle difference might be relevant: In the
case of NAK / method = [] the peer knows that the EAP conversion can
go no further, whereas in the case that it sends a list of methods
that the AAA happens to not support it does not know this unless it is
subsequently told.)

If I've not missed something then this looks an omission (or lack of
clarity) and the intended AAA response to no overlapping methods (and
indeed "no desired alternative") should be decided and codified.


Thanks,

Terry


Re: [Emu] draft-ietf-emu-eap-tls13: Client re-validation of server authority information during resumption

2020-08-12 Thread Mohit Sethi M
Hi Alan and Terry,

Thank you again for the feedback. I have updated the text in github:
https://emu-wg.github.io/draft-ietf-emu-eap-tls13/draft-ietf-emu-eap-tls13.html#rfc.section.5.7

Here is the diff for your convenience:
https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-emu-eap-tls13.txt=https://emu-wg.github.io/draft-ietf-emu-eap-tls13/draft-ietf-emu-eap-tls13.txt

We'll submit the new version once we have sufficient implementation 
experience with the use of the close_notify alert.

--Mohit

On 8/11/20 5:57 PM, Alan DeKok wrote:
> On Aug 11, 2020, at 8:40 AM, Terry Burton  wrote:
>> On Tue, 11 Aug 2020 at 09:11, Mohit Sethi M  
>> wrote:
>>> Section 5.7  "Resumption" says:
>>>
>>>> When resumption occurs, it is based on cached information at the TLS
>>>>layer.  To perform resumption in a secure way, the EAP-TLS peer and
>>>>EAP-TLS server need to be able to securely retrieve authorization
>>>>information such as certificate chains from the initial full
>>>>handshake.
>Is there more information which needs to be cached?  If so, are there 
> examples?
>
>>> In the second mechanism, the server can avoid storing information. It
>>> instead puts that information in the PSK or the session ticket and sends
>>> it to the client. However, the client still needs to store information
>>> from the original handshake. This is why there is the sentence "Note
>>> that the client still needs to cache the information locally.". The
>>> client can't obviously read the contents of the ticket or the PSK.
>> I agree with the sentiment, but the current text seems a bit
>> "Sherlock": Once you've eliminated all other possibilities whatever
>> remains must be the case. I think it should directly state that the
>> client uses the opaque ticket or PSK as a key to identify the cached
>> information corresponding to the original session. Whereas the server
>> may use the decoded content of the ticket or PSK to achieve the goal
>> of remaining stateless.
>I agree.  It's a minor point, but clarifying it is helpful.
>
>> Aside: The latter part might be obvious since shifting the burden of
>> storing the server-side state from the server to the client is the
>> whole point of ticket/PSK schemes. However it's not obvious to me that
>> the additional goal introduced by this RFC of performing a deep
>> revalidation of the authorisation data (resume-time certificate
>> checks, etc.) is shared with the RFC5077 or RFC8446 whose concern
>> appears to be with lightweight bootstrapping of the connection using
>> the original parameters. (Maybe I have missed something?) If that's
>> true then as Alan mentions, perhaps it is worth enumerating the types
>> of information that should be stored in the ticket to facilitate the
>> resume-time authorisation check rather than merely to reestablish the
>> crypto parameters required to perform an abbreviated handshake?
> Just re-checking 5.7, it should also have a discussion on expiring the 
> cached data.  How long should it be cached for on each side?  I'd like to see 
> some discussion.
>
>My $0.02 is that the cached data MUST expire no later than the expiry time 
> of any certificate involved.  i.e. client, server, or any cert in the CA 
> chain.
>
>Perhaps it would also be good to suggest that expiry times SHOULD be no 
> longer than 48h?
>
>I also note:
>
> The above requirements also apply if the EAP server expects some
> system to perform accounting for the session.  Since accounting must
> be tied to an authenticated identity, and resumption does not supply
> such an identity, accounting is impossible without access to cached
> data.
>
>It would be good to add a sentence such as:
>
>   Therefore systems which expect to perform accounting for the session 
> SHOULD cache an identifier which can be used in subsequent accounting.
>
>In RADIUS, this would involve sending back User-Name or CUI in the 
> Access-Accept.
>
>Alan DeKok.
>
> ___
> 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


Re: [Emu] draft-ietf-emu-eap-tls13: Client re-validation of server authority information during resumption

2020-08-11 Thread Mohit Sethi M
Hi Terry,

Section 5.7  "Resumption" says:

> When resumption occurs, it is based on cached information at the TLS
>    layer.  To perform resumption in a secure way, the EAP-TLS peer and
>    EAP-TLS server need to be able to securely retrieve authorization
>    information such as certificate chains from the initial full
>    handshake.  We use the term "cached data" to describe such
>    information.  Authorization during resumption MUST be based on such
>    cached data.  The EAP peer and sever MAY perform fresh revocation
>    checks on the cached certificate data. 

This text indicates what needs to be cached and seems pretty clear to me.

The next question is how to lookup the cached information. This is what 
the text says currently:

>    There are two ways to retrieve the cached information from the
>    original full handshake.  The first method is that the TLS server and
>    client cache the information locally.  The cached information is
>    identified by an identifier.  For TLS versions before 1.3, the
>    identifier can be the session ID, for TLS 1.3, the identifier is the
>    PSK identity.  The second method for retrieving cached information is
>    via [RFC5077] or [RFC8446], where the TLS server encapsulates the
>    information into a ticket and sends it to the client.  The client can
>    subsequently do resumption using the obtained ticket.  Note that the
>    client still needs to cache the information locally.  The following
>    requirements apply to both methods.
The first mechanism is obvious, both sides store the information from 
the initial handshake and lookup using the Session ID or the PSK identity.

In the second mechanism, the server can avoid storing information. It 
instead puts that information in the PSK or the session ticket and sends 
it to the client. However, the client still needs to store information 
from the original handshake. This is why there is the sentence "Note 
that the client still needs to cache the information locally.". The 
client can't obviously read the contents of the ticket or the PSK.

Do you have some concrete suggestion on improving the text? We are happy 
to edit or receive pull requests on github: 
https://github.com/emu-wg/draft-ietf-emu-eap-tls13

Would this be better:

>  The second method for retrieving cached information is
>    via [RFC5077] or [RFC8446], where the TLS server avoids storing
>    information locally and instead encapsulates the information into a
>    ticket or PSK and sends it to the client.  Note that the client still
>    needs to cache the information locally.  The client can subsequently
>    do resumption using the obtained ticket. 
--Mohit

On 8/10/20 6:58 PM, Terry Burton wrote:
> Hi,
>
> Reading "Using EAP-TLS with TLS 1.3" I find the text potentially
> misleading when it comes to resumption within TLS 1.3, specifically
> for the case where the peer wishes to re-validate the certificate
> originally provided by the server during the initial handshake using
> only its locally cached data and without redoing the handshake, e.g.
> to determine that the original certificate hasn't expired or been
> revoked.
>
>
> 5.7.  Resumption
> ...
> To perform resumption in a secure way, the EAP-TLS peer and
> EAP-TLS server need to be able to securely retrieve authorization
> information such as certificate chains from the initial full
> handshake.
> ...
> There are two ways to retrieve the cached information from the
> original full handshake.
> ...
> The second method for retrieving cached information is
> via [RFC5077] or [RFC8446], where the TLS server encapsulates the
> information into a ticket and sends it to the client.  The client can
> subsequently do resumption using the obtained ticket.  Note that the
> client still needs to cache the information locally.
>
>
> In TLS 1.3, the PSK ticket is defined as being encrypted using a key
> that only the server knows. Even without encryption, the format for
> the ticket is opaque to the client with only a suggested format
> presented in RFC 8446.
>
> How is the original handshake data determined? A casual reading of the
> text seems to imply that the client performs some verification using
> the encapsulated information within the ticket.
>
> However I believe that the intent is to use the full PSK blob, or some
> digest thereof, as a key to lookup the corresponding cached handshake
> data.
>
> Perhaps this could be made clearer?
>
>
> Thanks,
>
> Terry
>
> ___
> 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


Re: [Emu] Commitment Message handling in EAP-TLS 1.3

2020-08-05 Thread Mohit Sethi M
I seem to agree with the consensus around the usage of close_notify 
instead of a byte of 0x00. In fact, I can't even remember the reason for 
that choice anymore.

The draft is now updated in github to specify the usage of close_notify:
https://github.com/emu-wg/draft-ietf-emu-eap-tls13

Here is the diff for your convenience:

https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-emu-eap-tls13.txt=https://emu-wg.github.io/draft-ietf-emu-eap-tls13/draft-ietf-emu-eap-tls13.txt

This edit probably still requires some sanity checking. I will wait 
until we have confirmation from the different implementations before 
cleaning up and publishing a new version.

--Mohit

On 8/4/20 8:15 PM, Alan DeKok wrote:
> On Aug 3, 2020, at 2:23 PM, Jorge Vergara  wrote:
>> ACK that EAP-TLS does not need to keep the connection open.
>I agree.  I'm happy to change the implementations to send "close notify".
>
>> Question: should some consideration be given to consistency with other EAP 
>> methods that do need to keep the connection open? i.e. PEAP/EAP-TTLS/TEAP
>When those methods send application data, they don't need to do anything 
> else.
>
>When those methods use fast reconnect, they don't send application data.  
> So the other EAP methods should also send "close notify" in that case.
>
>Alan DeKok.
>
> ___
> 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] Commitment Message handling in EAP-TLS 1.3

2020-07-31 Thread Mohit Sethi M
Dear all,

Thanks all for the discussion on the commitment message.

draft-ietf-emu-eap-tls13-10 
(https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-10) in figure 2 shows the 
ticket establishment and commitment message:

EAP Peer  EAP Server

 EAP-Request/
 <  Identity
EAP-Response/
Identity (Privacy-Friendly)  >
 EAP-Request/
EAP-Type=EAP-TLS
 <(TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
   (TLS ClientHello) >
 EAP-Request/
EAP-Type=EAP-TLS
(TLS ServerHello,
 TLS EncryptedExtensions,
  TLS CertificateRequest,
 TLS Certificate,
   TLS CertificateVerify,
 <  TLS Finished)
EAP-Response/
EAP-Type=EAP-TLS
   (TLS Certificate,
TLS CertificateVerify,
TLS Finished)>
 EAP-Request/
EAP-Type=EAP-TLS
   (TLS NewSessionTicket,
 
 <   EAP-Success


and the relevant text on commitment message:

When an EAP server has sent its last handshake message (Finished or a
   Post-Handshake), it commits to not sending any more handshake
   messages by sending a Commitment Message.  The Commitment Message is
   a TLS record with application data 0x00 (i.e. a TLS record with
   TLSPlaintext.type = application_data, TLSPlaintext.length = 1, and
   TLSPlaintext.fragment = 0x00).  Note that the length of the plaintext
   is greater than the corresponding TLSPlaintext.length due to the
   inclusion of TLSInnerPlaintext.type and any padding supplied by the
   sender.  EAP server implementations MUST set TLSPlaintext.fragment to
   0x00, but EAP peer implementations MUST accept any application data
   as a Commitment Message from the EAP server to not send any more
   handshake messages.  The Commitment Message may be sent in the same
   EAP-Request as the last handshake record or in a separate EAP-
   Request.  Sending the Commitment Message in a separate EAP-Request
   adds an additional round-trip, but may be necessary in TLS
   implementations that only implement a subset of TLS 1.3.

I couldn't parse the comments about the "KeyUpdate" message. Perhaps having the 
discussion over email will help me understand the issue.

--Mohit

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


[Emu] Minutes from EMU @ IETF108

2020-07-31 Thread Mohit Sethi M
Dear all,

Thank you for participating in the EMU session at IETF 108. A special 
thank you to Aleksi Peltonen for serving as the note taker.

Minutes from the EMU session at IETF 108 have now been uploaded:
https://datatracker.ietf.org/doc/minutes-108-emu/

Please report any issues by August 10, 2020.

Joe and Mohit

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


[Emu] Preparations for Friday

2020-07-28 Thread Mohit Sethi M
Dear all,

Instead of the usual 120 minutes, we have a 50 minute session for EMU @ 
IETF 108 on Friday, July 31st. Here is our current agenda for the meeting:
https://datatracker.ietf.org/doc/agenda-108-emu/

As you notice, the agenda is rather packed. There is no possibility to 
extend the duration of the session and we intend to make a hard stop 
after 50 minutes.

Therefore, we strongly recommend all of you to familiarize yourself with 
meetecho: 
https://www.ietf.org/how/meetings/108/session-participant-guide/. This 
will hopefully ensure that we don't have any teething issues on Friday. 
Some of the meetecho controls are not obvious:

- Enter video queue != Enter audio queue. You have to request both if 
you want to share both audio and video.
- Instead of mute/unmute, the tool uses send audio/stop audio.

You can also use the meetecho test environment here: 
https://gce.conf.meetecho.com/conference/?group=prova.

We also encourage you to read the drafts (and related mailing list 
discussions) before Friday.

Joe and Mohit


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


[Emu] Finishing draft-ietf-emu-eap-tls13 - Commitment Message handling

2020-07-13 Thread Mohit Sethi M
Dear all,

draft-ietf-emu-eap-tls13 is currently in the state "AD Evaluation::AD 
Followup". Our AD (Roman) had done an excellent review 
(https://mailarchive.ietf.org/arch/msg/emu/k6K98OhuOQmbzSAgGWCtSIVv3Qk/), which 
I addressed in version 10 
(https://mailarchive.ietf.org/arch/msg/emu/IopJTjefyVVKpObzyFc0CAJ-Pig/).

The only outstanding issue is the handling of the commitment message. The 
current text in the draft says the following:

   When an EAP server has sent its last handshake message (Finished or a
   Post-Handshake), it commits to not sending any more handshake
   messages by sending a Commitment Message.  The Commitment Message is
   a TLS record with application data 0x00 (i.e. a TLS record with
   TLSPlaintext.type = application_data, TLSPlaintext.length = 1, and
   TLSPlaintext.fragment = 0x00).  Note that the length of the plaintext
   is greater than the corresponding TLSPlaintext.length due to the
   inclusion of TLSInnerPlaintext.type and any padding supplied by the
   sender.  EAP server implementations MUST set TLSPlaintext.fragment to
   0x00, but EAP peer implementations MUST accept any application data
   as a Commitment Message from the EAP server to not send any more
   handshake messages.  The Commitment Message may be sent in the same
   EAP-Request as the last handshake record or in a separate EAP-
   Request.  Sending the Commitment Message in a separate EAP-Request
   adds an additional round-trip, but may be necessary in TLS
   implementations that only implement a subset of TLS 1.3.

Hannes says that this is not ideal and cannot be achieved with mbed TLS 1.3 
implementation. He made 3 alternative suggestions for achieving the 
functionality of the commitment message 
(https://mailarchive.ietf.org/arch/msg/emu/eM-14QdDQjg7DvhAVJMzpvPz5wg/).

I would like to close this issue and would like to receive feedback from others 
who have commented before or are working on implementations: Jim, Alan, Jouni; 
please let us know what do you think about the change?

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


Re: [Emu] [Iot-directorate] Iotdir early review of draft-ietf-emu-eap-noob-01

2020-07-11 Thread Mohit Sethi M
Thanks Carsten. This is very valuable input for the working group before 
it makes a critical decision.

--Mohit

On 7/11/20 4:40 PM, Carsten Bormann wrote:
> Hi Mohit,
>
>
>> On 2020-07-11, at 15:27, Mohit Sethi M 
>>  wrote:
>>
>> Hi Michael,
>>
>> Thanks for the input. This is indeed something we should discuss at the 
>> upcoming virtual EMU meeting.
>>
>> Some colleagues (Ingles Sanchez et al.) have also investigated and 
>> documented the savings that might result from the use of CBOR in EAP-NOOB: 
>> https://hal.archives-ouvertes.fr/hal-02880326/document
> That paper simply translates a JSON-like structure into CBOR, without using 
> any of the additional benefits of using CBOR (e.g., numeric map labels).
> So I would expect the benefits of moving to CBOR to be larger than described 
> in this paper.
>
>> EAP-NOOB also relies on the JWK specification for encoding public keys. 
>> While CBOR equivalent is defined in RFC 8152, it is a rather large document 
>> that contains all the functionality of JWK, JWS, JWA (as far as I 
>> understand). Following smaller modular specifications was somehow easier at 
>> the time.
> RFC 8152 does have a section structure, so you don’t need to read all of it 
> to just get the equivalent of JWK.
>
>> What is more important is that wpa_supplicant currently has a JSON encoder 
>> and parser 
>> (https://protect2.fireeye.com/v1/url?k=be5e912f-e0fe3fe2-be5ed1b4-866132fe445e-d1e084c426bf1ae9=1=3870678c-1f3b-4f09-8cde-269a88395e80=https%3A%2F%2Fw1.fi%2Fcgit%2Fhostap%2Ftree%2Fsrc%2Futils%2Fjson.c).
>>  I think you would agree that wpa_supplicant is probably the most important 
>> tool for those using EAP (at least on 802.11).
>>
>> One could use an external library since there are many CBOR implementations 
>> available: 
>> https://protect2.fireeye.com/v1/url?k=e6a1854a-b8012b87-e6a1c5d1-866132fe445e-29d16d211c0fc3e9=1=3870678c-1f3b-4f09-8cde-269a88395e80=https%3A%2F%2Fcbor.io%2Fimpls.html.
>>  However this has two major downsides:
>>
>> - Adding an external library dependency implies that the overall system 
>> becomes more brittle.
> To the contrary.  An implementation of JSON just for one application is 
> likely to have received less testing and overall development attention than 
> an industrial-strength library.  If you for some reason don’t agree with 
> that, you can always create another CBOR implementation in an afternoon :-)
>
>> - Updating and maintaining two components is definitely harder than one.
> Not sure I follow.
>
>> As said, this is worth discussing at the meeting since it would result in a 
>> large change to the existing EAP-NOOB implementations.
> Certainly!
> I just wanted to make sure you don’t make your decision for the wrong reasons.
>
> Grüße, Carsten
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] [Iot-directorate] Iotdir early review of draft-ietf-emu-eap-noob-01

2020-07-11 Thread Mohit Sethi M
Hi Michael,

Thanks for the input. This is indeed something we should discuss at the 
upcoming virtual EMU meeting.

Some colleagues (Ingles Sanchez et al.) have also investigated and documented 
the savings that might result from the use of CBOR in EAP-NOOB: 
https://hal.archives-ouvertes.fr/hal-02880326/document

EAP-NOOB also relies on the JWK specification for encoding public keys. While 
CBOR equivalent is defined in RFC 8152, it is a rather large document that 
contains all the functionality of JWK, JWS, JWA (as far as I understand). 
Following smaller modular specifications was somehow easier at the time.

What is more important is that wpa_supplicant currently has a JSON encoder and 
parser (https://w1.fi/cgit/hostap/tree/src/utils/json.c). I think you would 
agree that wpa_supplicant is probably the most important tool for those using 
EAP (at least on 802.11).

One could use an external library since there are many CBOR implementations 
available: https://cbor.io/impls.html. However this has two major downsides:

- Adding an external library dependency implies that the overall system becomes 
more brittle.
- Updating and maintaining two components is definitely harder than one.

As said, this is worth discussing at the meeting since it would result in a 
large change to the existing EAP-NOOB implementations.

--Mohit


On 7/8/20 8:12 PM, Michael Richardson wrote:


Speaking as a WG participant.

Dave Thaler via Datatracker  wrote:
> 3) Section 3.3.2 says:
>> The in-band messages are formatted as JSON objects [RFC8259]

> So this limits applicability to constrained IoT devices, since JSON can be
> verbose compared to, say, CBOR, and if the IoT device already uses CBOR 
for
> its normal protocol use this requires adding a separate parser for JSON 
which
> may cause code size issues.   Is there a rationale for why CBOR could not 
be
> an option?  E.g., if this protocol is not applicable for constrained 
devices,
> then say so.  (I don’t know whether EAP itself already inherently has
> problems that limit its applicability for constrained devices.)

I think that the document predates widespread availability of CBOR :-)
I think that it would benefit from only using CBOR, as CBOR works into EAP
much better than I think JSON does.
That would be a radical change, but the document as only just been adopted by
the EMU WG.

To the extent that EAP is used more on 802.11 rather than 802.15.4 [not that
you can't do EAP/1x on 15.4, it just hasn't caught on], IoT devices that have
power budget for WiFi can generally do EAP.  There is a large variety of
arduino class devices running FreeRTOS+micropython, for instance, which
already have EAP supplicants.

CBOR would be easier for them in the C code parts of them, while if the
EAP-NOOB were to involve the python code (for callbacks, etc.) it wouldn't
matter much as whether JSON or CBOR, it would likely be presented as python
dict() anyway.

Where there is a problem is a slightly smaller class of device which use
various WiFi *MODULES*.  Usually the microcontroller speaks i2c to this
module, and the module takes care of all the TCP/IP/Ethernet/WiFi stuff.
Those devices do not use EAP today, and they are hard to upgrade.
(and from a security point of view, those architectures concern me greatly)

--
Michael Richardson , 
Sandelman Software Works
 -= IPv6 IoT consulting =-







___
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


Re: [Emu] I-D Action: draft-ietf-emu-aka-pfs-04.txt

2020-07-09 Thread Mohit Sethi M
Arghh. I feel very protected with unreadable URLs of fireeye. Fixed pointer to 
the reference:

https://www.secg.org/SEC2-Ver-1.0.pdf

The relevant section is 2.7.1.

--Mohit

On 7/9/20 9:45 AM, Mohit Sethi M wrote:

Rene, Russ, and I had an offline email exchange about this issue. I think we 
are now in agreement that the public key for the NIST P-256 curve requires at 
least 33 bytes (in the compressed format).

Thus, we should update the draft to reflect the correct key size. Adding a 
reference to 
https://www.secg.org/SEC2-Ver-1.0.pdf<https://protect2.fireeye.com/v1/url?k=ee7f4584-b0df87c2-ee7f051f-86fc6812c361-2b60805fe723aebc=1=8fc33e3e-797f-4645-8a58-9177a3822ce7=https%3A%2F%2Fwww.secg.org%2FSEC2-Ver-1.0.pdf>
 and explicitly mentioning the use of the compressed format would also be 
beneficial.

--Mohit

On 6/24/20 11:04 PM, Russ Housley wrote:

The ECDH public value in RFC 5480 is an OCTET STRING, which means that the 
value is exactly 32 bytes.  When this gets carried as a subject public key in a 
certificate, there is an extra byte only because the type is a BIT STRING.

My conclusion is that the current draft is correct:

  *  For P-256, the length of this value is 32 bytes, encoded in
 binary as specified in [FIPS186-4].

Russ





On Jun 24, 2020, at 1:10 AM, Mohit Sethi M 
<mailto:mohit.m.sethi=40ericsson@dmarc.ietf.org>
 wrote:

Hi all,

I am not a crypto expert and my knowledge of public key encodings is
based on my work with Rene Struik for a different draft.

The current text in draft-ietf-emu-aka-pfs-04 says "For P-256, the
length of this value is 32 bytes, encoded in binary". Shouldn't this be
33 bytes? And wouldn't it make sense to explicitly say that this is an
octet string in the compressed format while referencing "SEC 1: Elliptic
Curve Cryptography, Version 2.0" for the point to octet string
conversion rules?

--Mohit

On 5/26/20 9:57 AM, internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> 
wrote:


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   : Perfect-Forward Secrecy for the Extensible 
Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' 
PFS)
Authors : Jari Arkko
  Karl Norrman
  Vesa Torvinen
Filename: draft-ietf-emu-aka-pfs-04.txt
Pages   : 26
Date: 2020-05-25

Abstract:
   Many different attacks have been reported as part of revelations
   associated with pervasive surveillance.  Some of the reported attacks
   involved compromising smart cards, such as attacking SIM card
   manufacturers and operators in an effort to compromise shared secrets
   stored on these cards.  Since the publication of those reports,
   manufacturing and provisioning processes have gained much scrutiny
   and have improved.  However, the danger of resourceful attackers for
   these systems is still a concern.

   This specification is an optional extension to the EAP-AKA'
   authentication method which was defined in [I-D.ietf-emu-rfc5448bis].
   The extension, when negotiated, provides Perfect Forward Secrecy for
   the session key generated as a part of the authentication run in EAP-
   AKA'.  This prevents an attacker who has gained access to the long-
   term pre-shared secret in a SIM card from being able to decrypt any
   past communications.  In addition, if the attacker stays merely a
   passive eavesdropper, the extension prevents attacks against future
   sessions.  This forces attackers to use active attacks instead.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-emu-aka-pfs/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-emu-aka-pfs-04
https://datatracker.ietf.org/doc/html/draft-ietf-emu-aka-pfs-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-aka-pfs-04


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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


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


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




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


Re: [Emu] I-D Action: draft-ietf-emu-aka-pfs-04.txt

2020-07-09 Thread Mohit Sethi M
Rene, Russ, and I had an offline email exchange about this issue. I think we 
are now in agreement that the public key for the NIST P-256 curve requires at 
least 33 bytes (in the compressed format).

Thus, we should update the draft to reflect the correct key size. Adding a 
reference to 
https://www.secg.org/SEC2-Ver-1.0.pdf<https://protect2.fireeye.com/v1/url?k=ee7f4584-b0df87c2-ee7f051f-86fc6812c361-2b60805fe723aebc=1=8fc33e3e-797f-4645-8a58-9177a3822ce7=https%3A%2F%2Fwww.secg.org%2FSEC2-Ver-1.0.pdf>
 and explicitly mentioning the use of the compressed format would also be 
beneficial.

--Mohit

On 6/24/20 11:04 PM, Russ Housley wrote:

The ECDH public value in RFC 5480 is an OCTET STRING, which means that the 
value is exactly 32 bytes.  When this gets carried as a subject public key in a 
certificate, there is an extra byte only because the type is a BIT STRING.

My conclusion is that the current draft is correct:

  *  For P-256, the length of this value is 32 bytes, encoded in
 binary as specified in [FIPS186-4].

Russ





On Jun 24, 2020, at 1:10 AM, Mohit Sethi M 
<mailto:mohit.m.sethi=40ericsson@dmarc.ietf.org>
 wrote:

Hi all,

I am not a crypto expert and my knowledge of public key encodings is
based on my work with Rene Struik for a different draft.

The current text in draft-ietf-emu-aka-pfs-04 says "For P-256, the
length of this value is 32 bytes, encoded in binary". Shouldn't this be
33 bytes? And wouldn't it make sense to explicitly say that this is an
octet string in the compressed format while referencing "SEC 1: Elliptic
Curve Cryptography, Version 2.0" for the point to octet string
conversion rules?

--Mohit

On 5/26/20 9:57 AM, internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> 
wrote:


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   : Perfect-Forward Secrecy for the Extensible 
Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' 
PFS)
Authors : Jari Arkko
  Karl Norrman
  Vesa Torvinen
Filename: draft-ietf-emu-aka-pfs-04.txt
Pages   : 26
Date: 2020-05-25

Abstract:
   Many different attacks have been reported as part of revelations
   associated with pervasive surveillance.  Some of the reported attacks
   involved compromising smart cards, such as attacking SIM card
   manufacturers and operators in an effort to compromise shared secrets
   stored on these cards.  Since the publication of those reports,
   manufacturing and provisioning processes have gained much scrutiny
   and have improved.  However, the danger of resourceful attackers for
   these systems is still a concern.

   This specification is an optional extension to the EAP-AKA'
   authentication method which was defined in [I-D.ietf-emu-rfc5448bis].
   The extension, when negotiated, provides Perfect Forward Secrecy for
   the session key generated as a part of the authentication run in EAP-
   AKA'.  This prevents an attacker who has gained access to the long-
   term pre-shared secret in a SIM card from being able to decrypt any
   past communications.  In addition, if the attacker stays merely a
   passive eavesdropper, the extension prevents attacks against future
   sessions.  This forces attackers to use active attacks instead.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-emu-aka-pfs/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-emu-aka-pfs-04
https://datatracker.ietf.org/doc/html/draft-ietf-emu-aka-pfs-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-aka-pfs-04


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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


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



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

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


[Emu] Agenda Items for IETF 108

2020-07-08 Thread Mohit Sethi M
Dear all,

At the virtual IETF 108 meeting, we will have a 50 minute session on 
Friday, July 31, between 13:00 - 13:50 UTC.

Please send Joe and I (emu-cha...@ietf.org) requests for presentation 
slots.

Don't forget to include the title of your presentation, related drafts, 
and the approximate amount of time needed.

Joe and Mohit

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


Re: [Emu] draft-ietf-emu-eap-noob-01 incorrect curve name in example messages

2020-07-07 Thread Mohit Sethi M
Hi Max,

Good catch. This will be fixed in the next version!

--Mohit

On 7/3/20 12:21 PM, Max Crone wrote:
> Hi,
>
> I noticed that the examples messages in Appendix F 
> (https://tools.ietf.org/html/draft-ietf-emu-eap-noob-01#appendix-F) 
> use the curve name "Curve25519" in the JWK object. However, according 
> to the IANA registry 
> (https://www.iana.org/assignments/jose/jose.xhtml#web-key-elliptic-curve), 
> the curve name should be "X25519".
>
> In the implementation I am working on I will thus use the latter, 
> trusting that the draft will update to conform to the IANA registry.
>
> With kind regards,
>
> Max Crone
>
> ___
> 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


Re: [Emu] Secdir early review of draft-ietf-emu-eap-noob-01

2020-07-02 Thread Mohit Sethi M
Hi Steve,

I have answered each question in-line.

On 6/29/20 2:54 AM, Steve Hanna via Datatracker wrote:
> Reviewer: Steve Hanna
> Review result: Not Ready
>
> Reviewer: Steve Hanna
> Review result: Not Ready
>
> I have reviewed this document as part of the security directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written primarily for the benefit of the security area 
> directors.
>   Document editors and WG chairs should treat these comments just like any 
> other
> last call comments.
>
> This document defines a new EAP method for bootstrapping IoT devices.
>
> After reading the document, I have many questions:
>
> * Bootstrapping an IoT device involves many tasks that extend far beyond what
> is accomplished by EAP-NOOB: configuring the services that the device
> can/should employ within its new context (including how to reach and
> authenticate them), the networks and protocols that it should use and how it
> should obtain access to those networks, the access control policies that it
> should use (who is permitted to access the device and what operations can they
> perform), as well as many other configuration elements such as which lights a
> switch should control. The current document does not specify how such things
> are provisioned or even hint at this as an important problem. Without
> specifying such things, only a tiny part of the IoT device configuration
> problem has been solved. Perhaps another provisioning protocol could be used
> after EAP-NOOB but that protocol would need to be specified. With this extra
> step would come more complexity and user effort. Why not do this all with one
> protocol?

That's not how the Internet or standardization works.

Why stop here with the requirements. Maybe EAP-NOOB should also address 
how the software on these devices is updated since that is a necessary 
precursor to updating the elliptic curves used by the protocol. Maybe 
EAP-NOOB should also ensure quantum resistance since quantum computers 
will be available any day. Maybe EAP-NOOB should also periodically 
provide verifiable device health reports after the initial configuration 
is complete.

The point I am trying to make here is that there needs to be a careful 
balance between salami style protocol knick knacks that don't fit 
together and a gargantuan all encompassing protocol that is never 
completed (or deployed).

There are over 52 EAP authentication methods. Can you name one which 
also provisions access control policies for resources on the peer 
device. The answer would be a clear no. There is a reason for that. We 
have other protocols to deal with access control policies. For IoT 
devices, we have ACE (Authentication and Authorization for Constrained 
Environments: https://datatracker.ietf.org/wg/ace/charter/) doing that 
work.

You talk about configuring what protocols the IoT device should use 
after obtaining initial network connectivity? I wonder what kind of 
imaginary IoT devices have multiple protocols implemented (for doing the 
same job) that would require some sort of selection.

EAP-NOOB does export a AMSK after successful authentication. Whether 
this AMSK is used for configuring access control policies or for 
protecting higher-layer protocols is up to other protocol specifications 
and device developers. EAP-NOOB also includes exchange of protected 
ServerInfo and PeerInfo JSON objects that can supply deployment specific 
configuration information. Appendix C 
(https://tools.ietf.org/html/draft-ietf-emu-eap-noob-01#appendix-C) even 
suggests that servers can provide a list of SSIDs to the peer that it 
can successfully connect to later on.

>
> * IoT device provisioning is not a new problem. In fact, it has been solved
> hundreds of times. Most of those solutions are proprietary but some standards
> efforts are ongoing now: IoTopia, FIDO IoT, Connected Home over IP, IP-BLiS,
> etc. Why ignore these? Why not reach out and try to help them?

You missed Device Provisioning Protocol (DPP), Amazon Frustration Free 
Setup (https://developer.amazon.com/frustration-free-setup). I sincerely 
hope you have posed the same question of outreach to all them. I 
obviously cannot control (or participate) in all those other standards 
bodies. The fact that there are many people working in this area only 
proves that this is relevant problem and that there is no definite 
solution (not that I expect a single protocol to rule the entire world). 
The EMU working group was chartered to 
(https://datatracker.ietf.org/group/emu/about/) "Define a standard EAP 
method for mutual authentication between a peer and a server that is 
based on an out-of-band channel. The method itself should be independent 
of the underlying OOB channel and shall support a variety of OOB 
channels such as NFC, dynamically generated QR codes, audio, and visible 
light.". The fact that EAP-NOOB can also be used for bootstrapping IoT 
devices is a fringe 

Re: [Emu] I-D Action: draft-ietf-emu-aka-pfs-04.txt

2020-06-23 Thread Mohit Sethi M
Hi all,

I am not a crypto expert and my knowledge of public key encodings is 
based on my work with Rene Struik for a different draft.

The current text in draft-ietf-emu-aka-pfs-04 says "For P-256, the 
length of this value is 32 bytes, encoded in binary". Shouldn't this be 
33 bytes? And wouldn't it make sense to explicitly say that this is an 
octet string in the compressed format while referencing "SEC 1: Elliptic 
Curve Cryptography, Version 2.0" for the point to octet string 
conversion rules?

--Mohit

On 5/26/20 9:57 AM, internet-dra...@ietf.org wrote:
> 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   : Perfect-Forward Secrecy for the Extensible 
> Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' 
> PFS)
>  Authors : Jari Arkko
>Karl Norrman
>Vesa Torvinen
>   Filename: draft-ietf-emu-aka-pfs-04.txt
>   Pages   : 26
>   Date: 2020-05-25
>
> Abstract:
> Many different attacks have been reported as part of revelations
> associated with pervasive surveillance.  Some of the reported attacks
> involved compromising smart cards, such as attacking SIM card
> manufacturers and operators in an effort to compromise shared secrets
> stored on these cards.  Since the publication of those reports,
> manufacturing and provisioning processes have gained much scrutiny
> and have improved.  However, the danger of resourceful attackers for
> these systems is still a concern.
>
> This specification is an optional extension to the EAP-AKA'
> authentication method which was defined in [I-D.ietf-emu-rfc5448bis].
> The extension, when negotiated, provides Perfect Forward Secrecy for
> the session key generated as a part of the authentication run in EAP-
> AKA'.  This prevents an attacker who has gained access to the long-
> term pre-shared secret in a SIM card from being able to decrypt any
> past communications.  In addition, if the attacker stays merely a
> passive eavesdropper, the extension prevents attacks against future
> sessions.  This forces attackers to use active attacks instead.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-emu-aka-pfs/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-emu-aka-pfs-04
> https://datatracker.ietf.org/doc/html/draft-ietf-emu-aka-pfs-04
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-aka-pfs-04
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> 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 mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Commitment Message in draft-ietf-emu-eap-tls13

2020-06-16 Thread Mohit Sethi M

Hi Hannes,

Thanks for you super quick response too.

Based on your feedback, I am leaning towards :

Use the Commitment Message as an application layer payload (encrypted 
as it should be). (Note that this has nothing to do with early data.) 
If the OpenSSL spec does not support an application layer message from 
the server right after the finish then it is not compliant to the TLS 
1.3 RFC. 


It would also result in the smallest change to the current 
specification. Only the description of how the commitment message is 
constructed needs to be changed. I agree that sending a notification to 
an unauthenticated peer in this case is fine.


I wonder how others feel about this change.

--Mohit

On 6/16/20 1:43 PM, Hannes Tschofenig wrote:


Hi Mohit,

See below. Thanks for your super quick response.

*From:* Mohit Sethi M 
*Sent:* Tuesday, June 16, 2020 12:25 PM
*To:* Hannes Tschofenig ; Mohit Sethi M 
; emu@ietf.org

*Subject:* Re: [Emu] Commitment Message in draft-ietf-emu-eap-tls13

Hi Hannes,

On 6/16/20 12:37 PM, Hannes Tschofenig wrote:

Hi Mohit,

I had a chance to read through the emails you provided. A good
discussion.

I can offer three solutions:

 1. Use EAP-Success / EAP-Failure as an indication for the
completion of the exchange, even if it is not a reliable
notification mechanism. If the EAP peer does not receive the
NewSessionTicket message then it does not matter because it is
optional to use anyway. It will be a failure case anyway if
the EAP-Success / EAP-Failure got lost. They EAP peer may not
even know whether the exchange was successful despite
correctly processing TLS handshake messages.

I am uncomfortable doing this without updating RFC 3748. Not only will 
we be violating RFC 3748, we would still have the problem of peer 
uncertainty about the next message. It could be a NewSessionTicket or 
EAP-Success/Failure.


[Hannes] What is done in EAP today?

 2. Demand that the NewSessionTicket is sent immediately after the
Finished, very much like you currently demand that the
Commitment Message is attached to the last message.

I assume that you imply immediately after the server has sent its TLS 
Finished (and not after the server has received the TLS Finished from 
the peer)? Are you also implying that a NewSessionTicket should always 
be sent out, regardless of whether a server wants or supports 
resumption? What if the server is issuing several tickets?


[Hannes] I would leave it as an option to send a NewSessionTicket but 
it is sent then it has to be in the last message. Here is the exchange:


Case 1: NewSessionTicket Message Sent

    EAP Peer  EAP Server

EAP-Request/

<  Identity

    EAP-Response/

    Identity (Privacy-Friendly)  >

EAP-Request/

 EAP-Type=EAP-TLS

<    (TLS Start)

    EAP-Response/

    EAP-Type=EAP-TLS

   (TLS ClientHello) >

EAP-Request/

EAP-Type=EAP-TLS

(TLS ServerHello,

 TLS EncryptedExtensions,

  TLS CertificateRequest,

TLS Certificate,

 TLS CertificateVerify,

<  TLS Finished,

   TLS NewSessionTicket)

    EAP-Response/

    EAP-Type=EAP-TLS

   (TLS Certificate,

    TLS CertificateVerify,

    TLS Finished)    >

<   EAP-Success

Case 2: No ticket sent

    EAP Peer  EAP Server

  EAP-Request/

<  Identity

    EAP-Response/

    Identity (Privacy-Friendly)  >

EAP-Request/

   EAP-Type=EAP-TLS

<    (TLS Start)

    EAP-Response/

    EAP-Type=EAP-TLS

   (TLS ClientHello) >

EAP-Request/

EAP-Type=EAP-TLS

(TLS ServerHello,

 TLS EncryptedExtensions,

  TLS CertificateRequest,

TLS Certificate,

TLS CertificateVerify,

  <  TLS Finished)

EAP-Response/

    EAP-Type=EAP-TLS

   (TLS Certificate,

    TLS CertificateVerify,

    TLS Finished)    >

<   EAP-Success



 3. Use the Commitment Message as an application layer payload
(encrypted as it should be). (Note that this has nothing to do
with early data.) If the OpenSSL spec does not support an
application layer message from the server right after the
finish then it is not compliant to the TLS 1.3 RFC.

How would that work? How can server send encrypted application layer 
payload without having received the TLS Finished from the peer.


[Hannes] Here is a

Re: [Emu] Commitment Message in draft-ietf-emu-eap-tls13

2020-06-16 Thread Mohit Sethi M

Hi Hannes,

On 6/16/20 12:37 PM, Hannes Tschofenig wrote:


Hi Mohit,

I had a chance to read through the emails you provided. A good 
discussion.


I can offer three solutions:

 1. Use EAP-Success / EAP-Failure as an indication for the completion
of the exchange, even if it is not a reliable notification
mechanism. If the EAP peer does not receive the NewSessionTicket
message then it does not matter because it is optional to use
anyway. It will be a failure case anyway if the EAP-Success /
EAP-Failure got lost. They EAP peer may not even know whether the
exchange was successful despite correctly processing TLS handshake
messages.

I am uncomfortable doing this without updating RFC 3748. Not only will 
we be violating RFC 3748, we would still have the problem of peer 
uncertainty about the next message. It could be a NewSessionTicket or 
EAP-Success/Failure.


 2. Demand that the NewSessionTicket is sent immediately after the
Finished, very much like you currently demand that the Commitment
Message is attached to the last message.

I assume that you imply immediately after the server has sent its TLS 
Finished (and not after the server has received the TLS Finished from 
the peer)? Are you also implying that a NewSessionTicket should always 
be sent out, regardless of whether a server wants or supports 
resumption? What if the server is issuing several tickets?


 3. Use the Commitment Message as an application layer payload
(encrypted as it should be). (Note that this has nothing to do
with early data.) If the OpenSSL spec does not support an
application layer message from the server right after the finish
then it is not compliant to the TLS 1.3 RFC.

How would that work? How can server send encrypted application layer 
payload without having received the TLS Finished from the peer.


While I am open to discussing better alternatives, I think from an 
implementation perspective, it makes sense to have a definite 
notification mechanism for the server to notify the peer that no more 
post-handshake messages are to be expected.


--Mohit

The current solution in the draft, for example, does not work with 
Mbed TLS because you cannot tell the stack to suddenly bypass the 
encryption layer (after successfully establishing it) to send a 
plaintext message.


Ciao

Hannes

*From:* Mohit Sethi M 
*Sent:* Monday, June 15, 2020 3:52 PM
*To:* Hannes Tschofenig ; emu@ietf.org
*Subject:* Re: [Emu] Commitment Message in draft-ietf-emu-eap-tls13

Hi Hannes,

Unfortunately you are wrong here. The design decision was in fact 
taken to avoid changes to the underlying TLS implementation while also 
avoiding changes to RFC 3748. To summarize:


Jouni Malinen pointed out that mapping session resumption of TLS 1.3 
to EAP-TLS is non-trivial. See his email here: 
https://mailarchive.ietf.org/arch/msg/emu/SBdblHmLQTbBwoZHK8Rih-g5ne8/. 
Essentially, TLS 1.3 allows a server to send a Post-Handshake message 
with a NewSessionTicket at any time. However, in EAP-TLS this is not 
possible. The TLS tunnel is torn down after authentication. John notes 
in his response to Jouni 
(https://mailarchive.ietf.org/arch/msg/emu/nNUw61cTvHgWj8F0sOVRoICUzlk/) 
"in TLS the connection is assumed to stay open for a long time after 
the client sends Finished, in EAP the connection is assumed to be 
closed shortly after."


An earlier cleaner way of sending NewSessionTicket required an extra 
round trip and left the peer uncertain about the next message 
(https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-00#section-2.1.1). 
Jouni highlighted this uncertainty for a peer: " the peer has no idea 
whether the NewSessionTicket is delivered after ClientFinished. In 
other words, the next message in the sequence could be either 
continuation of EAP-TLS method or EAP-Success". You ask "why cannot 
the EAP-Success or EAP-Failure serve that purpose?". See RFC 3748 
(https://tools.ietf.org/html/rfc3748) which says the following:


    Implementation Note: Because the Success and Failure packets are not

    acknowledged, they are not retransmitted by the authenticator, and

    may be potentially lost.  A peer MUST allow for this circumstance as

    described in this note.

and

  On the peer, after success result indications have been exchanged by

    both sides, a Failure packet MUST be silently discarded.  The peer

    MAY, in the event that an EAP Success is not received, conclude that

    the EAP Success packet was lost and that authentication concluded

    successfully.


Thus, EAP-Success cannot be used as a reliable notification mechanism. 
Till version 05 of the document, we used an empty application data 
record as a notification of the last handshake message. The text said:


When an EAP server has sent its last handshake message (Finished or a

    Post-Handshake), it commits to not sending any more handshake

Re: [Emu] Commitment Message in draft-ietf-emu-eap-tls13

2020-06-15 Thread Mohit Sethi M
Hi Hannes,

Unfortunately you are wrong here. The design decision was in fact taken to 
avoid changes to the underlying TLS implementation while also avoiding changes 
to RFC 3748. To summarize:

Jouni Malinen pointed out that mapping session resumption of TLS 1.3 to EAP-TLS 
is non-trivial. See his email here: 
https://mailarchive.ietf.org/arch/msg/emu/SBdblHmLQTbBwoZHK8Rih-g5ne8/. 
Essentially, TLS 1.3 allows a server to send a Post-Handshake message with a 
NewSessionTicket at any time. However, in EAP-TLS this is not possible. The TLS 
tunnel is torn down after authentication. John notes in his response to Jouni 
(https://mailarchive.ietf.org/arch/msg/emu/nNUw61cTvHgWj8F0sOVRoICUzlk/) "in 
TLS the connection is assumed to stay open for a long time after the client 
sends Finished, in EAP the connection is assumed to be closed shortly after."

An earlier cleaner way of sending NewSessionTicket required an extra round trip 
and left the peer uncertain about the next message 
(https://tools.ietf..org/html/draft-ietf-emu-eap-tls13-00#section-2.1.1). Jouni 
highlighted this uncertainty for a peer: " the peer has no idea whether the 
NewSessionTicket is delivered after ClientFinished. In other words, the next 
message in the sequence could be either continuation of EAP-TLS method or 
EAP-Success". You ask "why cannot the EAP-Success or EAP-Failure serve that 
purpose?". See RFC 3748 (https://tools.ietf.org/html/rfc3748) which says the 
following:

   Implementation Note: Because the Success and Failure packets are not
   acknowledged, they are not retransmitted by the authenticator, and
   may be potentially lost.  A peer MUST allow for this circumstance as
   described in this note.

and

 On the peer, after success result indications have been exchanged by
   both sides, a Failure packet MUST be silently discarded.  The peer
   MAY, in the event that an EAP Success is not received, conclude that
   the EAP Success packet was lost and that authentication concluded
   successfully.

Thus, EAP-Success cannot be used as a reliable notification mechanism. Till 
version 05 of the document, we used an empty application data record as a 
notification of the last handshake message. The text said:

When an EAP server has sent its last handshake message (Finished or a
   Post-Handshake), it commits to not sending any more handshake
   messages by appending an empty application data record (i.e. a TLS
   record with TLSPlaintext.type = application_data and
   TLSPlaintext.length = 0) to the last handshake record.  After sending
   an empty application data record, the EAP server may only send an
   EAP-Success, an EAP-Failure, or an EAP-Request with a TLS Alert
   Message.

However, Jouni in a later response 
(https://mailarchive.ietf.org/arch/msg/emu/WA8OREhTsF8JEPvaixGoCwmd1qY/) noted 
that such behavior is non-trivial to achieve with OpenSSL. He notes " OpenSSL 
is not willing to send such an empty TLSPlaintext structure. SSL_write() has 
following to say : 'You should not call SSL_write() with num=0, it will return 
an error. SSL_write_ex() can be called with num=0, but will not send 
application data to the peer.'"

Therefore, the text was later updated to:

 When an EAP server has sent its last handshake message (Finished or a
   Post-Handshake), it commits to not sending any more handshake
   messages by sending a Commitment Message.  The Commitment Message is
   a TLS record with application data 0x00 (i.e. a TLS record with
   TLSPlaintext.type = application_data, TLSPlaintext.length = 1, and
   TLSPlaintext.fragment = 0x00).  Note that the length of the plaintext
   is greater than the corresponding TLSPlaintext.length due to the
   inclusion of TLSInnerPlaintext.type and any padding supplied by the
   sender.  EAP server implementations MUST set TLSPlaintext.fragment to
   0x00, but EAP peer implementations MUST accept any application data
   as a Commitment Message from the EAP server to not send any more handshake 
messages.


There is still a challenge in scenarios where a server chooses not to issue any 
NewSessionTicket. In this email: 
https://mailarchive.ietf.org/arch/msg/emu/PgGjhmafbbSJCcQctDsFw7AvNmU/ Jouni 
notes this problem:

I did see some issues when OpenSSL 1.1.1 when disabling sending of
session tickets, though. The current draft indicates that the empty
Application Data payload would be send out in the same EAP packet with
the server's Finished message, i.e., before the server having
authenticated the peer. And this would be done without the peer having
used TLS early data (which is explicitly disallowed in the draft). That
combination did not work with my experiments since OpenSSL was rejecting
the SSL_write() operation after the server having written own Finished
message, but before having received the Finished message from the peer.
The OpenSSL documentation seemed to imply that SSL_write_early_data()
could be used by the server _if_ the client first sent early data.. At
least in my 

Re: [Emu] draft-ietf-emu-eap-tls13-09

2020-06-15 Thread Mohit Sethi M
Hi Hannes,

On 6/12/20 11:29 AM, Hannes Tschofenig wrote:

A short follow-up on my own review:

I wrote:



"
Pre-Shared Key (PSK) authentication SHALL NOT be used except
   for resumption.
"
What you want to say that that EAP-TLS MUST NOT use external PSKs. I wonder why 
you want to rule that use case out? It is a perfectly fine use case for TLS 1.3 
and there is even the possibility to use PSK with ECDHE. What is the motivation?



I noticed now that the working group had a discussion about this already and 
that there is a new document being published specifically focused on 
EAP-TLS-PSK-based authentication. Hence, ignore the second part of my comment.

Indeed. There has been lots of discussion on this topic. To summarize:

RFC 5216 explicitly required certificate based TLS authentication with the 
following text:

   If the EAP server is not resuming a previously established session,
   then it MUST include a TLS server_certificate handshake message, and
   a server_hello_done handshake message MUST be the last handshake
   message encapsulated in this EAP-Request packet.

   The certificate message contains a public key certificate chain for
   either a key exchange public key (such as an RSA or Diffie-Hellman
   key exchange public key) or a signature public key (such as an RSA or
   Digital Signature Standard (DSS) signature public key).

Bernard Aboba opined that external PSK based authentication shouldn't be added 
to EAP-TLS in this update. Instead a separate document (with a separate EAP 
method type) should do that. Hence, we now have: 
https://tools.ietf.org/html/draft-mattsson-emu-eap-tls-psk-00. For reference, 
here are some email conversations containing discussion on this topic:

- https://mailarchive.ietf.org/arch/msg/emu/FtxRJHTjzSY0yVdVr8Vjyk9D-vk/
- https://mailarchive.ietf.org/arch/msg/emu/CRh3VXLDnpJFFIbHWJAjiOgfzAg/
- https://mailarchive.ietf.org/arch/msg/emu/nYrIA4PKqk2mrUoNvAtFh7S-Xb8/
- https://mailarchive.ietf.org/arch/msg/emu/hVG357HXqvy0EjZ2yrOLdspH53o/

--Mohit



Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

___
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


Re: [Emu] draft-ietf-emu-eaptlscert-04

2020-06-15 Thread Mohit Sethi M

Hi Hannes,

Thanks for the follow up. I have submitted a new version which should 
address your concerns. Here is a diff for your convenience:

https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eaptlscert-05

Please see in-line for details.

I believe that the draft is now ready for publication.

--Mohit

On 6/10/20 12:02 PM, Hannes Tschofenig wrote:

Thanks for the update.

A few more minor comments on -04:

Section 4.1:

"TLS 1.3 [https://tools.ietf.org/html/rfc8446] requires implementations to support 
ECC."

This is only true absent an application profile defining something else.
The UTA group has just adopted a WG item that defines such a profile.

Hence, I suggest to add the remark about the profile. Something like

"In the absence of an application profile standard specifying
otherwise, a TLS 1.3-compliant application must support ECC."

Done!


4.2.  Updating TLS and EAP-TLS Code

Why are you calling the section "updating code"? The suggestion in 4.2.1 does 
not require code update and whether something requires a code update depends what you 
have in the code already. Maybe you just need to enable the feature.  Updating the code 
is also a negative aspect because you are likely going to update the code on a regular 
basis anyway to fix bugs and to support new algorithms. Luckily TLS has the extension 
negotiation built-in and hence you can detect and negotiate new features on the fly.
I agree that all code indeed should be updated to fix bugs and 
vulnerabilities. However, updating applications and certificates is 
certainly different from updating the underlying TLS library and EAP 
implementation. Administrators in enterprise environments (where EAP-TLS 
is widely used) have great control over when and how the server and 
client updates are rolled out. The categorization in section 4 should 
help administrators to decide how to avoid the fragmentation problem. 
Whether it is issuing new certificates, updating the access points, or 
updating the TLS and EAP-TLS implementation. Nonetheless, I have added 
the following text: "This section discusses how the fragmentation 
problem can be avoided by updating the underlying TLS or EAP-TLS 
implementation. Note that in many cases the new feature may already be 
implemented in the underlying library and simply needs to be taken into 
use."


4.2.4.  Caching Certificates

"The extension however necessitates a successful full handshake before any 
caching."

This is not true. The spec defines a way to populate the cache by running a 
full handshake.
However, you could also populate the cache by out-of-band means, for example by 
pre-distributing certs.

The mechanism to re-run the handshake to populate the cache is, however, a safe 
fallback in case configuration changes and the pre-distributed certs become 
invalid. It is better to have a fallback.

I thought I made that comment before.


You had raised this issue before and I had responded to you before. Here 
is the response again:


Where does RFC 7924 (https://tools.ietf.org/html/rfc7924) talk about 
populating the cache with an out-of-band mechanism? The text in Section 
1 of RFC 7924 clearly states that:  "This specification defines a TLS 
extension that allows a client and a server to exclude transmission 
information cached in an earlier TLS handshake.". Notice the "earlier 
TLS handshake" part. I certainly refuse to add or describe new 
functionality which isn't discussed in the original RFC.




4.2.3.  Compact TLS 1.3

You are still stating "This naturally means that cTLS is not interoperable with 
previous versions of the TLS protocol."

cTLS is a compression of TLS, which means that you can fall-back to TLS, if the 
other peer does not support cTLS. As mentioned in my previous email, I don't 
understand why you are mentioning this aspect at all given that this document 
is about certificate size reduction.
I understand your desire of making cTLS look good. I am not sure how 
hiding the information that cTLS doesn't interoperate with older 
versions of TLS helps. Anyhow, I have removed that sentence since 
progressing the draft at this is stage is more important than arguing 
over one sentence.


Raw Public Keys

I wonder whether you should mention the possibility to use RPKs 
(https://tools.ietf.org/html/rfc7250) in Section 4.1.2 because those would be a 
fairly obvious choice in EAP-TLS given that we are talking about a nailed up 
connection between the EAP peer and the EAP server. This would obviously reduce 
the overhead associated with certificates considerably.


Added a new sub-section.

With this, I believe that all issues are resolved and the document is 
ready for publication.




Ciao
Hannes


IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the 

Re: [Emu] My review ... was RE: I-D Action: draft-ietf-emu-eaptlscert-02.txt

2020-06-08 Thread Mohit Sethi M
Hi Hannes,

Thanks for the follow up. I have submitted a new version which should 
address your concerns. Here is a diff for your convenience: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eaptlscert-04

Please see in-line for some details.

--Mohit

On 6/8/20 3:19 PM, Hannes Tschofenig wrote:
> Thanks for the update, Mohit.
>
> A few minor remarks:
>
> FROM:
>
> "
> TLS certificates in EAP deployments can be relatively large, and the
> certificate chains can be long.
> "
>
> TO:
>
> "
> Certificates in EAP deployments can be relatively large, and the
> certificate chains can be long.
> "
Done!
>
> Reason: Certificates are large and there is nothing in TLS that contributes 
> to the size.
>
> In Section 4 I would state the obvious to the reader: Keep the certificate 
> size small by not stuffing lots of fields in it and keep the chain short.
> A common reason why these certs are long is because developers don't 
> understand that they do not need to map the organizational hierarchy to a CA 
> hierarchy.
> This is the simplest approach to reduce the size of certificates sent over 
> the wire.
I added a sentence "The general guideline of keeping the certificate 
size small by not populating fields with excessive information can help 
avert the problems of failed EAP-TLS authentication.". Your comment on 
the needless mapping of the organizational hierarchy to the CA hierarchy 
is already covered in section 4.2.7.
>
> Regarding 4.2.3.  Compact TLS 1.3
>
> [I-D.ietf-tls-ctls] defines a "compact" version of TLS 1.3 and
> reduces the message size of the protocol by removing obsolete
> material and using more efficient encoding.  This naturally means
> that cTLS is not interoperable with previous versions of the TLS
> protocol.  It also defines a compression profile with which either
> side can define dictionary of "known certificates".  Thus, cTLS can
> provide another mechanism for EAP-TLS deployments to reduce the size
> of messages and avoid excessive fragmentation.
>
> The point for mentioning cTLS was related to the certificate compression. I 
> would therefore change the paragraph to:
>
> 4.2.3.  Compact TLS 1.3
>
> [I-D.ietf-tls-ctls] defines a "compact" version of TLS 1.3 and
> reduces the message size of the protocol by removing obsolete
> material and using more efficient encoding.  It also defines a
> compression profile with which either  side can define dictionary
> of "known certificates".
I haven't changed the paragraph. I think it is important to let the 
reader know that cTLS is not interoperable with previous versions TLS. 
So updating the peer implementation without updating the server 
implementation would not help.
>
> I wonder whether you want to mention also 
> https://tools.ietf.org/html/draft-tschofenig-tls-cwt-01 and 
> https://tools.ietf.org/html/draft-mattsson-tls-cbor-cert-compress-00?
> Since those are still individual drafts you could point out that those are 
> work in progress.
I was a bit hesitant to add these since they are still in early phases 
of development. However, I have now added a section titled "New 
Certificate Types and Compression Algorithms". Hope this is sufficient.
>
> Ciao
> Hannes
>
> -Original Message-
> From: Mohit Sethi M 
> Sent: Saturday, May 9, 2020 10:49 AM
> To: Hannes Tschofenig ; Michael Richardson 
> ; emu@ietf.org
> Subject: Re: [Emu] My review ... was RE: I-D Action: 
> draft-ietf-emu-eaptlscert-02.txt
>
> Hi Hannes,
>
> I have submitted a new version of the draft which I believe addresses your 
> concerns. Here is a diff for your convenience:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eaptlscert-03
>
> While Alan and Jouni have already provided excellent answers to most of your 
> comments, in-line you can find a few more clarifications for the changes I 
> made.
>
> --Mohit
>
> On 3/24/20 10:00 AM, Hannes Tschofenig wrote:
>> Hi Michael, Hi draft authors,
>>
>>> I was surprised to get to the end of the document without any suggestions 
>>> about sending certificates by reference rather than value.
>> Having seen this statement from Michael I have reviewed the document. Two 
>> generic observations about the draft:
>>
>> 1) Many statements are made about deployments and no references are 
>> provided. To improve quality of the write-up I would strongly suggest to add 
>> such references, as you would have to do with an academic publication as 
>> well.
>>
>> 2) A few techniques are missing (Certificate URLs and cTLS) and TLS Cached 
>> Info was wrongly

Re: [Emu] AD review of draft-ietf-emu-eap-tls13-09

2020-06-07 Thread Mohit Sethi M
Hi Roman,

Thanks for your usual careful review. I have submitted a new version 
that hopefully addresses all the issues. Here is the diff for your 
convenience: https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-10

Please see in-line for details on how we have handled each issue.

--Mohit

On 5/28/20 9:31 PM, Roman Danyliw wrote:
> Hi!
>
> I performed an AD review of draft-ietf-emu-eap-tls13-09.  Thanks for the work 
> on modernizing existing guidance to cover TLS 1.3.
>
> Two high level things caught my attention:
>
> ** The abstract, introduction and title suggested to me that this document is 
> only about TLS 1.3+EAP.  If I wasn't using TLS 1.3, then there is nothing 
> here of interest.  However, there appears to be text here that updates 
> non-TLS 1.3 guidance.  I recommend being clear about that up front (in the 
> abstract and introduction).
>
> ** Section 2.1 explicitly says that "[t]his document only lists additional 
> and different requirements, restrictions, and processing compared to 
> [RFC8446] and [RFC5216]."  The text tries to match section headers names with 
> [RFC5216] (which is helpful).  However, I didn't always follow the "updates" 
> without some searching.  Editorially, given a particular description of 
> behavior, I recommend being clearer by consistently making explicit reference 
> to a particular section in RFC5216 that is being updated.

We initially maintained a strict matching between sections of RFC 5216 
and this document. However, there were requests for new sections: 
Identity (Alan DeKok) and Hello Retry Request (Jim Schaad). In some 
cases, it was also necessary to have a new section. For example, a new 
section was needed to explain how server issued tickets are a necessary 
precursor for session resumption in TLS 1.3. Each section now begins by 
explicitly informing the reader if it updates a specific section of RFC 
5216. New sections that didn't exist in RFC 5216 are also clearly labeled.

It is true that the guidance on resumption and authorization is not 
specific to TLS version 1.3. The text in the abstract and introduction 
now state that "This document also provides guidance on authorization 
and resumption for EAP-TLS in general (regardless of the underlying TLS 
version used)".

>
> More details on the above observations and others below:
>
> (1) Can you please check the boiler plate language, idnits is complaining is 
> as follows:
>== The document seems to lack the recommended RFC 2119 boilerplate, even if
>   it appears to use RFC 2119 keywords -- however, there's a paragraph with
>   a matching beginning. Boilerplate error?
>
>   (The document does seem to have the reference to RFC 2119 which the
>   ID-Checklist requires).
>   (Using the creation date from RFC5216, updated by this document, for
>   RFC5378 checks: 2007-07-01)
>
>-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
>   have content which was first submitted before 10 November 2008.  If you
>   have contacted all the original authors and they are all willing to 
> grant
>   the BCP78 rights to the IETF Trust, then this is fine, and you can 
> ignore
>   this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
>   (See the Legal Provisions document at
>   https://trustee.ietf.org/license-info for more information.)
The boilerplate error showed up because of a missing space. It shouldn't 
show up anymore. Even though RFC5216 is pre-RFC5378 work, it had granted 
BCP78 rights to the IETF trust. So we should be fine. (This issue was 
also noted by the document shepherd (Joe Salowey).)
>
> (2) Section 1.  Editorial.  Instead of something working "perfectly", maybe 
> just "supports"
> OLD
> EAP-TLS [RFC5216] references TLS 1.0 [RFC2246] and TLS 1.1 [RFC4346],
> but works perfectly also with TLS 1.2 [RFC5246].
>
> NEW
> EAP-TLS [RFC5216] explicitly references TLS 1.0 [RFC2246] and TLS 1.1 
> [RFC4346], but it also supports TLS 1.2 [RFC5246].
I am somewhat uncomfortable with the word "support". In my opinion, 
EAP-TLS uses a version TLS rather than supports a version of TLS. I have 
updated the text to say "EAP-TLS [RFC5216] references TLS 1.0 [RFC2246] 
and TLS 1.1 [RFC4346], but can also work with TLS 1.2 [RFC5246]". I am 
willing to modify if this is not appropriate.
>
> (3) Section 1.  Editorial.  "Easy" might be relative.
>
> OLD
> Privacy is mandatory and achieved without any additional round-trips,
> revocation checking is mandatory and easy with OCSP stapling,
>
> NEW
> Privacy is mandatory and achieved without any additional round-trips,   
> revocation checking is mandatory and simplified with OCSP stapling,
Fixed as recommended.
>
> (3) Section 2.1.1.  What is the relationship between this section and NAI 
> guidance in RFC5216 Section 2.1.4?  Is it that anonymous NAIs are RECOMMENDED 
> for TLS 1.3, but stay a MAY in old EAP-TLS?
>
> (4) Section 2.1.3.  Editorial.  

Re: [Emu] Early allocation request for an EAP Method Type number for draft-ietf-emu-eap-noob

2020-05-26 Thread Mohit Sethi M
I would add that there is also an early implementation of EAP-TLS-PSK: 
https://github.com/rohitshubham/EAP-TLS-PSK

We had agreed that external PSK authentication for EAP-TLS will use a new 
method type number. The draft for EAP-TLS-PSK 
(https://tools.ietf.org/html/draft-mattsson-emu-eap-tls-psk-00) is still in the 
early stages and will undergo many changes before it can be considered for 
adoption by the working group. However, allocating a method type number for 
EAP-NOOB now would ensure that EAP-TLS-PSK doesn't use the same code point.

--Mohit

On 5/26/20 6:56 AM, Joseph Salowey wrote:
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

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


[Emu] Minutes and bluesheets from EMU virtual interim

2020-05-24 Thread Mohit Sethi M
Dear all,

Thank you for participating in the EMU virtual interim on Friday. A 
special thank you to Max Crone for volunteering as the minute taker. 
Meeting minutes and bluesheets from the virtual interim have now been 
uploaded.

Minutes: 
https://datatracker.ietf.org/meeting/interim-2020-emu-01/materials/minutes-interim-2020-emu-01-202005221800
Bluesheets: 
https://www.ietf.org/proceedings/interim-2020-emu-01/bluesheets/bluesheets-interim-2020-emu-01-202005221800-00.txt

Please report any issues by June 1, 2020.

Joe and Mohit

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


[Emu] Request for presentations during virtual interim

2020-05-18 Thread Mohit Sethi M
Dear all,

The webex details for our virtual interim meeting on Friday this week is 
now posted to the mailing list. They are copied below for convenience.

Please let us know if you intend to present. Don't forget to include the 
title, approximate time needed, and any associated drafts.

Joe and Mohit

JOIN WEBEX MEETING 
https://ietf.webex.com/ietf/j.php?MTID=mc9df4dccd3859204bde061bde4848491 
Meeting number (access code): 618 538 077 Meeting password: Sx2edf4mWU3

On 5/5/20 11:38 AM, Mohit Sethi M wrote:
> The poll is now closed. We will have a 90-minute virtual interim meeting
> for EMU on  May 22nd, 2020 between 15:00-16:30 UTC.
>
> Please send in requests for presentations. Don't forget to include the
> title, approximate time needed, and any associated drafts.
>
> --Mohit
>
> On 4/24/20 3:45 PM, Mohit Sethi M wrote:
>> Dear all,
>>
>> Reminder: please respond to the poll for a potential virtual interim in
>> May: https://doodle.com/poll/vxy5vc4g3cnegpdr
>>
>> Joe and Mohit
>>
>> On 4/20/20 2:11 AM, Mohit Sethi M wrote:
>>> Dear all,
>>>
>>> We did not have a face-to-face meeting in Vancouver for IETF 107. At
>>> this point, the IETF 108 meeting in Madrid is also uncertain.
>>>
>>> We are therefore considering a virtual interim meeting for EMU during
>>> middle/end of May 2020. Here are some proposed dates and time slots:
>>> https://doodle.com/poll/vxy5vc4g3cnegpdr
>>>
>>> Please indicate your availability!
>>>
>>> Joe and Mohit
>>>
>>> ___
>>> 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 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


Re: [Emu] My review ... was RE: I-D Action: draft-ietf-emu-eaptlscert-02.txt

2020-05-09 Thread Mohit Sethi M
Hi Hannes,

I have submitted a new version of the draft which I believe addresses 
your concerns. Here is a diff for your convenience: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eaptlscert-03

While Alan and Jouni have already provided excellent answers to most of 
your comments, in-line you can find a few more clarifications for the 
changes I made.

--Mohit

On 3/24/20 10:00 AM, Hannes Tschofenig wrote:
> Hi Michael, Hi draft authors,
>
>> I was surprised to get to the end of the document without any suggestions 
>> about sending certificates by reference rather than value.
> Having seen this statement from Michael I have reviewed the document. Two 
> generic observations about the draft:
>
> 1) Many statements are made about deployments and no references are provided. 
> To improve quality of the write-up I would strongly suggest to add such 
> references, as you would have to do with an academic publication as well.
>
> 2) A few techniques are missing (Certificate URLs and cTLS) and TLS Cached 
> Info was wrongly interpreted.  They actually relate to the remark from 
> Michael.
>
>> TLS certificates are often relatively large, and the certificate
>>chains are often long.
> I think this statement is in general incorrect. You could say that in 
> deployment X certificates have size X and the chain is Y long.
>
>
>> Also,
>>   from deployment experience, EAP peers typically have longer
>>certificate chains than servers.
> I would like a reference to be included here. Theoretically, it makes no 
> sense to
> have a certificate chain for an EAP peer to have a longer certificate chain 
> than a server
> given a EAP peer talks to one EAP server.
>
> In network access authentication it is not only about authentication but the 
> most important part is authorization. Hence, you pretty much always have a 
> one-to-one relationship between the EAP peer and the EAP server. There are no 
> good reasons to have complex CA hierarchies here.
>
>> This is because EAP peers often
>>   follow organizational hierarchies and tend to have many intermediate
>>certificates.  Thus, EAP-TLS authentication usually involve
>>significantly more octets than when TLS is used as part of HTTPS.
> I think it would make sense to explain this organizational hierarchy aspect 
> in a bit
> more detail.
>
>> The EAP fragment size
>>   in typical deployments is just 1020 - 1500 octets.
> Reference for the 1500 octets.
Added that this limitation come from Ethernet II frame size.
>
>
>> For example, many EAP authenticator (access point)
>>   implementations will drop an EAP session if it has not finished after
>>40 - 50 round-trips.
> Is there a reference that could be included?
>
>> However, deployment
>>experience has shown that these jumbo frames are not always
>>   implemented correctly.
> Add a reference here.
>
>> RADIUS can generally transport only about 4000
>>   octets of EAP in a single message.
> How was this number constructed?
Added that RADIUS RFC2865 limits length to 4096 octets.
>
>>A certificate chain (called a certification path in [RFC5280]) can
>>have 2 - 6 intermediate certificates between the end-entity
>>certificate and the trust anchor [RFC5280].
> The PKIX reference here is misleading. I think you included it to refer to 
> the terms but it sounds like the statement that
> the chain can have 2-6 intermediate CA certificates.
>
> I would add the terms to the terminology section and remove the PKIX 
> reference here.
Done. Thanks. Indeed that was misleading.
>
> I am also wondering what you are trying to say here with this sentence. Are 
> you saying that you have seen deployments
> for network access authentication that have up to 6 intermediate CA 
> certificates in the chain?
>
>
>> 3.  Experience with Deployments
>>Most common access point implementations drop EAP sessions that do
>>not complete within 50 round-trips.
> This sentence is a repetition.
>
>> This means that if the chain is
>>   larger than ~ 60 kB, EAP-TLS authentication cannot complete
>>   successfully in most deployments.
> Regarding the 60 kB certificate chain: Should this be an indication to 
> someone deploying
> the technology for access network authentication that something has gone 
> wrong?
>
> Is this someone you have observed or is this just a theoretical statement? I 
> hope it is the latter.
>
>
> 4.2.1.  Pre-distributing and Omitting CA Certificates
>
>
>> When using TLS 1.3, all certificates that
>> specify a trust anchor known by the other endpoint may be omitted
>> (see Section 4.4.2 of [RFC8446]).  When using TLS 1.2 or earlier,
>> only the self-signed certificate that specifies the root certificate
>> authority may be omitted (see Section 7.4.2 of [RFC5246]
> These sentences sound strange.
>
> In TLS (and probably other protocols) it makes no sense to distribute the
> trust anchors in the protocol itself (because then they wouldn't serve as an
> anchor for trust).
>
> It is my 

[Emu] Fwd: Reminder: Survey on planning for possible online IETF meetings

2020-05-07 Thread Mohit Sethi M
You have a chance to influence how the upcoming IETF meetings for this year are 
organized. Please answer the survey if you haven't already. See the details 
below.

Here is the link for your convenience: https://www.surveymonkey.com/r/5328FFJ

--Mohit

Begin forwarded message:

From: IETF Executive Director 
mailto:exec-direc...@ietf.org>>
Subject: Reminder: Survey on planning for possible online IETF meetings
Date: May 4, 2020 at 3:03:35 AM EDT
To: "IETF Announcement List" 
mailto:ietf-annou...@ietf.org>>
Reply-To: ietf108plann...@ietf.org

This is a reminder that we need the IETF community to help us plan for the 
possibility that one or more upcoming IETF meetings in 2020 and possibly 2021 
may not be able to go ahead in person.  You can help us with this by filling 
out the following survey:

https://www.surveymonkey.com/r/5328FFJ

So far we have 114 responses and we would ideally like 500 or more.

The survey contains the following pages and will take 15-20 minutes to complete:

1. Welcome
2. Online IETF 107 and the subsequent virtual interims
3. Replacing a cancelled in-person meeting
4. Online meeting format and timezone
5. Replicating humming
6. Replicating the hallway environment
7. Fees
8. Thanks and anything else

We run the survey in anonymous mode which means that we only see data that you 
explicitly provide.

Thank you in advance for your help.

--
Alissa Cooper, IETF Chair
Jay Daley, IETF Executive Director
Colin Perkins, IRTF Chair

___
IETF-Announce mailing list
ietf-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

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


Re: [Emu] Working Group Call For adoption of draft-dekok-emu-tls-eap-types

2020-05-06 Thread Mohit Sethi M
No objections were raised against adoption of this document as a working 
group item. The adoption call is now closed. Alan, please submit the 
draft as a working group item.

We still need consensus on TEAP specifics. There are 3 issues:

1. Fixing TEAP errata: https://www.rfc-editor.org/errata_search.php?rfc=7170
2. Specifying how TEAP should work with TLS 1.3
3. TEAP updates for BRSKI

We already have a draft and active authors for 3 
(https://tools.ietf.org/html/draft-lear-eap-teap-brski-05).

We can use the virtual interim to discuss where and how the first 2 
items should be addressed.

Joe and Mohit

On 4/20/20 1:53 AM, Mohit Sethi M wrote:
> This is a call for adoption of draft-dekok-emu-tls-eap-types
> (https://datatracker.ietf.org/doc/draft-dekok-emu-tls-eap-types/) as a
> working group item.
>
> Please indicate if you have any objections by May 4th, 2020.
>
> Joe and Mohit
>
> ___
> 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


Re: [Emu] Poll for virtual interim

2020-05-05 Thread Mohit Sethi M
The poll is now closed. We will have a 90-minute virtual interim meeting 
for EMU on  May 22nd, 2020 between 15:00-16:30 UTC.

Please send in requests for presentations. Don't forget to include the 
title, approximate time needed, and any associated drafts.

--Mohit

On 4/24/20 3:45 PM, Mohit Sethi M wrote:
> Dear all,
>
> Reminder: please respond to the poll for a potential virtual interim in
> May: https://doodle.com/poll/vxy5vc4g3cnegpdr
>
> Joe and Mohit
>
> On 4/20/20 2:11 AM, Mohit Sethi M wrote:
>> Dear all,
>>
>> We did not have a face-to-face meeting in Vancouver for IETF 107. At
>> this point, the IETF 108 meeting in Madrid is also uncertain.
>>
>> We are therefore considering a virtual interim meeting for EMU during
>> middle/end of May 2020. Here are some proposed dates and time slots:
>> https://doodle.com/poll/vxy5vc4g3cnegpdr
>>
>> Please indicate your availability!
>>
>> Joe and Mohit
>>
>> ___
>> 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 mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] draft-aura-eap-noob-08 NAI

2020-04-24 Thread Mohit Sethi M
Hi Eliot,

On 4/24/20 4:22 PM, Eliot Lear wrote:

Hi Mohit



On 24 Apr 2020, at 15:02, Mohit Sethi M 
<mailto:mohit.m.sethi=40ericsson@dmarc.ietf.org>
 wrote:

Hi Max,

Tuomas can give you a definite answer. My understanding is that error
1001 should be sent by the server if the received identity does not
follow the requirements of draft-aura-eap-noob. Besides, implementing
the stricter checks of this draft is easier than validating the ABNF of
RFC7542 (after which you would anyways need to verify compliance with
this draft).

And you are right. The absence of server-assigned realm in Figure 2 is
probably an editorial oversight. However, I wouldn't call the optional
server assigned realm as RESERVED_DOMAIN. If anything, I would call
eap-noob.net as a reserved/special use domain.



There are all manner of reasons not to use eap-noob.net.  I think we talked to 
the IAB about this at some point and they were comfortable with something in 
.ARPA, but we’d need to reconfirm.  This is a small matter that should be 
cleared up with a few email exchanges.

Absolutely. Using something in .arpa makes perfect sense. But until that is 
allocated, implementations need a temporary placeholder. The current text in 
section 3.3.1 of the draft even says 
(https://tools.ietf.org/html/draft-aura-eap-noob-08#section-3.3.1):

The default realm for the peer is "eap-noob.net" (.arpa domain TBA).

--Mohit



Eliot
___
Emu mailing list
Emu@ietf.org<mailto:Emu@ietf.org>
https://www.ietf.org/mailman/listinfo/emu

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


Re: [Emu] draft-aura-eap-noob-08 NAI

2020-04-24 Thread Mohit Sethi M
Hi Max,

Tuomas can give you a definite answer. My understanding is that error 
1001 should be sent by the server if the received identity does not 
follow the requirements of draft-aura-eap-noob. Besides, implementing 
the stricter checks of this draft is easier than validating the ABNF of 
RFC7542 (after which you would anyways need to verify compliance with 
this draft).

And you are right. The absence of server-assigned realm in Figure 2 is 
probably an editorial oversight. However, I wouldn't call the optional 
server assigned realm as RESERVED_DOMAIN. If anything, I would call 
eap-noob.net as a reserved/special use domain.

--Mohit

On 4/22/20 12:29 PM, Max Crone wrote:
> While implementing EAP-NOOB, I found the explanation on the Invalid 
> NAI (error code 1001) in the draft to be unclear.
>
> The document formulates it as follows:
> >   If the NAI structure is invalid, the server SHOULD send the error
> >   code 1001 to the peer.
>
> However, does this mean that the EAP-NOOB server should verify that 
> the NAI follows the formal syntax as specified in RFC 7542, or should 
> it verify that the NAI follows the specification of EAP-NOOB, i.e., it 
> is of the form "noob@{eap-noob.net||RESERVED_DOMAIN}". I think this 
> section could be formulated more clearly to address these concerns.
>
> On that note, Figure 2 seems to be incomplete. The 
> EAP-Response/Identity specifies the NAI parameter to be 
> "n...@eap-noob.net", while the specification also has the option of 
> configuring this to a reserved domain. In that case, the NAI should 
> not use the default realm anymore. Currently, this is not reflected in 
> the figure.
>
> If anything remains unclear, I am open for discussion.
>
> ~Max Crone
>
> ___
> 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


Re: [Emu] Poll for virtual interim

2020-04-24 Thread Mohit Sethi M
Dear all,

Reminder: please respond to the poll for a potential virtual interim in 
May: https://doodle.com/poll/vxy5vc4g3cnegpdr

Joe and Mohit

On 4/20/20 2:11 AM, Mohit Sethi M wrote:
> Dear all,
>
> We did not have a face-to-face meeting in Vancouver for IETF 107. At
> this point, the IETF 108 meeting in Madrid is also uncertain.
>
> We are therefore considering a virtual interim meeting for EMU during
> middle/end of May 2020. Here are some proposed dates and time slots:
> https://doodle.com/poll/vxy5vc4g3cnegpdr
>
> Please indicate your availability!
>
> Joe and Mohit
>
> ___
> 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] Poll for virtual interim

2020-04-19 Thread Mohit Sethi M
Dear all,

We did not have a face-to-face meeting in Vancouver for IETF 107. At 
this point, the IETF 108 meeting in Madrid is also uncertain.

We are therefore considering a virtual interim meeting for EMU during 
middle/end of May 2020. Here are some proposed dates and time slots:
https://doodle.com/poll/vxy5vc4g3cnegpdr

Please indicate your availability!

Joe and Mohit

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


Re: [Emu] Working Group Call For adoption of draft-aura-eap-noob-08.txt

2020-04-19 Thread Mohit Sethi M
Hi Alan,

On 4/19/20 7:18 PM, Alan DeKok wrote:
>
>> On Apr 18, 2020, at 4:13 PM, Joseph Salowey  wrote:
>>
>> This is a call for adoption of draft-aura-eap-noob-08.txt [1] as a working 
>> group item.  This draft has been discussed in several IETF meetings and 
>> would be the starting point for the working group deliverable for an EAP 
>> method based on "mutual authentication between a peer and a server that is 
>> based on an out-of-band channel."  Please review the draft and indicate 
>> whether you support adoption or not by May 4, 2020.
>I think it's OK.
Thank you for providing your input.
>
>I do have to question why the WG is engaging in new work, when the updates 
> to TTLS and PEAP are languishing.  That document is small.  There's been 
> positive feedback.  There have been only minor issues which have been 
> addressed in the most recent version.
>
>I think that we should be able to accept, last call, and publish the 
> document in short order.

The chairs had an email discussion which hadn't concluded. The main 
sticking point was that both Joe and I prefer TEAP being addressed in a 
separate update document that fixes all other TEAP errata as well. 
However, this can be discussed after adoption.

A working group adoption call is now issued and we intend to move this 
document forward rapidly.

--Mohit

>
>   Alan DeKok.
>
> ___
> 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


Re: [Emu] draft-dekok-emu-tls-eap-types discussion

2020-04-19 Thread Mohit Sethi M
No hat!

I support the adoption of this document!

--Mohit

On 4/3/20 11:48 PM, Alan DeKok wrote:
> https://tools.ietf.org/html/draft-dekok-emu-tls-eap-types-01
>
>I haven't seen much discussion on the document.  There are still some open 
> questions:
>
> * should it be published simultaneously with draft-ietf-emu-eap-tls13?
> If so, we need some consensus on this document, and quick.
>
> If not, when do we publish this draft?  Microsoft has already said that 
> they won't rev their EAP-TLS implementation until they can also rev PEAP.
>
> * Should the document simply drop references to FAST?
>It looks like the effort has moved to TEAP.
>Perhaps we should note that FAST cannot be used with TLS 1.3, and that 
> TEAP should be used instead
>
> * should the document drop references to TEAP?
>   Given Jouni Malinen's comments on implementing TEAP, it may be worth simply 
> noting that we're waiting for a TEAP update document
>
> * Without FAST / TEAP, the document is about 4 pages of text.  Is there 
> anything controversial, missing, etc?
>
> * What are the barriers to adoption and publication?
>
>Alan DeKok.
>
> ___
> 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


Re: [Emu] WGLC for draft-davidben-tls13-pkcs1-00

2020-03-16 Thread Mohit Sethi M
Thank you Russ. We have updated the text as suggested:

https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eaptlscert-02

--Mohit

On 3/9/20 11:09 PM, Russ Housley wrote:
I read the document, and I think it is read to go after one editorial fix.  The 
term "trust anchor" is used many times in the document, which is proper.  
However, in Section 3, the term "root-of-trust" is used.  Please change this to 
"trust anchor" and reference RFC 5280 for a definition.

Russ


On Mar 1, 2020, at 11:10 PM, Joseph Salowey 
mailto:j...@salowey.net>> wrote:

Hi Folks,

This is the working group last call for the "Large Certificates in TLS-based 
EAP Methods" draft available at 
https://datatracker.ietf.org/doc/draft-ietf-emu-eaptlscert/... Please review 
the document and send your comments to the list by 2359 UTC on 16 March 2020.

Note the the GH repo for this draft can be found at: 
https://github.com/emu-wg/eaptls-longcert

Thanks,

Joe





___
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


Re: [Emu] Late WGLC Comment on draft-ietf-emu-eap-tls13

2020-03-11 Thread Mohit Sethi M
Hi John,

I understand your concern of EAP restricting TLS authentication methods. 
However, it is not unusual for other groups to define profiles of a 
protocol they rely on.

If someone's IoT device wants only EAP-TLS-PSK and nothing else, then I 
believe we should enable that. I agree with you that a separate document 
and type code for each TLS authentication method is not ideal either. We 
could do something like EAP-TLS-FULL as you suggest (as long as 
developers can pick and choose only relevant TLS authentication method). 
Also, we are not yet running out of the type code (and expanded type 
code) space for now. If others are interested in defining some 
EAP-TLS-foo method later on, they have the liberty to do that.

--Mohit

On 3/11/20 10:01 AM, John Mattsson wrote:
> Hi,
>
> Russ Housley wrote:
>   >> I do not understand the reason for Bernard's objection.  I looked at the 
> minutes, and I do not find any rationale there.  Can you help?
>
> If I remember correctly, Bernard stated that the indroduction of PSK could 
> weaken the implementation and violate the security proofs of EAP-TLS. I don't 
> really agree with Bernard, but I am fine with resticting the type code 0x0D 
> to certificates only. I am not sure any proofs with TLS 1.1 would apply to 
> TLS 1.3 anyway as TLS 1.3 is basically a new protocol, reusing encoding and 
> IANA registers from the old version.
>
> Given that the EAP-TLS Type-Code 0x0D is decicated to Certificates, I am not 
> sure the approach to dedicate a new type code for PSK authentication is the 
> correct choice.
>
> psk_ke
> psk_dhe_ke
> tls_cert_with_extern_psk+psk_dhe_ke
>
> are just three of many authentication methods that may not fit in type code 
> 0x0D. Earlier versions of TLS have supported many more authentication methods
>
> KRB5
> anon
> SRP
> ECCPWD
>
> And just looking at the TLS WG documents, there are several future 
> authentication methods for TLS 1.3 likely in the future.
>
> https://datatracker.ietf.org/doc/draft-wang-tls-raw-public-key-with-ibc/
> https://datatracker.ietf.org/doc/draft-tschofenig-tls-cwt/
> https://datatracker.ietf.org/doc/draft-vanrein-tls-kdh/
>
> I do not think the EAP group should forbid any TLS 1.3 authentication method 
> unless there is valid reasons to do so. Instead of the current suggestion:
>
> 0x0D EAP-TLS (cert and nothing else)
> 0xTBDEAP-TLS-PSK (psk and psk+something else)
>
> I think a better way to structure things would be:
>
> 0x0D EAP-TLS (cert and nothing else)
> 0xTBDEAP-TLS-FULL (everything that TLS 1.3 supports)
>
> I sympatise with earlier comments in the group that EAP should mostly be a 
> transport for TLS and that the decisions of which authentication methods to 
> support should be taken by the TLS WG.
>
> Cheers,
> John
>
> -Original Message-
> From: Russ Housley 
> Date: Tuesday, 10 March 2020 at 18:48
> To: Mohit Sethi M 
> Cc: John Mattsson , EMU WG 
> Subject: Re: [Emu] Late WGLC Comment on draft-ietf-emu-eap-tls13
>
>  Thanks for the pointer.
>  
>  I am fine with the proposed way forward.
>  
>  Russ
>  
>  
>  > On Mar 10, 2020, at 12:43 PM, Mohit Sethi M 
>  wrote:
>  >
>  > Hi Russ,
>  >
>  > You can listen here: https://youtu.be/YJLG4JUftqI?t=1144
>  >
>  > We plan to support it in EAP-TLS-PSK instead:
>  > https://tools.ietf.org/html/draft-mattsson-emu-eap-tls-psk-00. We have
>  > already added a reference to draft-ietf-tls-tls13-cert-with-extern-psk
>  > and plan to use it. I think using an external PSK any ways requires
>  > ironing out some issues like what is the relationship between NAI and
>  > the PSK identity? And do we allow user-configured PSK identities/PSKs 
> etc.?
>  >
>  > Would it be reasonable if we specify the usage of
>  > draft-ietf-tls-tls13-cert-with-extern-psk in EAP-TLS-PSK instead?
>  >
>  > --Mohit
>  >
>  > On 3/10/20 6:30 PM, Russ Housley wrote:
>  >> I do not understand the reason for Bernard's objection.  I looked at 
> the minutes, and I do not find any rationale there.  Can you help?
>  >>
>  >> Russ
>  >>
>  >>
>  >>> On Mar 9, 2020, at 5:59 AM, John Mattsson 
>  wrote:
>  >>>
>  >>> Hi Russ,
>  >>>
>  >>> Sorry for the late reply. I actually brought up your draft 
> [ID-ietf-tls-tls13-cert-with-extern-psk] during my EMU presentation at IETF 
> 106 as something that should probably be in EAP-TLS. Bernard Aboba then 
> expressed a very strong opinion

Re: [Emu] Late WGLC Comment on draft-ietf-emu-eap-tls13

2020-03-10 Thread Mohit Sethi M
Hi Russ,

You can listen here: https://youtu.be/YJLG4JUftqI?t=1144

We plan to support it in EAP-TLS-PSK instead: 
https://tools.ietf.org/html/draft-mattsson-emu-eap-tls-psk-00. We have 
already added a reference to draft-ietf-tls-tls13-cert-with-extern-psk 
and plan to use it. I think using an external PSK any ways requires 
ironing out some issues like what is the relationship between NAI and 
the PSK identity? And do we allow user-configured PSK identities/PSKs etc.?

Would it be reasonable if we specify the usage of 
draft-ietf-tls-tls13-cert-with-extern-psk in EAP-TLS-PSK instead?

--Mohit

On 3/10/20 6:30 PM, Russ Housley wrote:
> I do not understand the reason for Bernard's objection.  I looked at the 
> minutes, and I do not find any rationale there.  Can you help?
>
> Russ
>
>
>> On Mar 9, 2020, at 5:59 AM, John Mattsson  wrote:
>>
>> Hi Russ,
>>
>> Sorry for the late reply. I actually brought up your draft 
>> [ID-ietf-tls-tls13-cert-with-extern-psk] during my EMU presentation at IETF 
>> 106 as something that should probably be in EAP-TLS. Bernard Aboba then 
>> expressed a very strong opinion that 
>> [ID-ietf-tls-tls13-cert-with-extern-psk] should absolutely not be included 
>> in the EAP-TLS Type-Code 0x0D. After this the WG decided as a way forward to 
>> specify EAP-TLS with PSK authentication in a new draft.
>>
>> Given these strong opinions from Bernard Aboba, and the wish to publish 
>> draft-ietf-emu-eap-tls13 soon. I think the best way forward would be specify 
>> the use of [ID-ietf-tls-tls13-cert-with-extern-psk] in the same new draft as 
>> EAP-TLS with PSK authentication. Does that sound like an acceptable way 
>> forward?
>>
>> Cheers,
>> John
>>
>> -Original Message-
>> From: Russ Housley 
>> Date: Monday, 13 January 2020 at 18:29
>> To: John Mattsson 
>> Cc: EMU WG 
>> Subject: Late WGLC Comment on draft-ietf-emu-eap-tls13
>>
>> John:
>>
>> Section 2.1.1 says:
>>
>>Pre-Shared Key (PSK) authentication SHALL NOT be used except
>>for resumption.
>>
>> I would rather this say:
>>
>>Pre-Shared Key (PSK) authentication SHALL NOT be used except
>>for resumption or in conjunction with the "tls_cert_with_extern_psk"
>>extension [ID-ietf-tls-tls13-cert-with-extern-psk].
>>
>> Russ
>>
>>
>>
> ___
> 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


Re: [Emu] WGLC for draft-ietf-emu-eaptlscert (corrected)

2020-03-05 Thread Mohit Sethi M
Hi Alan,

Thanks for your careful and detailed reviews. They are extremely helpful. We 
have submitted a new version addressing your feedback.

Please see in-line for specific actions taken. Here you can see the diff: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eaptlscert-01.

--Mohit

On 3/2/20 3:32 PM, Alan DeKok wrote:

  My $0.02 of nits:

1.

... Also,
   from deployment experience, EAP peers typically have longer
   certificate chains than servers.  ...

  It may be good to explain why?

Added info that peer chain often reflects organizational hierarchy.



... Therefore, EAP-TLS authentication
   usually involve significantly more bytes than when TLS is used as
   part of HTTPS. ...

  suggest "data" or "octets" instead of "bytes".  And elsewhere in the document.

Changed to octects everywhere except when describing the key lengths of RSA, 
ECC, etc.



... As the EAP fragment size in typical deployments are just 1000 - 1500
   bytes, ...

  RFC 3748 Section 4 says that the minimum MTU is 1020 octets.  It would be 
good to make this text agree with RCC 3748.  There are multiple such uses in 
the document.

Fixed all of them.



  It may be worth mentioning that some implementations support EAP over 
Ethernet "Jumbo" frames.  i.e. 8-9K.  Larger packets will help lower the number 
of round trips.  However, deployment shows that these jumbo frames are not 
always implemented correctly (I've run into this in the field).  Also, EAP is 
typically transported over RADIUS, which can generally transport only a bit 
under 4K of EAP data.

Added. Thanks again for your valuable deployment experience and insight.



  ... or example, many EAP authenticator
   (access point) implementations will drop an EAP session if it hasn't ...

 nit: avoid contractions here, and elsewhere in the document.

Makes sense. I think I removed all occurrences.



2.
...
   Readers are expected to be familiar with the terms and concepts used
   in EAP-TLS [RFC5216] and TLS [RFC8446].

  suggest: adding EAP [RFC3748]

Added.



...Can contain multiple object identifiers (OID) that indicate the
  permitted uses of the certificate.  For example, Windows requires
  certain OID's in the certificates for EAP-TLS to work...

  Suggest referencing RFC 5216 5.3 instead of "Windows", and perhaps adding a 
note that these checks are widely implemented, and enforced.

Fixed as suggested.




  It would be good to add a section 4.2.5, "using fewer intermediate 
certificates".

  I've seen situations where there are many, many, intermediate certificates.  
The reasons are generally that the certificate chain mirrors the organizational 
hierarchy of the business which is using it.  Such organizations also tend to 
fill each certificate field with large amounts of information, further bloating 
the certificate chain.

  It would be good to note that the certificate chains do *not* have to mirror 
the hierarchy of the organization.

  It would be good to note that most certificate chains should be 2-4 certs, 
and that there are few good reasons for using more than 6.

Added a new subsection.




  It may be good to add a section 4.2.6 "putting less information into each 
certificate".  See comments above.

  There are few good reasons to put full postal addresses into every 
intermediate cert.  When a company needs 6 certs to match their organizational 
hierarchy, those intermediate certs could just use "Department 42, Building 6" 
instead of a full postal / street address.

I added this info to the existing subsection on "Guidelines for certificates".



  i.e. the certs should contain sufficient information to determine who issued 
them, and how to contact the issuer.  This information is often site-specific, 
and can use site-specific terms.  The site-specific information does *not* need 
to be understandable by random members of the general public.



4.3
...  Vendors making new authenticators should consider increasing the
   number of round-trips allowed before denying the EAP authentication
   to complete

  Is there a suggestion here?  Should this number be configurable?

  i.e FreeRADIUS hard-codes this number to 50, and it is not configurable.  
wpa_supplicant hard-codes this to 100 (it was 40-50 for quite a while).  
wpa_supplicant allows it to be changed at compile time, but it is not 
configurable.   I took quick look at "iwd", and I can't find any limits there.  
Which seems wrong.

  It would be good to suggest that EAP peers examine their certificate chains, 
and make rough calculations as to how many round trips will be required.  e.g. 
take the total length of all certs, and divide by 1020.  That is the *mimimum* 
number of round trips required to do a full certificate exchange.  EAP peers 
MUST allow at least that many round trips, otherwise authentication will be 
impossible.

  Perhaps suggest EAP implementations use an upper limit of 100.  And then 
explain 

Re: [Emu] [lamps] EAP/EMU recommendations for client cert validation logic

2020-01-17 Thread Mohit Sethi M
On 1/16/20 6:07 AM, Benjamin Kaduk wrote:
> Is there anything better for implementations to actually do (as distinct
> from what we write down as recommendations) than to start setting up a
> parallel (purpose-specific) PKI now and trusting that in parallel with what
> they're currently doing, with the hope of being able to have a flag day
> many years down the line when the new PKI becomes the only thing that's
> trusted?
This seems like a reasonable way forward to me.

--Mohit

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


Re: [Emu] I-D Action: draft-ietf-emu-eap-tls13-08.txt

2020-01-07 Thread Mohit Sethi M
Hi Alan,

On 12/28/19 3:29 PM, Alan DeKok wrote:
> On Dec 27, 2019, at 1:54 PM, internet-dra...@ietf.org wrote:
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-08
>Which adds some text about identities:
>
> It is RECOMMENDED to use anonymous NAIs with the same realm in 
> the
>  resumption and the original full authentication.  This requirement   
>  allows EAP packets to be routable to the same destination as the 
>  original full authentication.
>
>That's good, thanks.  I still would prefer some additional text as I had 
> suggested.  The text explains related issues in more detail:
>
> The alternative is to derive the EAP Identity from the identity used
> inside of TLS. This derivation is common practice when using
> certificates, and works because the "common name" field in the
> certificate is typically compatible with EAP, and it contains a
> routable identifier such as an email address. This practice cannot be
> used for resumption, as the PSK identity may be a binary blob, and it
> might not contain a routable realm as suggested by RFC 7542.
>
> In some cases, the PSK identity is derived by the underlying TLS
> implementation, and cannot be controlled by the EAP
> authenticator. These limitations make the PSK identity unsuitable for
> use as the EAP Identity.
>
>I find it's easier for people to follow recommendations when they have a 
> full picture of the pros and cons of the choices being recommended.
>
>For the original authentication:
>
> Anonymous NAIs MAY be derived from
>  the client certificate used in TLS.  Client certificates typically   
>  contains an identity with a routable domain such as an email address.
>
>How is this derivation done?   Many things "may" be done, but that doesn't 
> help guide *why* or *how* things are done.
>
>If there's no clear guidance possible, then that should be said, too.
>
>I also believe that the document should also RECOMMEND that the 
> EAP-Response/Identity be in the form of an anonymous NAI.

The current text already says this in 2.1.7: "EAP-TLS peer and server 
implementations supporting TLS 1.3 or higher MUST support anonymous NAIs 
(Network Access Identifiers) (Section 2.4 in [RFC7542]) and a client 
supporting TLS 1.3 MUST NOT send its username in cleartext in the 
Identity Response. It is RECOMMENDED to use anonymous NAIs, but other 
privacy-friendly identities (e.g. encrypted usernames) MAY be used."

While identities MAY be derived from the certificate, they can also be 
configured by the user. As a co-author, I don't think we should 
over-prescribe only one way of doing it.

--Mohit

>
>I would prefer to have a separate section about identities. I find the 
> current text a bit unclear. It helps to explain why an anonymized NAI is 
> useful, even when there is no email address in a certificate.
>
>Alan DeKok.
>
> ___
> 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


Re: [Emu] I-D Action: draft-ietf-emu-eap-tls13-08.txt

2020-01-07 Thread Mohit Sethi M
Hi Alan,

On 12/28/19 3:29 PM, Alan DeKok wrote:
> On Dec 27, 2019, at 1:54 PM,internet-dra...@ietf.org  wrote:
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-08
>Which adds some text about identities:
>
> It is RECOMMENDED to use anonymous NAIs with the same realm in 
> the
>  resumption and the original full authentication.  This requirement   
>  allows EAP packets to be routable to the same destination as the 
>  original full authentication.
>
>That's good, thanks.  I still would prefer some additional text as I had 
> suggested.  The text explains related issues in more detail:
>
> The alternative is to derive the EAP Identity from the identity used
> inside of TLS. This derivation is common practice when using
> certificates, and works because the "common name" field in the
> certificate is typically compatible with EAP, and it contains a
> routable identifier such as an email address. This practice cannot be
> used for resumption, as the PSK identity may be a binary blob, and it
> might not contain a routable realm as suggested by RFC 7542.
>
> In some cases, the PSK identity is derived by the underlying TLS
> implementation, and cannot be controlled by the EAP
> authenticator. These limitations make the PSK identity unsuitable for
> use as the EAP Identity.

Is there a case when the PSK identity is not derived by the underlying 
TLS implementation? And perhaps you meant to say that it cannot be 
controlled by the EAP peer (rather than the EAP authenticator)?

--Mohit

>I find it's easier for people to follow recommendations when they have a 
> full picture of the pros and cons of the choices being recommended.
>
>For the original authentication:
>
> Anonymous NAIs MAY be derived from
>  the client certificate used in TLS.  Client certificates typically   
>  contains an identity with a routable domain such as an email address.
>
>How is this derivation done?   Many things "may" be done, but that doesn't 
> help guide *why* or *how* things are done.
>
>If there's no clear guidance possible, then that should be said, too.
>
>I also believe that the document should also RECOMMEND that the 
> EAP-Response/Identity be in the form of an anonymous NAI.
>
>I would prefer to have a separate section about identities. I find the 
> current text a bit unclear. It helps to explain why an anonymized NAI is 
> useful, even when there is no email address in a certificate.
>
>Alan DeKok.
>
> ___
> 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


  1   2   >