[Emu] Re: WGLC for draft-ietf-emu-bootstrapped-tls

[Russ Housley]

When this document reaches IETF Last Call, RFC 8773 needs to be called out as a 
downref.  This downref seems fine to me.

Russ


> On Sep 11, 2024, at 4:32 PM, Peter Yee  wrote:
> 
> Along with draft-ietf-emu-eap-arpa, I've placed 
> draft-ietf-emu-bootstrapped-tls into a WGLC ending on September 25th. As of 
> the latest version, it is aligned with draft-ietf-emu-eap-arpa. The document 
> is a short read, so please look it over and provide review comments to the 
> mailing list. It can be found at 
> https://datatracker.ietf.org/doc/draft-ietf-emu-bootstrapped-tls/. The 
> aforementioned eap.arpa document is at 
> https://datatracker.ietf.org/doc/draft-ietf-emu-eap-arpa/. 
> 
> Thank you.
> 
>   -Peter and Joe

___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org

Re: [Emu] Adoption call for RFC 7170bis

[Russ Housley]

I support adoption.

> On Dec 15, 2022, at 5:29 PM, Peter Yee  wrote:
> 
> This is an adoption call for RFC 7170bis (draft-dekok-emu-rfc7170bis-00)[1].
> I'd call this mostly a formality since it's pretty clear the WG is
> interested in updating TEAP and TEAP was already adopted by the WG (back in
> May 2011). With Alan having generated a new working version to host the
> update and even preparing a Git repository[2] to that end, I believe we're
> in a good place to revise RFC 7170. That said, if anyone has an objection to
> starting off from Alan's kind offering, please let us know by December 22,
> 2022. 
> 
> Joe and Peter
> 
> 1) https://datatracker.ietf.org/doc/draft-dekok-emu-rfc7170bis/
> 2) https://github.com/alandekok/rfc7170-bis.git
> 
> 
> 
> ___
> 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] Working Group Last Call for draft-ietf-emu-tls-eap-types

[Russ Housley]

> On Jun 14, 2022, at 2:12 PM, Alan DeKok  wrote:
> 
> On Jun 13, 2022, at 3:57 PM, Russ Housley  wrote:
>> 
>> Major concerns:
>> 
>> Section 3, 3rd para: It is unclear to me what "relevant resumption and/or 
>> EAP type" means.  Please expand this discussion.
> 
>  In context:
> 
> 
> As a result, implementations MUST check for application data once the
> TLS session has been established.  This check MUST be performed before
> proceeding with another round trip of TLS negotiation.  If application
> data is available, it MUST be processed according to the relevant
> resumption and/or EAP type.
> 
>  The intent here is to say "if there's application data, just use that".  I 
> think the reference to "resumption" is superfluous, and can be removed or 
> clarified.
> 
>  Perhaps:
> 
> As a result, implementations MUST check for application data once the
> TLS session has been established.  This check MUST be performed before
> proceeding with another round trip of TLS negotiation.  If application data is
> received by the EAP peer, any session tickets offered by the supplicant
> MUST be ignored, and resumption MUST NOT take place.
> 
> The interpretation and processing of application data is dependent on the EAP 
> type
> which has been negotiated.  On receiving application data, an EAP 
> implementation
> MUST follow the relevant specification (defined by the EAP type) for 
> processing
> that application data.

This is helpful.  Thanks.

> 
>  We didn't need similar text for TTLS / PEAP / FAST, because application data 
> was always interpreted as that particular EAP type.  We need some clarifying 
> text here, because we're talking about TLS-based EAP types in general, and 
> not any specific type.
> 
>  I'm not sure how to clarify this any more, otherwise than by deleting the 
> text.

I think you should just say that: TTLS, PEAP, and FAST each have 
method-specific application data.

> 
>> Minor concerns:
>> 
>> Section 2 says:
>> 
>>   There remain some differences between EAP-TLS and other TLS-based EAP
>>   methods which necessitates this document.  The main difference is
>>   that [RFC9190] uses the EAP-TLS Type (value 0x0D) in a number of
>>   calculations, whereas other method types will use their own Type
>>   value instead of the EAP-TLS Type value.  This topic is discussed
>>   further below in Section 2.
>> 
>> I assume this should be a forward pointer to Section 2.1.
> 
>  Sure.

Thanks.

> 
>> Section 2.1 uses || to indicate concatenation, but Section 2.2 uses |.  
>> Please pick one.
> 
>  RFC 9190 uses ||, so we'll stick with that.  The text in Section 2.2 was 
> lifted from RFC 7170, which uses |

Either one is fine with me.  Please be consistent.

> 
>> 
>> Section 2.1 says:
>> 
>>   ...  There does not
>>   appear to be compelling reasons to make the labels method-specific,
>>   when they can just include the logical Type in the key derivation.
>> 
>> I think it would be more clear to say that the inclusion of the logical Type 
>> makes the result method-specific.
> 
>  OK.  I'll update the text.

Thanks.

>> Nit:  The author on the title page should be "A. DeKok"
> 
>  Fixed, thanks.

Thanks.

This resolves all of my concerns.

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

Re: [Emu] Working Group Last Call for draft-ietf-emu-tls-eap-types

[Russ Housley]

Major concerns:

Section 3, 3rd para: It is unclear to me what "relevant resumption and/or EAP 
type" means.  Please expand this discussion.


Minor concerns:

Section 2 says:

   There remain some differences between EAP-TLS and other TLS-based EAP
   methods which necessitates this document.  The main difference is
   that [RFC9190] uses the EAP-TLS Type (value 0x0D) in a number of
   calculations, whereas other method types will use their own Type
   value instead of the EAP-TLS Type value.  This topic is discussed
   further below in Section 2.

I assume this should be a forward pointer to Section 2.1.


Section 2.1 uses || to indicate concatenation, but Section 2.2 uses |.  Please 
pick one.


Section 2.1 says:

   ...  There does not
   appear to be compelling reasons to make the labels method-specific,
   when they can just include the logical Type in the key derivation.

I think it would be more clear to say that the inclusion of the logical Type 
makes the result method-specific.


Nit:  The author on the title page should be "A. DeKok"

Russ


> On Jun 8, 2022, at 12:16 PM, Joseph Salowey  wrote:
> 
> This is the working group last call for draft-ietf-emu-tls-eap-types.  You 
> can find the document here: 
> 
> https://datatracker.ietf.org/doc/html/draft-ietf-emu-tls-eap-types 
> 
> 
> Please respond to the list with comments by June 24, 2022.   Responses that 
> indicate that you have read the draft and think it is ready to move forward 
> are also useful.  
> 
> Thanks,
> 
> Joe & 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] Call for Adaption for draft-chen-emu-eap-tls-ibs

[Russ Housley]

1.  Not sure.  I do not object, but I am not sure how many people want to 
implement.

2.  I will review the ASN.1.  In fact, I already did so.

3.  I contributed corrections to the ASN.1.

Russ

From: Joseph Salowey 
Date: 2022-04-11 11:35
To: EMU WG 
Subject: [Emu] Call for Adaption for draft-chen-emu-eap-tls-ibs
This is an adoption call for EAP-IBS 
(https://datatracker.ietf.org/doc/draft-chen-emu-eap-tls-ibs/ 
)
 as an EMU working group item.  Please respond to this call and answer the 
following questions by April 24, 2022:

1. Do you think this draft should be an EMU working group Item?

2. Would you contribute by reviewing this document?

3. Would you contribute text to this document?

Thanks,

The Chairs

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

Re: [Emu] Working Group Last Call for TLS-based EAP types and TLS 1.3

[Russ Housley]

> On Feb 19, 2022, at 8:57 AM, Alan DeKok  wrote:
> 
>> - The MAC function in section 2.2 is not defined. I assume it should be 
>> HMAC. Suggestion:
>> 
>>  OLD
>> For TLS 1.3, the hash function used is the same as the
>> ciphersuite hash function negotiated for HKDF in the key schedule, as
>> per section 7.1 of RFC 8446.
>>  NEW
>> For TLS 1.3, MAC is HMAC using the ciphersuite hash function negotiated 
>> for
>> HKDF in the key schedule, as per section 7.1 of RFC 8446.
> 
>  It's good to define "MAC" here.  The construct "MAC is HMAC" sounds awkward 
> to me tho.  I'll try to come up with some phrasing.

For TLS 1.3, the message authentication code (MAC) is compute with the HMAC 
algorithm ...


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

Re: [Emu] EAP-TLS 1.3 Section 2.2 text

[Russ Housley]

Nit: RFC 5280 (see Section 4.2.1.6) talks about the subject alternative name 
extension, which as an ASN.1 definition for SubjectAltName.  So, please do not 
refer to subjectAlternativeName.

Russ


> On May 15, 2021, at 8:21 PM, Joseph Salowey  wrote:
> 
> I proposed a PR#72 
>  based on this 
> suggestion. The resulting text for the section is below.  Please review to 
> see if it is OK.
> 
> Thanks,
> 
> Joe
> 
> 2.2.  Identity Verification
> 
>This section updates Section 2.2 of [RFC5216].
> 
>The EAP peer identity provided in the EAP-Response/Identity is not
>authenticated by EAP-TLS.  Unauthenticated information SHALL NOT be
>used for accounting purposes or to give authorization.  The
>authenticator and the EAP-TLS server MAY examine the identity
>presented in EAP-Response/Identity for purposes such as routing and
>EAP method selection.  EAP-TLS servers MAY reject conversations if
>the identity does not match their policy.  Note that this also
>applies to resumption, see Sections 2.1.3, 5.6, and 5.7.
> 
>The EAP server identity in the TLS server certificate is typically a
>fully qualified domain name (FQDN).  EAP peer implementations SHOULD
>allow users to configure 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.  EAP-TLS deployments will often use more
>than one EAP server.  In this case each EAP server may have a
>different certificate.  To facilitate SAN matching, EAP Server
>certificates can include the same name in the list of SANs for each
>certificate that represents the EAP-TLS servers.  EAP-TLS peers
>SHOULD allow for the configuration of multiple EAP server names since
>deployments may choose to use multiple EAP servers each with their
>own 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 for the network.  If name matching is not used with
>a public root CA, 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 is
>non-trivial and therefore automated methods of provisioning are
>RECOMMENDED.  For example, the eduroam federation [RFC7593] provides
>a Configuration Assistant Tool (CAT) to automate the configuration
>process.  In the absence of a trusted root CA certificate (user
>configured or system-wide), EAP peers MAY implement a trust on first
>use (TOFU) mechanism where the peer trusts and stores the server
>certificate during the first connection attempt.  The EAP peer
>ensures that the server presents the same stored certificate on
>subsequent interactions.  Use of a TOFU mechanism does not allow for
>the server certificate to change without out-of-band validation of
>the certificate and is therefore not suitable for many deployments
>including ones where multiple EAP servers are deployed for high
>availability.
> 
> On Mon, May 10, 2021 at 5:11 AM Alan DeKok  > wrote:
> On May 9, 2021, at 9:16 PM, Joseph Salowey  > wrote:
> > [Joe]  This is a good question.  There are multiple ways this could be 
> > addressed.  All servers should have one of their list of SANs that matches 
> > the name used for EAP servers.  Another option is for supplicants to allow 
> > for the configuration of multiple certificates or allow for a wild card 
> > match.
> 
>   FWIW, wpa_supplicant has a list of allowed host names for SAN.  I don't 
> think it allows wildcards.
> 
> >   How about this text addition:
> > 
> > "EAP-TLS deployments will often use more than one EAP server.  In this case 
> > each EAP server may have a different certificate.  To facilitate the SAN 
> > matching, EAP Server certificates can include the same name in the list of 
> > SANs for each certificate that represents the EAP-TLS servers.  EAP-TLS 
> > peers SHOULD allow for the configuration of multiple EAP server names since 
> > deployments may choose to use multiple EAP servers each with their own 
> > certificate." 
> 
>   That's good.
> 
> > [Joe] Is your comment about HA and the TOFU mechanism?  I'm not really sure 
> > how the TOFU mechanism is supposed to work and be secure.  Perhaps we 
> > should remove the TOFU mechanism text or state that it does not work well 
> > in all HA configurations (where different servers use different 
> > certificates)
> 
>   Perhaps just state that it does not work well in HA configurations.
> 
>   I don't think TOFU can be secure here.
> 
>   Alan DeKok.
> 
> ___
> Emu mailing list
>

Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling

[Russ Housley]

Michael:

>> I am aware of some places that generate an OCSP response for the entire
>> population of certificates, and those responsed are distributed to many
>> locations.  I am not aware of anyone that distributes the OCSP
>> responder signature private key to multiple locations.
> 
> Does anyone put different OCSP signers into different certificates?
> I.e. shard the work?

This could be done by including different AIA certificate extensions, but I am 
not aware of anyone that does so.

> I think that splitting the OCSP reponses to many locations might solve the
> industrial situation well.

One could put multiple id-ad-ocsp entries in the AuthorityInfoAccess extension, 
but this could lead to a relying party trying each one in turn, resulting in a 
long timeout interval.

Russ

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

Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling

[Russ Housley]

>> The second is, I think, that the EAP server (Authentication Server), would 
>> run
>> an OCSP responder locally so that it can mint it's own staples.
>> AFAIK, each certificate can point to a different OCSP signer.
> 
> Does anyone actually do that?

I am aware of some places that generate an OCSP response for the entire 
population of certificates, and those responsed are distributed to many 
locations.  I am not aware of anyone that distributes the OCSP responder 
signature private key to multiple locations.

Russ

___
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

[Russ Housley]

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

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

[Emu] Iotdir telechat review of draft-ietf-emu-rfc5448bis-07

[Russ Housley via Datatracker]

Reviewer: Russ Housley
Review result: Ready with Issues

I reviewed this document as part of the IoT Directorate's effort to
IoT-related IETF documents being processed by the IESG.  These comments
were written primarily for the benefit of the Internet Area Directors.
Document authors, document editors, and WG chairs should treat these
comments just like any other IETF Last Call comments.

Document: draft-ietf-emu-rfc5448bis-07
Reviewer: Russ Housley
Review Date: 2020-03-24
IETF LC End Date: 2020-01-29
IESG Telechat date: 2020-04-09


A review from the IoT Directorate was requested on 2020-03-23, which is
after the IETF Last Call ended.  I assume that the Internet ADs want
this review to help inform them during IESG Evaluation.

Note: I did not review the Appendices.


Summary: Ready with Issues


Major Concerns:

Section 5.2 says:

   The pseudonym usernames and fast re-authentication identities MUST be
   generated in a cryptographically secure way so that that it is
   computationally infeasible for an attacker to differentiate two
   identities belonging to the same user from two identities belonging
   to different users.  This can be achieved, for instance, by using
   random or pseudo-random identifiers such as random byte strings or
   ciphertexts.  See also [RFC4086] for guidance on random number
   generation.

It is not clear to me that a random number generator is needed to hide
the identities.  For example, a hash of a configured secret value and a
counter are probably good enough.  There are clearly other ways to do it
too, and some of them need a random number generator.  Because of the
way this is worded, it is not clear not me that my proposed solution
would meet the MUST statement.  I do not think we want to make this
harder than necessary.

Section 7 says:

  In general, it is expected that the current negotiation
  capabilities in EAP-AKA' are sufficient for some types of
  extensions and cryptographic agility, including adding Perfect
  Forward Secrecy ([I-D.ietf-emu-aka-pfs]) and perhaps others.  But
  as with how EAP-AKA' itself came about, some larger changes may
  require a new EAP method type.

I do not think it it appropriate to claim cryptographic agility when
SHA-256 and HMAC-SHA-256 are hardwired.  It would be better to say that
a new EAP method will be defined to change the algorithms (as was done
to make EAP-AKA' in the first place).


Minor Concerns:

Section 1 includes the summary of changes from RFC 5448.  However, it
does not mention the addition of Sections 3.5 and 4.1.  Please add them.

Section 3.1 says:

   Only the server sends the AT_KDF_INPUT attribute.  The value is sent
   as specified in [TS-3GPP.24.302] for both non-3GPP access networks
   for 5G access networks.  

There are some missing words here.  I am not really sure what is
intended, so I cannot offer a fix.

Section 5.3.1 says:

  Again, the identity MUST be used exactly as sent.

Please delete!  Saying it twice does not make it a stronger MUST.

Section 7.2: s/encrypt all payload traffic after encryption/
  /encrypt all payload traffic after authentication/


Nits:

Section 1: s/ non-goal of this draft/ non-goal of this memo/

There is a misalignment in the bottom box in Figure 1.  This is
surprising because the figure is otherwise identical to the one in
RFC 5448.

In Section 3.5: The introduction to the numbered columns is simply
"In addition:".  For clarity, I think it would be better to say
something like:

   The numbered columns indicate the quantity of the attribute
   within the message as follows:

Section 5.1: s/(see Section 5.3.2 and Section 5.3.2.1./
  /(see Section 5.3.2 and Section 5.3.2.1)./

Section 5.3: s/as defined in this RFC/as defined in Section 5.1/

I suggest the following structure for Section 5.3.1:

   5.3.1.   Key Derivation
   5.3.1.1  Format of the SUPI
   5.3.1.2  Format of the other identities

Section 6: s/Peer-Id is null string/Peer-Id is the null string/

Section 7.2: s/recommendations from Section 5.2 need to be
   followed to avoid this.
Section 7.2: s/following the recommendations in Section 5.2
   mitigate this concern./



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

Re: [Emu] WGLC for draft-davidben-tls13-pkcs1-00

[Russ Housley]

Thanks!

> On Mar 16, 2020, at 3:41 AM, Mohit Sethi M  wrote:
> 
> Thank you Russ. We have updated the text as suggested:
> 
> https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eaptlscert-02 
> <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/ 
>>> <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 
>>> <https://github.com/emu-wg/eaptls-longcert>
>>> 
>>> Thanks,
>>> 
>>> Joe
>>> 
>> 
>> 
>> 
>> ___
>> Emu mailing list
>> Emu@ietf.org <mailto:Emu@ietf.org>
>> https://www.ietf.org/mailman/listinfo/emu 
>> <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

[Russ Housley]

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 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] Late WGLC Comment on draft-ietf-emu-eap-tls13

[Russ Housley]

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

Re: [Emu] WGLC for draft-davidben-tls13-pkcs1-00

[Russ Housley]

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

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

[Russ Housley]

> On Mar 9, 2020, at 10:28 AM, Alan DeKok  wrote:
> 
>> The
>>  subject name in client certificates typically contains an identity
>>  with a routable domain such as an email address.
> 
>  The email address may not be routable.  Perhaps:
> 
> The subject name in client certificates typically contains an identity such 
> as an email address, which is already in the NAI format.

The email address is often in the SubjectAltName extension.  I know it is often 
part of the Subject, but it could be in either spot.

Russ

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

Re: [Emu] [lamps] EAP/EMU recommendations for client cert validation logic

[Russ Housley]

It seems to me that RFC 4334 offers a way for an enterprise to assert that the 
certificate is intended to be used with a particular SSID.  This seems better 
than a self-signed certificate with just a domain name.

I understand that CA/B Forum does not allow these extensions and attributes, 
but as already highlighted in thi discussion, these certificates are not part 
of the Web PKI.

Russ

> On Jan 19, 2020, at 10:07 AM, Alan DeKok  wrote:
> 
> On Jan 18, 2020, at 6:30 PM, Ryan Sleevi  wrote:
>> Great. Let’s focus on one problem at a time to make sure it’s easier to 
>> follow along. Earlier in the thread you seemed fixated on the first problem, 
>> so it’s unclear when/where/how shifted to the second.
> 
>  Perhaps less "fixated" than "trying to achieve a common understanding.
> 
>  It's best to understand the current situation before designing any solution.
> 
>> The alternative is the application ships it’s own root store. Which 
>> applications have been doing for 20+ years and which modern OSes make even 
>> easier.
> 
>  The question here is *what* root store?  It's easy for browsers to ship root 
> stores.  The WWW root stores are well known. 
> 
>  What root store is already widely known, and trusted for EAP?
> 
>> Not really? CAs are plenty happy to sell whatever folks want. Look at stuff 
>> like the drone PKI being developed.
> 
>  CAs are in *theory* happy to sell things.  In practice, it's difficult to 
> get non-WWW certificates.
> 
>> I already gave that answer several times. Define your profile and policies, 
>> pick (different) roots, and ship them in your software. It’s mistaken to 
>> suggest that you HAVE to use the same roots as the OS.
> 
>  I think you're operating from a WWW perspective.  That use-case is very 
> different from EAP.  In WWW, 99% of the TLS-enabled traffic is from the 
> server to the client.  The client doesn't know what the information is, and 
> doesn't really care.  Even secret information like passwords sent to a web 
> server are generated by / on that web server.  So a client can verify (a) the 
> password was created for a proven server using a trusted CA, and next time 
> (b) prove it's the same server, so it's OK to send over the password.
> 
>  EAP is completely different.  I have *my* password.  It's secret, and I made 
> it.  I want to be sure that I give it *only* to the site which is authorized. 
>  This means that I don't really care that a root CA is trusted.  That root CA 
> might sign certificates for 1000 companies.  I want to have my password only 
> to one company; the correct one.  I want the client supplicant to *not* hand 
> my password to the other ones.  I have no DNS to leverage, either.
> 
>  To put it another way, in WWW, the server has data that the client wants.  
> In EAP, the client has data (passwords) that the server wants.  The trust 
> models are very different.
> 
>  The goal then is to get to the point where a supplicant can verify that the 
> server cert is signed by a trusted CA, *and* that it's the server cert that 
> the client wants.
> 
>  Shipping a trusted root CA on the supplicant OS is the *only* way to do this.
> 
>> No, there doesn’t. That’s an unreasonable demand, because it’s insisting 
>> that advocates of the problem don’t want to actually do the work involved in 
>> developing a solution for the problem. There’s absolutely no reason to 
>> require that it be shipped as part of the OS. Plenty of PKIs exist without 
>> requiring that, and modern OSes make it easier.
> 
>  See above.
> 
>  This isn't just "ship a root CA with an EAP / RADIUS server".  That's a 
> trivial problem to solve.  If you want to use a RADIUS server, it may be OK 
> to trust the CAs included with that product.  The same goes for browsers.
> 
>  But what are the poor end users going to do with their EAP supplicants?  
> Pretty much *zero* of them have ever downloaded a supplicant "application".  
> So that route is completely off of the table.
> 
>  Instead the supplicant is shipped with the OS. Therefore, any root CAs 
> needed by the supplicant MUST be included with the OS.
> 
>  It really is that simple.
> 
>  In conclusion, we need a new PKI, and the root CAs must be included with OS 
> distributions.  But the OS vendors won't do that until we define the 
> requirements, solution, and transition path.
> 
>  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] Late WGLC Comment on draft-ietf-emu-eap-tls13

[Russ Housley]

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

Re: [Emu] Idea: New X509 Extension for securing EAP-TLS

[Russ Housley]

> On Nov 12, 2019, at 2:53 AM, Jan-Frederik Rieckers  
> wrote:
> 
> Signed PGP part
> On 12.11.19 00:15, Owen Friel (ofriel) wrote:
>> One deployment consideration is if an operator wants to use a public PKI 
>> (e.g. Lets Encrypt) for their AAA certs, then it could be years, if ever, 
>> before these extensions could be supported (as Alan alludes to), so it would 
>> also be good to define how this could work with standard RFC 6125 DNS-IDs / 
>> RFC 5280 dNSNames.
> 
> I had a lot of thoughts about this topic.
> I am experimenting with certificates in EAP-TLS contexts and experienced
> the problems with getting a certificate with specific extension
> properties from our public PKI. (In my case a test certificate with a
> critical MustStaple extension)
> 
> The Problem with dNSNames is that they are also used in other contexts
> (mainly HTTPS). There would be the possibility to define a specific
> prefix to bind it to a Realm without having the certificate being valid
> for the HTTPS host (e.g. eap-tls.uni-bremen.de for the realm
> uni-bremen.de) but I don't see the advantage in that.
> This will probably don't really lead to a change in the supplicants
> implementations.
> 
> My deployment experience shows, that the certificate check is the main
> security problem in WPA2-Enterprise networks. I have seen instructions
> for installing WPA2-Enterprise networks where they have explicitly
> suggested switching off the certificate check, probably because it was
> too complicated for the users and would lead to people complaining at
> the IT department about the complicated setup.
> 
> A setup of WPA2-Enterprise can be secure if all devices are part of a
> centralized Device Management, but especially in eduroam this isn't
> possible. We have a lot of people who don't really care about security.

Can the extended key usage for EAP over a LAN ( id-kp-eapOverLAN ) solve this 
for you?  It is defined in RFC 4334.  A certificate for Web PKI should not 
include this extended key usage.

RFC 4334 also offers a certificate extension that lists the SSIDs that are 
associated with the server.

Russ




signature.asc
Description: Message signed with OpenPGP
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Idea: New X509 Extension for securing EAP-TLS

[Russ Housley]

Alan:
> 
> On Nov 9, 2019, at 1:00 PM, Russ Housley  wrote:
>> 
>> With a very quick skim, it appears that you are trying to do the same thing 
>> as RFC 7585.
> 
>  I think there's overlap, but it's not quite the same thing.
> 
>  Both proposals add a "known realm" as an X.509 certificate property.  They 
> differ in their usage, and in who is checking the fields.  I'll quickly recap:
> 
>  RFC 7585 allows for RADIUS clients to dynamically discover RADIUS servers 
> via DNS.  As a sanity check, the discovered RADIUS server should induce the 
> "known realm" in its server certificate.  The RADIUS client verifies that the 
> "known realm" field matches the domain it was looking for.  Note that this 
> verification is done by a RADIUS client, and is independent of the 
> authentication mechanism carried inside of RADIUS.  (PAP, CHAP, EAP, etc.)
> 
>  In this proposal, the supplicant is the component which is checking the 
> "known realm" field.  The supplicant verifies that the NAI it's sending 
> matches the "known realm" sent by the server.
> 
>  It is common practice today for server certificates to include a contact 
> email address in the common name field.  However, there's no requirement that 
> this is done.  No one checks the domain of that email address against the NAI 
> being used by the supplicant.
> 
>  I think that this proposal may be useful.  Given that the parties who check 
> this field do so for different purposes, it may be useful to have two 
> separate OIDs.
> 
>  On the other hand, RCC 7585 uses the OID for TLS connections which then 
> carry RADIUS packets.  This draft would use an OID for EAP-TLS 
> authentications, which are carried inside of RADIUS, and then inside of UDP / 
> TCP / TLS / DTLS.  The uses-cases may be different enough to warrant re-use 
> of the same OID.

Thanks for the overview.  It was very helpful.

RFC 7586 define the NAIRealm as an otherName in the SubjectAltName of a 
certificate.  It seems that the NAIRealm name form works equally well, 
regardless of the role that the certificate holder is performing in the 
protocol.

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

Re: [Emu] Idea: New X509 Extension for securing EAP-TLS

[Russ Housley]

With a very quick skim, it appears that you are trying to do the same thing as 
RFC 7585.

Russ


> On Nov 9, 2019, at 12:33 PM, Jan-Frederik Rieckers  
> wrote:
> 
> Signed PGP part
> Hi to all,
> 
> I have submitted a draft for a new X509v3 extension to improve security
> in EAP environments by including information which is implicitly defined
> by the communication context in the certificate .
> This is done e.g. by including the Realm of the username in the
> certificate, to give clients the opportunity to decide if the
> certificate can be trusted apart from (user-set) configuration.
> 
> https://datatracker.ietf.org/doc/draft-rieckers-eapparameterextension/
> 
> This is a very early working state. I would be happy to get feedback if
> this is useful and the draft goes into the right direction.
> 
> If people are interested I would prepare a short presentation about
> deployment experiences in the eduroam at the University Bremen,
> which have lead to this draft, together with the basic idea how to solve
> these problems.
> 
> Probably this draft is not one which can or will be adopted by the EMU
> working group, but I think this is the right group of people for a first
> feedback.
> 
> Kind regards
> 
> Jan-Frederik Rieckers
> 
> 
> 

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

Re: [Emu] Minutes from EMU @ IETF103

[Russ Housley]

Concern:

Jari: Need feedback. See this as WG document? We might be able to stick this in 
and have affect on organizations that want to spy on. We might actually get 
this deployed if . 

The end of the sentence is missing...


Nit:

Russ: MAC is dependent on the based AKA authentication.

s/based/base/
s/AKA/AKA'/


> On Nov 13, 2018, at 4:38 AM, Mohit Sethi M  wrote:
> 
> Hi all,
> 
> Thank you for participating in the EMU session at IETF 103. A special 
> thank you to Jim for serving as the jabber scribe.
> 
> Minutes from the EMU session at IETF 103 have now been uploaded:
> https://datatracker.ietf.org/meeting/103/materials/minutes-103-emu-00
> 
> Please report any issues by November 21, 2018.
> 
> 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] draft-ietf-emu-rfc5448bis-03

[Russ Housley]

I agreed to review this document at IETF 103.  Here are my comments.

Document: draft-ietf-emu-rfc5448bis-03
Reviewer: Russ Housley
Review Date: 2018-11-13

Summary: Almost Ready


Major Concerns:

The Abstract is essentially unchanged from RFC 5448.  I think it would
be better to provide the history of AKA and AKA' in a sentence or two
and then tell the big changes that appear here.  I found the part about
SHA-1 especially concerning until I realized that was left over from the
RFC 5448 Abstract text.

I think the Introduction should be updated to provide a perspective for
a new implementer.  I suggest something like this:
  - 3GPP uses AKA' natively and as an EAP method.
  - EAP-AKA originally defined in [RFC4187]
  - EAP-AKA' defined in [RFC5448], and uses KDF in [TS-3GPP.33.402]
  - This update supports identifiers needed for 5G
-- This version of the EAP-AKA' specification obsoletes RFC 5448
-- List of the changes made by this update
  - Negotiation of the various versions

Section 3.2 says:

   AT_KDF

  This is set to 24.

And, then Section 3.3 says:

   AT_KDF set to 1

The second one is shorthand for the KDF identifier carried in the
attribute.  I think that you should not use this shorthand.  I
stumbled on it when reading.  I suggest:

   AT_KDF parameter has the value 1

Section 5.3 says:

   Given the choice between these two types of identifiers, two areas
   need further specification in EAP-AKA' to ensure that different
   implementations understand each other and stay interoperable:

This should be reworded.  These do not need future specification.
Those details are in the document.  I think it would be better to say:

   Given the choice between these two types of identifiers, EAP-AKA'
   ensure interoperability by:


Minor Concerns:

Section 3: s/EAP-AKA' is a new EAP method/EAP-AKA' is an EAP method/

Section 3 does not seem to be different from RFC 5448.  Would it be
better to list the changes from RFC 4187 (AKA to AKA') and then the
changes from RFC 5448 (AKA' to this update)?


Nits:

The document uses "key generation" and "key derivation".  If they are
different, please add an explanation somewhere.  If they are the same,
please use one term throughout.

The document uses "byte" and "octet".  Please use one term throughout.

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

Re: [Emu] I-D Action: draft-ietf-emu-rfc5448bis-02.txt

[Russ Housley]

The Abstract says:  This specification defines a new EAP method...

At this point, we should probably drop 'new'.

Russ


> On Sep 17, 2018, at 9:02 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   : Improved Extensible Authentication Protocol Method 
> for 3rd Generation Authentication and Key Agreement (EAP-AKA')
>Authors : Jari Arkko
>  Vesa Lehtovirta
>  Vesa Torvinen
>  Pasi Eronen
>   Filename: draft-ietf-emu-rfc5448bis-02.txt
>   Pages   : 44
>   Date: 2018-09-17
> 
> Abstract:
>   This specification defines a new EAP method, EAP-AKA', a small
>   revision of the EAP-AKA method.  The change is a new key derivation
>   function that binds the keys derived within the method to the name of
>   the access network.  The new key derivation mechanism has been
>   defined in the 3rd Generation Partnership Project (3GPP).  This
>   specification allows its use in EAP in an interoperable manner.  In
>   addition, EAP-AKA' employs SHA-256 instead of SHA-1.
> 
>   This specification also updates RFC 4187 EAP-AKA to prevent bidding
>   down attacks from EAP-AKA'.
> 
>   This version of the EAP-AKA' specification provides updates to
>   specify the protocol behaviour for 5G deployments as well.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-emu-rfc5448bis/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-emu-rfc5448bis-02
> https://datatracker.ietf.org/doc/html/draft-ietf-emu-rfc5448bis-02
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-rfc5448bis-02
> 
> 
> 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] Suggestion: draft-arkko-eap-aka-kdf-09

[Russ Housley]

I like test vectors that have two independent implementations.  That 
seems to be the case here, so please proceed.


Russ

At 02:07 AM 1/5/2009, yogendra pal wrote:

Russ, Could you let us know whether we can include the these test
vectors or not ?

Thanks
Yogendra

On Sun, Dec 21, 2008 at 1:57 AM, Jari Arkko  wrote:
> Wonderful. Are we ready to include these values in an appendix of the RFC?
> Russ, would you mind if we do that?
>
> Jari
>
> Jouni Malinen wrote:
>>
>> On Sat, Dec 20, 2008 at 06:05:41PM +0530, yogendra pal wrote:
>>
>>
>>>
>>> I hope Jouni can test the case-2, case-3, case-4 with his
>>> implementation for further verification.
>>>
>>
>> I can confirm that I get the same key derivation results (IK', CK',
>> K_encr, K_aut, K_re, MSK, EMSK) for these cases.
>>
>>
>
>


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