Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03

2021-07-05 Thread Eliot Lear

Is this something we should do here or in IOTOPS?

I think it would be cool to develop at least something of a requirements 
doc.  And there are some tools out there, even at the EAP level.  But 
They don't all fit together well.


Eliot

On 05.07.21 16:20, Carolin Baumgartner wrote:



On 7/3/21 1:57 PM, Alan DeKok wrote:

On Jul 3, 2021, at 7:47 AM, Eliot Lear  wrote:
I don't think Tim could be blamed for holding the view that there is 
a separation between specifications and how they are used. There's 
good and bad to the practice.  The good is that the spec can be used 
in ways that the creators didn't intend, and thus perahsp there are 
fewer unnecessary constraints.


On the other hand, not having a theory of operation section, as we 
do have in a good number of our specs, leads to people really not 
understanding when they are applicable, and perhaps more 
importantly, when they are not.
   People don't even understand how to use the specs as intended. 
We're essentially telling people "EAP methods are applicable in these 
situations, but good luck actually trying to get them deployed, 
you're on your own".
I agree and out of experience everything that leaves just a little bit 
room of interpretation ("you can do it this way or that way") ends up 
in misinterpretions or gaps and causes good ideas to fail.


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





OpenPGP_signature
Description: OpenPGP digital signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03

2021-07-03 Thread Eliot Lear

Hi Alan,

I don't think Tim could be blamed for holding the view that there is a 
separation between specifications and how they are used. There's good 
and bad to the practice.  The good is that the spec can be used in ways 
that the creators didn't intend, and thus perahsp there are fewer 
unnecessary constraints.


On the other hand, not having a theory of operation section, as we do 
have in a good number of our specs, leads to people really not 
understanding when they are applicable, and perhaps more importantly, 
when they are not.


All of this having been said, perhaps the best way to go forward is to 
have a requirements discussion in terms of the sorts of operations we 
would like to see as part of the authentication process – as opposed to 
elsewhere.


I see tremendous opportunity here, to be honest.  But it's a lot of work.

Eliot

On 03.07.21 13:35, Alan DeKok wrote:


   We have specs with Security Considerations, and implementation guidelines.  
They're a lot more than just what bits go on the wire.

   In general, a BCP is too late in the process.  Vendors have already implemented the 
base spec, so what's "current" is a random grab-bag of stuff decided on by 
product managers, or by junior engineers.

   I've seen many, many, sites unable to deploy the security they want, due to 
a wide range of limitations in products.  IMHO, these are security issues, and 
should be treated as such in the base specification.  There should be clear 
guidance given on a wide range of issues, such as security, implementation, UI, 
workflow, etc.

   Not having those guidelines is a large source of income for me.  But it is 
endlessly frustrating for everyone involved.  I would prefer to help people 
build useful systems, instead of having them pay me to paper over issues in 
multiple products.

   Alan DeKok.

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





OpenPGP_signature
Description: OpenPGP digital signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03

2021-07-01 Thread Eliot Lear

Hi Alan,

On 01.07.21 15:23, Alan DeKok wrote:

   TEAP is one solution, but I don't think everyone is going to move to TEAP 
overnight.  It would be nice to have solutions for existing (and deployed) EAP 
methods.


Perhaps I lost the plot, but what do you propose?

Eliot




OpenPGP_signature
Description: OpenPGP digital signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03

2021-06-30 Thread Eliot Lear

Hi Alan

Slight segue..

On 30.06.21 15:38, Alan DeKok wrote:

If the answer is "use TPM", then that doesn't meet peoples existing needs.  It 
will also take many years for it to become standardized, much less ubiquitous.  As an 
example, here's an EAP / TPM paper from 2010:

https://www.semanticscholar.org/paper/EAP-TPM-%3A-A-New-Authentication-Protocol-for-IEEE-.-Latze/6d755cf4d1ac1da25c8d02a2e5cba56212149d69



I think we have to be a bit careful about using the term "TPM". What we 
care about are trust anchors, credentials, and operations on those.  
Those objects might be stored in TPMs, but it seems to me that the 
protocol does not need to be aware of that.


If we can be crisper on both the operations and the objects, I think 
we'll do better.  Some of that is on us with a TEAP update, but I think 
there's also a discussion to be had about that.


It's the T part of TEAP that is emphasized in the current work. The 
operations and objects beyond that are underdeveloped.  That has to be a 
lot cleaner as we move forward.


Eliot




OpenPGP_signature
Description: OpenPGP digital signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


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

2021-05-17 Thread Eliot Lear
Let this be the biggest argument on this list ;-)

> On 17 May 2021, at 14:44, Alan DeKok  wrote:
> 
> 
>  This is just a personal preference, but "MUST NOT" is clearer to me than 
> SHALL NOT.  It's also more used, IIRC.



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


Re: [Emu] Issue 47 Certificate identity checks

2021-04-12 Thread Eliot Lear


> On 12 Apr 2021, at 18:25, Joseph Salowey  > wrote:
> 
>> 
>>  I would agure there that the federation should have it's own CA.
> 
> That’s what I’m thinking.  But I could imagine hardcoded devices that make 
> use of it.  That’s all.
> 
> 
> [Joe] Relying on a burned in certificate this way seems like a really bad 
> idea.  What happens when that certificate expires?
> 

Separate the cert from the cert selection.  Don’t burn the cert in, but imagine 
a device that communicates out of the box with a federation service.  This is 
already done at higher layers.

Eliot


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


Re: [Emu] Issue 47 Certificate identity checks

2021-04-12 Thread Eliot Lear


> On 12 Apr 2021, at 19:54, Alan DeKok  wrote:
> 
> On Apr 12, 2021, at 12:22 PM, Joseph Salowey  wrote:
>> [Joe]  without some sort of name matching using certs from a public CA is 
>> unwise.
> 
>  The only other alternative is to "pin" the server cert.  Many systems 
> support this.  Perhaps mentioning [Trust On] First Use (TOFU) would help here.
> 

That won’t work for headless wireless.

Yes, we have kicked that hornet’s nest.  I hope everyone is wearing appropriate 
netting.

Eliot



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


Re: [Emu] Issue 47 Certificate identity checks

2021-04-12 Thread Eliot Lear
Hi Alan,

> On 12 Apr 2021, at 14:52, Alan DeKok  wrote:
> 
>>> 
>>> EAP TLS peer implementations MUST allow for configuration of a unique trust 
>>> root to validate the server's certificate.
>> 
>> This statement seems independent of the previous one, and may be overly 
>> broad.  Let me give you an example: a device may be designed only to operate 
>> as part of a federation.
> 
>  I would agure there that the federation should have it's own CA.

That’s what I’m thinking.  But I could imagine hardcoded devices that make use 
of it.  That’s all.

Eliot


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


Re: [Emu] Issue 47 Certificate identity checks

2021-04-12 Thread Eliot Lear
Hi Joe,

I’m okay with most of this text except for as follows:

> 2. CAs MAY issue certs to EAP Servers that specify the id-kp-eapOverLAN EKU 
> specified in RFC 3770.

The above sentence is unnecessary.  Of COURSE CAs can issue certs with that EKU 
or any other.  What I think you mean is this:

CAs issuing certificates intended for use by EAP servers SHOULD specify the 
id-kp-eapOverLAN EKU specified in RFC 3770.

[I am even tempted to say MUST, but I don’t think we ca go that far.]

[…]


>  3. If the above options are not available then separate trust roots need to 
> be used to issue certificates for EAP-TLS server and for TLS servers.

I don’t think this is sufficient.  Rather, I would discuss the logic behind it. 
 In particular, I would state quite clearly something along the following lines:

“EAP peers need to have some basis to decide which networks are authorized.  A 
key signal for this purpose is the validation of the server certificate.  To 
prevent use of the wrong server, the peer SHOULD have some means to select and 
update appropriate trust anchors.  How this happens is beyond the scope of this 
memo."


> EAP TLS peer implementations MUST allow for configuration of a unique trust 
> root to validate the server's certificate.

This statement seems independent of the previous one, and may be overly broad.  
Let me give you an example: a device may be designed only to operate as part of 
a federation.

Eliot


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


Re: [Emu] Consensus call for result indicators in EAP-TLS 1.3

2021-02-19 Thread Eliot Lear


> On 9 Feb 2021, at 09:53, John Mattsson 
>  wrote:
> 
> Michael Richardson wrote:
>> is this really 3.5 round trips -> 4.5 round trips, or is it really more like 
>> that we are >going from perhaps 5.5 round trips to 6.5 round trips (for 
>> example).
> 
> Another question is if EAP-Success should even be counted. A protected 
> success indication would make EAP-Success a dummy message. It has to be sent 
> according to EAP, but would not really be used….

Except to the authenticator, right?

Eliot





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


Re: [Emu] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

2020-11-28 Thread Eliot Lear
Hi there IESG

I support the intent of this document, and I think the approach to update the 
various documents listed is the right one.

Because of the breadth of documents updated, I wonder if at least some 
implementation guidance is warranted, in order to assist developers and even 
perhaps administrators.  Perhaps in some cases these are compile-time or even 
run time options.  I’d suggest guidance for common libraries, such as Microsoft 
.NET, OpenSSL, GNUTLS, and WolfSSL. Better to give that guidance to get people 
to TLS 1.3 rather than 1.2, of course.  Even informational references would be 
fine, as assuredly some of this guidance exists.

Thanks,

Eliot




> On 9 Nov 2020, at 23:26, The IESG  wrote:
> 
> 
> The IESG has received a request from the Transport Layer Security WG (tls) to
> consider the following document: - 'Deprecating TLSv1.0 and TLSv1.1'
>   as Best Current Practice
> 
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> last-c...@ietf.org mailing lists by 2020-11-30. Exceptionally, comments may
> be sent to i...@ietf.org instead. In either case, please retain the beginning
> of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>   This document, if approved, formally deprecates Transport Layer
>   Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346).
>   Accordingly, those documents (will be moved|have been moved) to
>   Historic status.  These versions lack support for current and
>   recommended cryptographic algorithms and mechanisms, and various
>   government and industry profiles of applications using TLS now
>   mandate avoiding these old TLS versions.  TLSv1.2 has been the
>   recommended version for IETF protocols since 2008, providing
>   sufficient time to transition away from older versions.  Removing
>   support for older versions from implementations reduces the attack
>   surface, reduces opportunity for misconfiguration, and streamlines
>   library and product maintenance.
> 
>   This document also deprecates Datagram TLS (DTLS) version 1.0
>   (RFC6347), but not DTLS version 1.2, and there is no DTLS version
>   1.1.
> 
>   This document updates many RFCs that normatively refer to TLSv1.0 or
>   TLSv1.1 as described herein.  This document also updates the best
>   practices for TLS usage in RFC 7525 and hence is part of BCP195.
> 
> 
> 
> 
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/
> 
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 
> The document contains these normative downward references.
> See RFC 3967 for additional information:
>rfc5024: ODETTE File Transfer Protocol 2.0 (Informational - Independent 
> Submission Editor stream)
>rfc5024: ODETTE File Transfer Protocol 2.0 (Informational - Independent 
> Submission Editor stream)
>rfc5023: The Atom Publishing Protocol (Proposed Standard - IETF stream)
>rfc5019: The Lightweight Online Certificate Status Protocol (OCSP) Profile 
> for High-Volume Environments (Proposed Standard - IETF stream)
>rfc5019: The Lightweight Online Certificate Status Protocol (OCSP) Profile 
> for High-Volume Environments (Proposed Standard - IETF stream)
>rfc5018: Connection Establishment in the Binary Floor Control Protocol 
> (BFCP) (Proposed Standard - IETF stream)
>rfc4992: XML Pipelining with Chunks for the Internet Registry Information 
> Service (Proposed Standard - IETF stream)
>rfc4992: XML Pipelining with Chunks for the Internet Registry Information 
> Service (Proposed Standard - IETF stream)
>rfc4976: Relay Extensions for the Message Sessions Relay Protocol (MSRP) 
> (Proposed Standard - IETF stream)
>rfc4975: The Message Session Relay Protocol (MSRP) (Proposed Standard - 
> IETF stream)
>rfc4975: The Message Session Relay Protocol (MSRP) (Proposed Standard - 
> IETF stream)
>rfc4964: The P-Answer-State Header Extension to the Session Initiation 
> Protocol for the Open Mobile Alliance Push to Talk over Cellular 
> (Informational - IETF stream)
>rfc4964: The P-Answer-State Header Extension to the Session Initiation 
> Protocol for the Open Mobile Alliance Push to Talk over Cellular 
> (Informational - IETF stream)
>rfc4851: The Flexible Authentication via Secure Tunneling Extensible 
> Authentication Protocol Method (EAP-FAST) (Informational - IETF stream)
>rfc4851: The Flexible Authentication via Secure Tunneling Extensible 
> Authentication Protocol Method (EAP-FAST) (Informational - IETF stream)
>rfc4823: FTP Transport for Secure Peer-to-Peer Business Data Interchange 
> over the Internet (Informational - IETF stream)
>rfc4823: FTP Transport for Secure Peer-to-Peer Business Data Interchange 
> over the Internet (Informational - IETF stream)
>rfc4791: Calendaring Extensions to WebDAV (CalDAV) (Proposed Standard - 
> IETF stream)
>rfc4791: 

Re: [Emu] Proposed TEAP Errata Resolution Summary

2020-11-02 Thread Eliot Lear
Joe,

Thanks for all your work on this.  On the “discuss”es, would you mind giving 
some time for them at the meeting?

Thanks,

Eliot

> On 1 Nov 2020, at 23:33, Joseph Salowey  wrote:
> 
> Below is the summary of the TEAP errata resolutions.  The text that will be 
> sent to the AD is in the linked emails.  The GitHub PR is provided to make it 
> easier to review the revision in context.  Anything that is marked for final 
> review will be sent to the AD next week if there are no objections raised.  
> Ones marked discuss should have some discuss to verify the resolution (5765, 
> 5767, 5775, 5844). 
> 
> Thanks,
> 
> Joe
> 
> Errata ID: 5127
> Status: Verified - Final Review
> Type: Technical
> Mail: https://mailarchive.ietf.org/arch/msg/emu/R5uypu9Kna8vTpyV5BlIXDm-Mdk/ 
> 
> PR: https://github.com/emu-wg/teap-errata/pull/2 
> 
> 
> Errata ID: 5128
> Status: Verified - Final Review
> Type: Technical
> Mail: https://mailarchive.ietf.org/arch/msg/emu/fYBuPgWa7xiH7JmoHfP5yrU7HV0/ 
> 
> PR: https://github.com/emu-wg/teap-errata/pull/4 
> 
> 
> Errata ID: 5765
> Status: Verified - Discuss
> Type: Technical
> Mail: https://mailarchive.ietf.org/arch/msg/emu/Ga8evJZzLG8lCML-kkxV6G_JS0E/ 
> 
> Mail: https://mailarchive.ietf.org/arch/msg/emu/676S5r51SkmxtzLZH9FqNFB6aOQ/ 
> 
> PR: https://github.com/emu-wg/teap-errata/pull/18 
> 
> 
> Errata ID: 5767
> Status: Hold For Document Update - Discuss
> Type: Technical
> Mail: https://mailarchive.ietf.org/arch/msg/emu/QIOT258m2LNCnmCGKgpjCYVFLWE/ 
> 
> 
> Errata ID: 5768
> Status: Verified - Final Review
> Type: Technical
> Mail: https://mailarchive.ietf.org/arch/msg/emu/r-nAObtWmZ6tt1Dd0fmc7cHEBNs/ 
> 
> PR for section 5 is: https://github.com/emu-wg/teap-errata/pull/8 
> 
> PR for section 4 is: https://github.com/emu-wg/teap-errata/pull/7 
> 
> 
> Errata ID: 5770
> Status: Verified - Final Review
> Type: Technical
> Mail: https://mailarchive.ietf.org/arch/msg/emu/mXzpSGEn86Zx_fa4f1uULYMhMoM/ 
> 
> PR for section 5: https://github.com/emu-wg/teap-errata/pull/13 
> 
> 
> Errata ID: 5775
> Status: Verified - Discuss
> Type: Technical
> Mail: https://mailarchive.ietf.org/arch/msg/emu/u96Oxo2oFnsntJUFRFgiPENDcYQ/ 
> 
> Section 4 PR - https://github.com/emu-wg/teap-errata/pull/12 
> 
> Section 5 PR - https://github.com/emu-wg/teap-errata/pull/11 
> 
> 
> Errata ID: 5844
> Status: Verified - Discuss
> Type: Technical
> Mail: https://mailarchive.ietf.org/arch/msg/emu/1ceqDbGP3mozqbzZ40xo48zFiDo/ 
> 
> 
> PR Section 5: https://github.com/emu-wg/teap-errata/pull/19 
> 
> PR section 3: https://github.com/emu-wg/teap-errata/pull/22 
> 
> PR section 3: https://github.com/emu-wg/teap-errata/pull/23 
> 
> PR section 4: https://github.com/emu-wg/teap-errata/pull/24 
> 
> 
> Errata ID: 5845
> Status: Verified - Final review
> Type: Technical Mail: 
> https://mailarchive.ietf.org/arch/msg/emu/Ucy2tg7UyZFry99k3oGOY_aS6mk 
> 
> The PR for section 3: https://github.com/emu-wg/teap-errata/pull/20 
> 
> 
> Errata ID: 6157
> Status: Verified - Final Review
> Type: Technical
> Mail: https://mailarchive.ietf.org/arch/msg/emu/t1HhhUL0QFgBmgAFYRMRkKXWXaA/ 
> 
> PR:https://github.com/emu-wg/teap-errata/pull/21 
> 
> ___
> 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] Making Security Practical ... was RE: Moving towards less security in 2020 - OCSP

2020-11-02 Thread Eliot Lear
Hi Hannes,

My concern is not about implementation.  At least for the sake of discussion, 
let us assume that we can get the code to where it needs to be.  The question 
is more about what happens when an OCSP server is unavailable, either to the 
client or to the server (stapled or otherwise).  What is expected of server 
behavior in such a case, and what is expected of client behavior?

Consider the scenario when you have the CA sitting off somewhere in the 
distance, and a power failure or other service interruption has occurred.  
Should the client refuse to come up because stapling didn’t happen?  Should old 
stapling information be retained, and what does that mean in the context of the 
nonce extension?  I had thought we said that this risk is mitigated by the 
choice of the deployment to include the OCSP extension information in the cert- 
or not.  At that point the deployment can make the decision.

Are we now saying otherwise?

Eliot

> On 2 Nov 2020, at 09:08, 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 
> 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 
> 
>    [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 

Re: [Emu] Consensus Call on OCSP usage in draft-ietf-emu-eap-tls13-11

2020-10-29 Thread Eliot Lear
Hi Max

> On 29 Oct 2020, at 18:30, Max Pala  <mailto:madw...@openca.org>> wrote:
> 
> Hi Eliot, all,
>  
> In our industry we solved this issue by requiring OCSP stapling if and only 
> if the certificate being validated carries the OCSP URI in the certificate. 

Perfectly reasonable.

>  
> This allows us to live in a mixed environment where support for OCSP might 
> have been introduced later on and allows the CA to explicitly support OCSP 
> for the certificate by including the URL in it.

Yep.

>  
> If the “ecosystem” policy allows it – you might suggest that if OCSP 
> responses are not not provided but the URL where to get OCSP responses is 
> known to the device (or it is in the certificate), the device/entity can 
> continue with the authentication but it should not enable any device/entity 
> functionality before successfully executing (and validating) the OCSP 
> protocol first (and disconnect if not reachable/invalid/revoked).
>  
> Just my 2 cents.
>  

Worth more.

Eliot

> Cheers,
> Max
>  
> From: Emu mailto:emu-boun...@ietf.org>> on behalf of 
> Eliot Lear  <mailto:lear=40cisco@dmarc.ietf.org>>
> Date: Thursday, October 29, 2020 at 10:53 AM
> To: Joseph Salowey mailto:j...@salowey.net>>
> Cc: EMU WG mailto:emu@ietf.org>>
> Subject: Re: [Emu] Consensus Call on OCSP usage in draft-ietf-emu-eap-tls13-11
>  
> Hi Joe,
>  
> My suggestion is that we add some discussion about what to do in the case of 
> no connectivity to the CA.  This will be a not-uncommon occurrence, IMHO, in 
> industrial use cases.
>  
> Eliot
> 
> 
>> On 29 Oct 2020, at 17:23, Joseph Salowey > <mailto:j...@salowey.net>> wrote:
>>  
>> An issue was raised in a review of  draft-ietf-emu-eap-tls13-11 on the 
>> mandatory requirement for OCSP stapling [1].  The document makes the use of 
>> OCSP mandatory in section 5.4 [2]. Several folks have pointed out that this 
>> may not be feasible in all deployments.  This is a quick consensus call for 
>> this issue.   Please indicate which option below you support and why.  
>> Please respond by November 5, 2020. 
>> 
>> 1. Keep the text as is with OCSP mandatory for all implementations
>> 
>> 2. Require Servers to Implement and Recommended to Use OCSP with text 
>> similar to the following:
>> 
>> “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.“
>>  
>> Thanks,
>>  
>> Joe
>>  
>> [1] https://mailarchive.ietf.org/arch/msg/emu/0DnfUWPqvKX0_Wo8s-ZypergMHI/ 
>> <https://mailarchive.ietf.org/arch/msg/emu/0DnfUWPqvKX0_Wo8s-ZypergMHI/>
>> [2] https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-11#section-5.4 
>> <https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-11#section-5.4>
>> ___
>> 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 
> <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] Consensus Call on OCSP usage in draft-ietf-emu-eap-tls13-11

2020-10-29 Thread Eliot Lear
Hi Joe,

My suggestion is that we add some discussion about what to do in the case of no 
connectivity to the CA.  This will be a not-uncommon occurrence, IMHO, in 
industrial use cases.

Eliot

> On 29 Oct 2020, at 17:23, Joseph Salowey  > wrote:
> 
> An issue was raised in a review of  draft-ietf-emu-eap-tls13-11 on the 
> mandatory requirement for OCSP stapling [1].  The document makes the use of 
> OCSP mandatory in section 5.4 [2]. Several folks have pointed out that this 
> may not be feasible in all deployments.  This is a quick consensus call for 
> this issue.   Please indicate which option below you support and why.  Please 
> respond by November 5, 2020. 
> 
> 1. Keep the text as is with OCSP mandatory for all implementations
> 
> 2. Require Servers to Implement and Recommended to Use OCSP with text similar 
> to the following:
> 
> “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.“
> 
> Thanks,
> 
> Joe
> 
> [1] https://mailarchive.ietf.org/arch/msg/emu/0DnfUWPqvKX0_Wo8s-ZypergMHI/ 
> 
> [2] https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-11#section-5.4 
> ___
> 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] Proposed Resolution to TEAP Errata 5770

2020-10-27 Thread Eliot Lear
Hi,

> 
> [Joe] Yes I think it is fine to say EAP authentication method.   I have been 
> convinced that the spec requires crypto-binding with the basic password 
> authentication.   I'll need to add this in. 
>  

Keep in mind that there might not even be basic auth.  One case is that one 
just uses the OUTER auth, does some PKCS ops or extensions and then wants to 
conclude.  No inner in this case.  Which erratum is that covered by?

Eliot

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


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

2020-10-26 Thread Eliot Lear
[Trimming]

> On 26 Oct 2020, at 16:26, Michael Richardson  wrote:
> 
> 
>>> While this degenerate case of Authentication Server + OCSP Signer on the 
>>> same
>>> machine is kinda dumb from a overall security point of view, it's still
>>> better than raw public keys.
> 
>> Yes.  Let’s think about who OCSP is protecting in this case.  It’s
>> protecting the client from the Authentication Server, in theory.
> 
> Yes, from compromises of the Authentication Server via loss of control of 
> private key.

And so the authentication server and OCSP signer being on the same device 
itself represents both a scaling problem and a security problem.  Just imagine 
having to manage all of that.

> 
>>> If the OCSP signer is moved to some TPM then
>>> there is a win.  Not all TPMs can provide the performance required to handle
>>> the server certificate, but resigning an OCSP Staple once every ten minutes
>>> or something shouldn't be a problem.
> 
>> If this is the case, then a public key could be moved into the the TPM just 
>> as easily.
> 
> If the TPM can accomodate thousands of signatures per minute, which fTPMs
> probably can accomodate (same CPU, just different context), then sure.
> Many older, i2c interfaced physical-TPMs do not accomodate that rate.

I’ll admit to only secondary interest in performance.  That is- one can 
optimize around this.  But managing naked public keys of servers themselves is 
not scalable from a key management perspective.


>>> The third is, I think, that the EAP server runs an entirely self-contained
>>> private CA.  The OCSP responder is now clearly an integral part of the local
>>> system.
> 
>> Again, what threat are we protecting against?
> 
> The self-contained CA might have a passphrase, so there is some accomodation
> updating the signing key for new algorithms, etc.  while the trust anchor
> which is distributed is appropriate pessimistic.
> 


I guess the issue I’m having is that stapling is requiring more connectivity 
than may be present, and making it a MUST means that we are making very VERY 
broad deployment assumptions.  It is WAY too early for that.

Eliot


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


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

2020-10-26 Thread Eliot Lear


> On 26 Oct 2020, at 15:19, Michael Richardson  wrote:
> 
> Signed PGP part
> 
> Eliot Lear  wrote:
>>> The EAP server is expected to frequently request a OCSP response from
>>> the OCSP responder (a server typically run by the certificate
>>> issuer). The OCSP response is then added to the Servers Certificate
>>> message as long as it is valid. Before the OCSP response is close to
>>> expiring, the EAP server requests a new OCSP response from the OCSP
>>> responder.
> 
>> Right.  What this is saying is that a local deployment MUST run an OCSP
>> responder.  If that OCSP responder is unavailable, then what?  Now
>> imagine we are discussing critical infrastructure where the responder
>> is not in the same room, and there are network connectivity problems.
>> The device joining the network needs local access and that is it.  Does
>> that mean it should not use EAP-TLS?  Or are we saying that they MUST
>> use naked public keys?
> 
> No.  There are several steps before we get to raw public keys.
> 
> The first is that the duration of the Staples could be lengthed to accomodate
> anticipated down time for the (now) critical OCSP responder.
> A second part is that perhaps staples could be provisioned in advance for the
> server to cover for planned maintenance periods.  I don't imagine this is in
> any protocol, but could be added.

But to what end?  We don’t even know if these devices can reasonably deal with 
any secure notion of time.  Even checking cert expiry is a bit questionable in 
some cases, especially if the cert has been seen before, and the device is of 
someone critical value.  And it’s not clear what the value is with a lengthy 
expiry.


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

> While this degenerate case of Authentication Server + OCSP Signer on the same
> machine is kinda dumb from a overall security point of view, it's still
> better than raw public keys.

Yes.  Let’s think about who OCSP is protecting in this case.  It’s protecting 
the client from the Authentication Server, in theory.


> If the OCSP signer is moved to some TPM then
> there is a win.  Not all TPMs can provide the performance required to handle
> the server certificate, but resigning an OCSP Staple once every ten minutes
> or something shouldn't be a problem.

If this is the case, then a public key could be moved into the the TPM just as 
easily.

> 
> The third is, I think, that the EAP server runs an entirely self-contained
> private CA.  The OCSP responder is now clearly an integral part of the local
> system.

Again, what threat are we protecting against?

Eliot


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


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

2020-10-26 Thread Eliot Lear
Thanks, John.  Please see below:

> On 26 Oct 2020, at 13:58, John Mattsson 
>  wrote:
> 
> Hi Eliot,
> 
> The EAP server is expected to frequently request a OCSP response from the 
> OCSP responder (a server typically run by the certificate issuer). The OCSP 
> response is then added to the Servers Certificate message as long as it is 
> valid. Before the OCSP response is close to expiring, the EAP server requests 
> a new OCSP response from the OCSP responder.
> 

Right.  What this is saying is that a local deployment MUST run an OCSP 
responder.  If that OCSP responder is unavailable, then what?  Now imagine we 
are discussing critical infrastructure where the responder is not in the same 
room, and there are network connectivity problems.  The device joining the 
network needs local access and that is it.  Does that mean it should not use 
EAP-TLS?  Or are we saying that they MUST use naked public keys?

> I assume you mean the client is offline? If use cases where none of the 
> entities can contact the OCSP responder is in scope, OCSP stapling does not 
> work.

Right.  So then what?  Fail?

For many devices the manufacturers will be unable to predict whether a device 
will or will not have direct access to anything.  It specific to deployment 
circumstances.  Also, running an OCSP server is something that will be very new 
for many enterprises.

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


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

2020-10-26 Thread Eliot Lear
Hi John,

My question is one of pragmatics.  In an offline industrial environment, what 
is expected of the server to accomplish the stapling?  Especially if the 
request is nonced.

Eliot

> On 26 Oct 2020, at 13:08, John Mattsson 
>  wrote:
> 
> Hi,
> 
> When this was discussed in the group, it was decided to not only mandate 
> revocation checking, but to also mandate OCSP stapling as is it often the 
> only viable solution to let an offline peer check the revocation status of 
> the server. We had a discussion on must-staple, and the decision was to 
> mandate stapling in the draft instead of waiting for support of the X.509 
> must-staple extension. OCSP and OCSP stapling are quite well supported 
> already and should be even more well-supported in a few years:
> 
> 1. Basically all TLS implementations support OSCP, and a majority support 
> OSCP stapling (Certificate Status Request). Mbed is an exception rather than 
> the rule.
> 
> https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations
> 
> 2. All browsers (desktop and mobile) support OCSP stapling.
> 
> https://blog.apnic.net/2019/01/15/is-the-web-ready-for-ocsp-must-staple/#:~:text=OCSP%20Must%2DStaple%20is%20a,Certificate%20Status%20Protocol%20(OCSP).
> 
> 3. NIST SP 800-52 Rev 2 mandates that the server shall support use of the 
> Certificate Status Request extension (i.e. OCSP stapling).
> 
> 
> - I do not think there is any wiggle room at all in the current version of 
> the draft:
> 
>  "When EAP-TLS is used with TLS 1.3, the peer and server MUST use Certificate 
> Status Requests [RFC6066]
>for the server's certificate chain"
> 
>  Note that in the current draft it is unspecified how the server checks the 
> revocation status of the client's certificate:
> 
>  "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."
> 
> 
> - The X.509 must-staple extension 
> (https://tools.ietf.org/html/draft-hallambaker-muststaple-00) is not relevant 
> for server certificates in the current EAP-TLS 1.3 draft as stapling is 
> already a must. OSCP stapling is not very useful for client certs. I do not 
> know if the X.509 must-staple extension is well supported or not. It could 
> become relevant for server certs if the requirements are softened.
> 
> 
> - My view is that OSCP stapling is a very good fit for EAP in particular and 
> is well-supported enough to be mandated. Mandating stapling for EAP-TLS 1.3 
> from the start avoids having to rely on the X.509 must-staple extension. Any 
> implementation not supporting OCSP stapling should implement it together with 
> TLS 1.3. I do not think the requirent should be softened, but if it is, my 
> view is that is should be softened as little as possible.
> 
> 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] draft-ietf-emu-eap-tls13-11: OCSP Stapling

2020-10-23 Thread Eliot Lear
So I’m a client and include a certificate status request.  The EAP server isn’t 
talking to the CA at the moment.  Does a nonce have to be used?  If so… #fail.  
If not, what prevents a replay?  And if the answer is nothing, what is the 
threat model we are addressing?
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


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

2020-10-22 Thread Eliot Lear
+1.  How does anyone even do OCSP without having first gotten onto the network?

Eliot

> On 21 Oct 2020, at 11:02, Hannes Tschofenig  wrote:
> 
> Hi all, 
>  
> this draft mandates OCSCP stapling (for use with TLS 1.3 in EAP-TLS) and I 
> believe this is a problem for implementations. This extra burden is IMHO 
> unjustified. For the type of deployments where EAP is used there is no need 
> for a mandatory certificate revocation checking with OCSP.
>  
> Having it optional, like the use of many other TLS extensions, is fine for 
> me. FWIW even TLS 1.3, which is used in a more generic environment, does not 
> mandate the use of OCSP stapling.
>  
> This requirement will make the problem described in draft-ietf-emu-eaptlscert 
> worse. I am sure the authors are aware of this fact since they are also 
> co-authors of draft-ietf-emu-eaptlscert.
>  
> 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] [Technical Errata Reported] RFC7170 (6157)

2020-05-20 Thread Eliot Lear
Hi Ben,

My apologies for the delay.  You are pointing out a separate issue that might 
need to be opened, but I will do my best to discuss below:

> On 9 May 2020, at 02:20, Benjamin Kaduk  wrote:
> 
> On Mon, May 04, 2020 at 03:20:00AM -0700, RFC Errata System wrote:
>> The following errata report has been submitted for RFC7170,
>> "Tunnel Extensible Authentication Protocol (TEAP) Version 1".
>> 
>> --
>> You may review the report below and at:
>> https://www.rfc-editor.org/errata/eid6157
>> 
>> ------
>> Type: Technical
>> Reported by: Eliot Lear 
>> 
>> Section: 4.2.9
>> 
>> Original Text
>> -
>>  Status
>> 
>>  The Status field is one octet.  This indicates the result if the
>>  server does not process the action requested by the peer.
>> 
>> Corrected Text
>> --
>>  Status
>> 
>>  The Status field is one octet.  This indicates the result if the
>>  party who receives this TLV does not process the action.
>> 
>> Notes
>> -
>> The status field is carried in the "Request-Action" frame.  As is repeatedly 
>> stated in the chapeau of the section, the frame can be sent either by the 
>> server or the peer.
> 
> This looks like one where I can't pick up on the needed context just from
> the section in question.  The intent of the 'Status' field still seems
> unclear: this text seems to suggest that it's a sort of "fallback" error
> code to use if the request to perform an action is ignored.  But that
> doesn't make much sense if I also look at the text about:
> 
>Two Request-Action TLVs MUST NOT occur in the same TEAP
>   packet if they have the same Status value.  [...]
> 
> Why am I not allowed to have two requests that would get the same treatment
> if the request was ignored?

I can’t answer this question authoritatively because I didn’t write the RFC 
(;-), and in general the language here is hard to parse.  For instance, what 
does it mean for the request-action frame to have a PKCS#10 request in it?  
Does that mean that the receiving peer must either attempt to generate a PKCS#7 
message or return the most fatal of (result(PKCS#7 generation),”Status”)?  That 
doesn’t seem to make sense, because the conversation could continue if Status 
== non-fatal without the server having processed the request.  On the other 
hand, sending a normal PKCS#10 frame seems to have nearly identical semantics.

Eliot

> 
> Thanks for helping me understand,
> 
> Ben

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


[Emu] TEAP Update (was: Re: Working Group Call For adoption of draft-aura-eap-noob-08.txt)

2020-05-04 Thread Eliot Lear
Hi Mohit

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

Oleg has addressed the TEAP errata and it would be very helpful if Joe and 
Jouni could give it a stare.  I also posted one issue relating to the use of 
Request-Action, which may require an additional TLV to correct.  Also, I am 
aware of one additional erratum that I will open shortly that is minor 
(conflicting terms in the Request-Action frame).

If we can collect all of these, then it would be good for the group to decide 
what else needs to be updated.  FWIW, I see a TLS 1.3 update for TEAP as 
raising some questions around the way that restart is incorporated into 7170.  
We could simply rule out restart for 1.3, or do something smarter.  I dunno yet.

Eliot

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

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


Re: [Emu] TEAP Request-Action TLV

2020-04-30 Thread Eliot Lear


> On 30 Apr 2020, at 20:53, Michael Richardson  wrote:
> 
> Signed PGP part
> 
> Eliot Lear  wrote:
>> Here is a circumstance one could easily imagine, and in fact we
>> attempted to address in draft-lear-eap-teap-brski:
> 
>> Client requires a new certificate for some reason or another.  Perhaps
>> its is about to expire, or perhaps the signer has been compromised, or
>> what have you.
> 
> I think that's a really bad example.  I can talk about the reasons, but I
> think it would detract from your query.

Certificate do need to roll, and we should handle that case.  One could use the 
ACME/LE model of just periodically sending a PKCS#10 request after 2/3rds of 
the expiry is past, but that doesn’t help us in the case where the signing cert 
needs to roll.

> Maybe you can give me a different use case?

A different use case might be (later on), “please send me a RATS attestation”.  
The key point is that the EAP server is a good control channel to gate clients 
in a lock step fashion, but the Request-Action TLV doesn’t quite get us there, 
as written, as I see it.

Eliot



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


[Emu] TEAP Request-Action TLV

2020-04-30 Thread Eliot Lear
All:

Here is a circumstance one could easily imagine, and in fact we attempted to 
address in draft-lear-eap-teap-brski:

Client requires a new certificate for some reason or another.  Perhaps its is 
about to expire, or perhaps the signer has been compromised, or what have you.

We were thinking that we could use the Request-Action Frame for this purpose 
with a type of PKCS#10.  But that now seems wrong, as the language in the draft 
states that one appends a Request-Action frame with a full TLV, and not just a 
type,  and further that the other end process the TLV.  In looking at Jouni’s 
code, he is doing precisely that with the PAC TLV.

And so it seems we have three choices:

Create a new TLV that has a length of two that can be used in a REQUEST_ACTION 
frame.
Create a new TLV that is what we thought we meant: here is a list of 
two(ish)-byte types whose TLVs I want you to send to me.
Hard code the ordering of requests so everyone knows what to expect.

Each of these has its own problems. 

The first requires that we create a new EAP TYPE for TLV one end needs the 
other to send, but it’s pretty easy to process. The second requires extra 
processing but requires less standardization.  The last seems to go against the 
EAP model and reduces deployment flexibility.

Thoughts?

Eliot___
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 Eliot Lear
Hi Mohit

> On 24 Apr 2020, at 15:02, Mohit Sethi M 
>  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.

Eliot
___
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-03-24 Thread Eliot Lear


> On 24 Mar 2020, at 10:30, Hannes Tschofenig  wrote:
> 
> Hi Eliot, 
>  
> I consider the enterprise and the university case as a roaming model. From an 
> EAP method point of view there is IMHO little difference between the roaming 
> and the non-roaming case: the EAP exchange always runs between the EAP peer 
> on the device and the EAP server. 
>  
> The IoT case is different because it falls more in the category of  home WiFi 
> usage. This doesn’t really use EAP in my understanding.


For wifi?  The number of IoT devices using wifi is minuscule compared to what I 
believe we will see over time.  And so it is hard to judge.  The onboarding 
mechanisms need to mature a bit more.

Eliot___
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-03-24 Thread Eliot Lear
Hi Hannes

> On 24 Mar 2020, at 10:08, Hannes Tschofenig  wrote:
> 
> Hi Eliot
>  
> You bring up a good point, namely the deployment environment. Are we are 
> talking about an IoT, an enterprise deployment environment or something else? 
> Clearly there will be differences. Reading through the text my impression was 
> that this is about an enterprise (or university) deployment environment. I 
> might, however, be on the wrong track here.

Since we’re talking about EAP, I can think of a few cases:

Classic enterprise/university case, IoT or not.  I was ASSUMING IoT because my 
brain goes to IOT, but I don’t think it has to be so.
There is also a wifi roaming device model, where EAP might be used in various 
service provider or federated environments a’la Eduroam or similar.  Today this 
is NOT a big IoT space, but soon?

The one place this is not a big deal at the moment is in the home, as 
WPA-Personal/PAE is the norm.

One additional question is how big the impact is between wired and wireless.  
Obviously with the former you worry less about interference and drops.

Eliot


>  
> Having the references to where deployment problems with large 
> certificates/certificate chains occur would shine light on this aspect.
>  
> Ciao
> Hannes
>  
> From: Eliot Lear  
> Sent: Tuesday, March 24, 2020 10:02 AM
> To: Hannes Tschofenig 
> Cc: Michael Richardson ; emu@ietf.org
> Subject: Re: [Emu] My review ... was RE: I-D Action: 
> draft-ietf-emu-eaptlscert-02.txt
>  
> Good morning Hannes
> 
> 
>  
> 
> 
> 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.
>  
> Not sure I entirely understand you.  A few places are promoting new roots for 
> manufacturers.  And so the initial chain for a peer might look like 
> CA-Root->CA-Intermediate->Mfg  Root->Mfg Intermediate->Device.  I think it 
> may be possible to remove one of the intermediates, but probably not both.  
> It seems to me that this is an onboarding problem, and the best way to reduce 
> the cert chain size on a day to day basis would be to swap out for an 
> operational cert where the trust anchor is within the enterprise.  That means 
> you get one of those Big Fat transactions and then things settle down, and 
> that transaction may be handled specially anyway.
>  
> One comment I have in the draft relates to this text:
>  
>o  Extensions are necessary to comply with [RFC5280], but the vast
>   majority are optional.  Include only those that are necessary to
>   operate.
>  
> This statement is just a little too general.  It very much depends WHICH 
> certificate we are discussing.  If it is a manufacturer certificate, as long 
> as you can roll to an enterprise cert, then who cares?  If it is an 
> enterprise certificate, then we have to look more closely.
>  
> So for instance, as Hannes mentions, authorization is a big issue.  Some of 
> that can be done outside of the certificate using ACE or similar, but some 
> may need to be present in the cert.  What we would rather not have is people 
> working the SAN to introduce authorization attributes.
>  
> Eliot
> 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


Re: [Emu] My review ... was RE: I-D Action: draft-ietf-emu-eaptlscert-02.txt

2020-03-24 Thread Eliot Lear
Good morning Hannes

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

Not sure I entirely understand you.  A few places are promoting new roots for 
manufacturers.  And so the initial chain for a peer might look like 
CA-Root->CA-Intermediate->Mfg  Root->Mfg Intermediate->Device.  I think it may 
be possible to remove one of the intermediates, but probably not both.  It 
seems to me that this is an onboarding problem, and the best way to reduce the 
cert chain size on a day to day basis would be to swap out for an operational 
cert where the trust anchor is within the enterprise.  That means you get one 
of those Big Fat transactions and then things settle down, and that transaction 
may be handled specially anyway.

One comment I have in the draft relates to this text:

   o  Extensions are necessary to comply with [RFC5280], but the vast
  majority are optional.  Include only those that are necessary to
  operate.

This statement is just a little too general.  It very much depends WHICH 
certificate we are discussing.  If it is a manufacturer certificate, as long as 
you can roll to an enterprise cert, then who cares?  If it is an enterprise 
certificate, then we have to look more closely.

So for instance, as Hannes mentions, authorization is a big issue.  Some of 
that can be done outside of the certificate using ACE or similar, but some may 
need to be present in the cert.  What we would rather not have is people 
working the SAN to introduce authorization attributes.

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


Re: [Emu] draft-lear-eap-teap-brski-05

2020-03-05 Thread Eliot Lear
Hi Hannes,

N.B., this draft is undergoing a fair amount of change.  However, what you are 
discussing wasn’t in scope for those particular changes, not that your points 
shouldn’t lead to changes if needed.

> On 5 Mar 2020, at 18:20, Hannes Tschofenig  wrote:
> 
> Hi all, 
>  
> I have a fundamental question about draft-lear-eap-teap-brski-05.
>  
> The draft makes an assumption about how a TLS client performs authentication 
> of the server side. Because the client is unable to validate the server 
> certificate it delays the authentication till it receives the voucher. The 
> voucher is a fancy name for a certificate chain that allows the client to 
> trace the chain back from the provided certificate to the 
> manufacturer-provided certificate.
>  
> Here is the relevant text: 
> “
> o  Step 2: Device establishes provisional TLS connection to registrar.
>  
> The device establishes an outer TEAP tunnel with the TEAP server and does not 
> validate the server certificate.
> “
>  
> Which part of the text in the TLS spec makes you believe that this is 
> actually supported via the spec (rather than being supported by some 
> implementations*)?
>  

This model is identical to that of draft-ietf-anima-bootstrapping-keyinfra (by 
design).  We are just shifting that capability down a layer.  We’ve tested that 
this is something that can at least be done in OpenSSL on the client side.  I 
won’t make claims about other software.  The specification is a wireline 
RESTful spec.

> Additionally, the TLS stack needs to expose the server certificate via an API 
> so that the application layer can perform this delayed authentication.

Not necessarily.  One merely need only defer the validation step.  What is 
required is that the trust anchor set be configurable.

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


Re: [Emu] Processing of TEWAP erratum 5127

2020-01-28 Thread Eliot Lear


> On 27 Jan 2020, at 05:46, Joseph Salowey  wrote:
> 
> [Joe]  THis is not the only the derivation could be interpreted.  The null 
> after the label and the inclusion of the length are part of RFC 8295 and not 
> the TLS PRF.   To fix this errata I think we should define the TLS-PRF to be 
> P_ with a length parameter for TLS 1.2  and then use the definitions 
> above that explicitly define the 3 inputs.   TLS 1.3 defines the PRF in terms 
> of HKDF extract and expand functions from RFC 5869 so there would need to be 
> some mapping to 1.3 as well.

So… I’m not sure we can deal with 1.3 in an erratum, but we sure as heck 
shouldn’t make it harder later.  I think what you are suggesting matches the 
OpenSSL call as well, which is where much of this derives from.


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


[Emu] RFC 7170 Erratum 5844

2020-01-22 Thread Eliot Lear
If we accept erratum 5845, then it seems only natural that we should accept 
this erratum as well.

> Section 3.3.1 says:
> 
>EAP method messages are carried within EAP-Payload TLVs defined in
>Section 4.2.10.  If more than one method is going to be executed in
>the tunnel, then upon method completion, the server MUST send an
>Intermediate-Result TLV indicating the result.
> 
> It should say:
> 
>EAP method messages are carried within EAP-Payload TLVs defined in
>Section 4.2.10.  Upon method completion, the server MUST send an
>Intermediate-Result TLV indicating the result.
> 
> Notes:
> 
> Description of whether Intermediate-Result TLV is supposed to be used in the 
> case where only a single inner EAP authentication method is used. Section 
> 3.3.1 says "more than one method is going to be executed in the tunnel, then 
> upon method completion, the server MUST send an Intermediate-Result TLV 
> indicating the result", Section 3.3.3 says "The Crypto-Binding TLV and 
> Intermediate-Result TLV MUST be included to perform cryptographic binding 
> after each successful EAP method in a sequence of one or more EAP methods", 
> 4.2.13 says "It MUST be included with the Intermediate-Result TLV to perform 
> cryptographic binding after each successful EAP method in a sequence of EAP 
> methods", Annex C.3 shows an example exchange with a single inner EAP 
> authentication method with use of Intermediate-Result TLV.
> 
> It looks like the majority of the places discussion this topic implies that 
> there is going to be an Intermediate-Result TLV after each inner EAP 
> authentication method and the text in 3.3.1 is the only clear case of 
> conflicting (or well, at least misleading if one were to claim it does not 
> explicitly say MUST NOT for the one inner EAP authentication method case). As 
> such, I'd conclude the Intermediate-Result TLV is indeed going to be 
> exchanged after each EAP authentication method and the proposed text change 
> to 3.3.1 covers that.


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


[Emu] RFC 7170 Erratum 5845

2020-01-22 Thread Eliot Lear
Hi Jouni and all,

Getting back to 7170 errata.

You wrote:
> Section 3.3.1 says:
> 
>EAP method messages are carried within EAP-Payload TLVs defined in
>Section 4.2.10.  If more than one method is going to be executed in
>the tunnel, then upon method completion, the server MUST send an
>Intermediate-Result TLV indicating the result.
> 
> It should say:
> 
>EAP method messages are carried within EAP-Payload TLVs defined in
>Section 4.2.10.  Upon method completion, the server MUST send an
>Intermediate-Result TLV indicating the result.
> 
> Notes:
> 
> Description of whether Intermediate-Result TLV is supposed to be used in the 
> case where only a single inner EAP authentication method is used. Section 
> 3.3.1 says "more than one method is going to be executed in the tunnel, then 
> upon method completion, the server MUST send an Intermediate-Result TLV 
> indicating the result", Section 3.3.3 says "The Crypto-Binding TLV and 
> Intermediate-Result TLV MUST be included to perform cryptographic binding 
> after each successful EAP method in a sequence of one or more EAP methods", 
> 4.2.13 says "It MUST be included with the Intermediate-Result TLV to perform 
> cryptographic binding after each successful EAP method in a sequence of EAP 
> methods", Annex C.3 shows an example exchange with a single inner EAP 
> authentication method with use of Intermediate-Result TLV.
> 
> It looks like the majority of the places discussion this topic implies that 
> there is going to be an Intermediate-Result TLV after each inner EAP 
> authentication method and the text in 3.3.1 is the only clear case of 
> conflicting (or well, at least misleading if one were to claim it does not 
> explicitly say MUST NOT for the one inner EAP authentication method case). As 
> such, I'd conclude the Intermediate-Result TLV is indeed going to be 
> exchanged after each EAP authentication method and the proposed text change 
> to 3.3.1 covers that.
> 
> 

Given the example in Section C.3, odd as it seems, is there any reason not to 
accept this erratum?

Eliot


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


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

2020-01-16 Thread Eliot Lear (elear)


On 8 Jan 2020, at 17:29, Ryan Sleevi 
mailto:ryan-i...@sleevi.com>> wrote:


The CA must revoke if the certificate is misused; that's required by contract.
The CA defines what misuse means.
A number of CAs define misuse as "used for purposes other than TLS web server"
Ergo, obtaining and using certificates with EAP means these certificates are at 
risk of revocation.

Ok not for nothing but this is getting silly.  If a CA actually revoked a cert 
for someone using it for EAP, would they also have to revoke for someone using 
it for SMTP, XMPP, and IMAP?  Has that ever happened?

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


Re: [Emu] BRSKI-TEAP vs regular connection (was Re: EAP questions ...)

2020-01-15 Thread Eliot Lear (elear)


> On 15 Jan 2020, at 16:10, Michael Richardson  wrote:
> 
> 
> Eliot Lear (elear)  wrote:
>>> Owen, do we have a need to recognize that a device needs to perform
>>> onboarding again after a movement?
>>> 
>>> i.e. device A enrolls on network 1, gets an LDevID usable on network
>>> 1, uses that with EAP-FOOBAR.
>>> 
>>> device A then is moved to network 2, it tries to use same LDevID,
>>> receives an error and then recognizes that it needs to perform another
>>> enrollment.
> 
>> I think that is up to the device manufacturer and relates to a number
>> of factors, such as whether the device is mobile, whether it has a
>> reset button, the nature of the device, privacy considerations, whether
>> there are federated capabilities on the device, etc.
> 
> I can see that some of these are important to the device.
> The device may have reasons why it would like to enroll again, but I think
> the question is more about when the network recognizes that it does not need
> to enroll again.
> An example would be a device which was originally enrolled with BRSKI-TEAP,
> but is then provided with roaming credentials (EDU-ROAM).
> 
> How would it know it was on network 2?

Ah.  I misread your note the first time.  The example of 2 is precisely 
eduroam, and this becomes a matter of configuration.  We were talking about 
this at one point, and there is a need to configure a realm as part of all of 
this.  That is something that could be easily be included in TEAP but isn’t 
there today.  It could also be included in DPP in the configuration frame.


> 
>>> What is that error, and is it recognizeable?  Do we need a new error
>>> code to distinguish from "I reject you" from "I reject you but, you
>>> could try enrolling with BRSKI-TEAP"
> 
>> I think that can already be detected in the draft based on the action
>> request frames.
> 
> To clear, it would be doing TEAP (or EAP-TLS) to connect to the network,
> because it is already enrolled.   If there are BRSKI-specific responses
> defined in TEAP, then I'm surprised.

That is what draft-lear-eap-teap-brski is really about.

Eliot

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

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


Re: [Emu] BRSKI-TEAP vs regular connection (was Re: EAP questions ...)

2020-01-15 Thread Eliot Lear (elear)
Hi Michael,


> 
> Owen, do we have a need to recognize that a device needs to perform
> onboarding again after a movement?
> 
> i.e. device A enrolls on network 1, gets an LDevID usable on network 1,
> uses that with EAP-FOOBAR.
> 
> device A then is moved to network 2, it tries to use same LDevID,
> receives an error and then recognizes that it needs to perform another
> enrollment.
> 

I think that is up to the device manufacturer and relates to a number of 
factors, such as whether the device is mobile, whether it has a reset button, 
the nature of the device, privacy considerations, whether there are federated 
capabilities on the device, etc.


> What is that error, and is it recognizeable?  Do we need a new error
> code to distinguish from "I reject you" from "I reject you but, you
> could try enrolling with BRSKI-TEAP"

I think that can already be detected in the draft based on the action request 
frames.

Eliot
> 
> 
> (hoping re-installed laptop works)
> 
> 
> ___
> 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] [lamps] EAP/EMU recommendations for client cert validation logic

2020-01-08 Thread Eliot Lear (elear)
Thanks, Ryan.  After I sent the note I thought about document signing.  Our 
SUDI model at Cisco I view as somewhat different, but may be closer to apt to 
EAP anyway, so worth discussing.

Eliot

On 8 Jan 2020, at 12:26, Ryan Sleevi 
mailto:ryan-i...@sleevi.com>> wrote:



On Wed, Jan 8, 2020 at 5:00 AM Eliot Lear (elear) 
mailto:el...@cisco.com>> wrote:
Hi Ryan,

This topic seems like a good one to just get on the phone and sort through, but 
I have one question:

On 8 Jan 2020, at 09:11, Ryan Sleevi 
mailto:ryan-i...@sleevi.com>> wrote:

However, if using the same set or CAs that popular OSes use for TLS, it does 
mean that these CAs, and their customers, will still be subject to the same 
agility requirements, and limited to the same profile as TLS. Because of this, 
there’s ample reason to split further into the dedicated hierarchy and 
dedicated EKU.

Is there an example of a non-EAP use where splitting into a new hierarchy has 
actually succeeded?

Document signing generally fits there, in that there are a number of CAs that 
only offer document signing/identity proofing without overlapping. As would, 
say, Cisco’s device/firmware signing model or the PKIs in use in the financial 
services/ATM markets.

Relevant to EAP would be the aforementioned Passpoint model, which uses new and 
distinct CAs for that. There are definitely flaws with that (e.g. wanting said 
CAs to work with browsers), but there are parts of it that do work.

There’s no technical reason to require the use of the same roots/same 
hierarchy, and ample and adequate reason to distinguish: both from the 
perspective of a root store maintainer (ensuring certificates comply with 
policies) and as a certificate consumer (minimizing risk of misissuance, ala 
Flame)

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


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

2020-01-08 Thread Eliot Lear (elear)
Hi Ryan,

This topic seems like a good one to just get on the phone and sort through, but 
I have one question:

On 8 Jan 2020, at 09:11, Ryan Sleevi 
mailto:ryan-i...@sleevi.com>> wrote:

However, if using the same set or CAs that popular OSes use for TLS, it does 
mean that these CAs, and their customers, will still be subject to the same 
agility requirements, and limited to the same profile as TLS. Because of this, 
there’s ample reason to split further into the dedicated hierarchy and 
dedicated EKU.

Is there an example of a non-EAP use where splitting into a new hierarchy has 
actually succeeded?

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


Re: [Emu] Processing of TEWAP erratum 5127

2019-11-25 Thread Eliot Lear
Hi Juoni,

Thanks for taking the time.  I suspect this will take a few iterations to get 
the actual text right, as I am drinking water from a fire hose here.  Please 
bear with me.

> On 24 Nov 2019, at 12:31, Jouni Malinen  wrote:
> 
> On Fri, Nov 22, 2019 at 05:21:10PM +0800, Eliot Lear wrote:
>> I have been reviewing this erratum, and I think it is correct, but I have a 
>> question:
>> 
>>> Section 5.2. says:
>>> 
>>> IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org" |
>>> "\0" | 64)
>>> It should say:
>>> 
>>> IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org" |
>>> "\0", 64)
>> 
>> Is that last parameter “seed” or “seed size”?  Confusedly yours.
> 
> It's neither.. The main problem here is in RFC 7170 not defining
> TLS-PRF() properly. All it says is "TLS-PRF is the PRF negotiated as
> part of TLS handshake" while RFC 5246 does not define PRF as a function
> with arguments that would be compatible with even a single instance of
> TLS-PRF() use in RFC 7170..


> And the RFC 7170 uses are inconsistent with
> themselves like this erratum show, but this instance is not the only
> issue: TLS-PRF() is used with two, three, and even four arguments.


Indeed.  So that we’re clear, here they are:

Section 5.2:
 IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org" |
 "\0" | 64)


2 args.

Later, same section:

IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys",
IMSK[j], 60)

4 args.

And then further down:

 MSK  = TLS-PRF(S-IMCK[j], "Session Key Generating Function", 64)
 EMSK = TLS-PRF(S-IMCK[j],
   "Extended Session Key Generating Function", 64)


3 args.


And 5246 says:

PRF(secret, label, seed) = P_(secret, label + seed)

And so I agree with you that nowhere is there a length field for the return 
value in RFC 5246.


> This
> leaves the implementer guessing what exactly these maps to..
> 
>>> RFC5246 The Transport Layer Security (TLS) Protocol Version 1.2
>>> 5. HMAC and the Pseudorandom Function
>>> "TLS's PRF is created by applying P_hash to the secret as:
>>> PRF(secret, label, seed) = P_(secret, label + seed)" 
> 
> So this PRF(secret, label, seed) is what is available and RFC 5246 does
> not define that 64 part in the example above as an argument. That 64 is
> the number of octets of output that is fetched from the PRF.
> 
> In other words, RFC 7170 should have defined TLS-PRF(secret, label,
> seed, output-len-in-octets) as taking output-len-in-octets of octets
> from the output of RFC 5246 PRF(secret, label, seed). With this,
> following fixes would be needed for the users for TLS-PRF() in RFC 7170:
> 
> IMSK:
> This could be one of following (last two having identical outcome):
> TLS-PRF(EMSK, "teapbind...@ietf.org <mailto:teapbind...@ietf.org>", "", 64)
> TLS-PRF(EMSK, "teapbind...@ietf.org <mailto:teapbind...@ietf.org>", "\0", 64)
> TLS-PRF(EMSK, "teapbind...@ietf.org <mailto:teapbind...@ietf.org>", "\0" | 
> 0x00 | 0x40, 64)
> TLS-PRF(EMSK, "teapbind...@ietf.org <mailto:teapbind...@ietf.org>", 0x00 | 
> 0x00 | 0x40, 64)
> 
> However, this TLS-PRF() instance is more strange.. The "Optional data
> parameter is not used in the derivation" part does not make any sense
> since I think "optional data parameter" is a reference to the seed value
> going into PRF.


Could it be that this text refers to RFC 5295:

>  If an inner method supports export of an Extended Master Session Key
>  (EMSK), then the IMSK SHOULD be derived from the EMSK as defined in
>  [RFC5295].  The usage label used is "teapbind...@ietf.org", and the
>  length is 64 octets.  Optional data parameter is not used in the
>  derivation.

USRK = KDF(EMSK, key label | "\0" | optional data | length)

Which perhaps is meant to translate to:

IMSK = KDF(EMSK, “teapbind...@ietf.org <mailto:teapbind...@ietf.org>”, 64)

But again, only when the inner method supports export of the EMSK.  Note the 
text below, by the way:

> USRKs MUST be at least 64 octets in length.



However we interpret the text, it seems that either the argument count is wrong 
or the function is wrong.

> The following description is then clearly indicating
> that "\0" is 0x00 and length (that | 64) is "2-octet unsigned integer in
> network byte order".  That seems to be talking about some binary data
> and the seed is the only place where such byte order and field size
> discussion would apply. I'm actually implementing that last one becaus

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

2019-11-01 Thread Eliot Lear
Hi!

> On 1 Nov 2019, at 13:05, Alan DeKok  wrote:
> 
> On Nov 1, 2019, at 7:53 AM, Eliot Lear  wrote:
>> 
>>> The EAP Identity used in resumption SHOULD be the same EAP Identity as was 
>>> used during the original authentication. This requirement allows EAP 
>>> packets to be routable through an AAA infrastructure to the same 
>>> destination as the original authentication.
>> 
>> Just a question: why SHOULD and not MUST?
> 
>  I'm happy to have it a MUST.
> 
>  I'm prepared for some people to say it can be different, i.e a different AAA 
> server can be used for resumed sessions.  But I don't see that as important.
> 
>>> 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.
>> 
>> Ok, so this sort of impacts the other drafts as well (NOOB and TEAP) for 
>> federated realms (we may both have this wrong).  My presumption here is that 
>> an anonymous NAI is always used, but that the realm is what people would key 
>> off of, and this would always be present.
> 
>  As the EAP Identity, yes.
> 
>> But that presumption doesn’t hold true with the current TEAP update that 
>> we’re working on and that may be problematic.  In any case, this means that 
>> that at least the externalized identity can be used to route, and that 
>> normal TLS semantics can be used for authenticating.  It does require that 
>> tickets be managed on both ends.
> 
>  If the authentications are performed within a constrained system, it's fine 
> to skip using NAIs.  I would suggest that for device bootstrapping you want 
> to ensure that the authentications *aren't* routed outside of the current 
> network.  So they *shouldn't* use a realm.


Ok.  Got it.  I think we have to be quite careful about use of the realm, then, 
and mechanism selection must be done exclusively with EAP-Request/Type.  I 
think it’s okay for federations to bootstrap; although we needn’t define that 
here.

I’ll be updating our draft accordingly.

Eliot


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


Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

2019-11-01 Thread Eliot Lear
Thanks, Alan.  Please see below.

> On 1 Nov 2019, at 12:08, Alan DeKok  wrote:
> 
> On Nov 1, 2019, at 6:15 AM, John Mattsson  wrote:
>> I strongly support working group adoption of draft-dekok-emu-tls-eap-types. 
>> Can we make sure to get this document going, I agree that this is a very 
>> needed draft. I think it should include updates for everything people wants 
>> to use. I do not think draft-ietf-emu-eap-tls13 strictly have to wait for 
>> draft-dekok-emu-tls-eap-types, but draft-dekok-emu-tls-eap-types should be 
>> published shortly after.
> 
>  I will do an update to my document shortly.
> 
>  I also added an issue with the EAP-TLS document on GitHub.  The suggestion 
> is to add text which explains how (and why) the EAP Identity is chosen during 
> resumption:
> 
> ---
> The EAP Identity used in resumption SHOULD be the same EAP Identity as was 
> used during the original authentication. This requirement allows EAP packets 
> to be routable through an AAA infrastructure to the same destination as the 
> original authentication.

Just a question: why SHOULD and not MUST?

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

Ok, so this sort of impacts the other drafts as well (NOOB and TEAP) for 
federated realms (we may both have this wrong).  My presumption here is that an 
anonymous NAI is always used, but that the realm is what people would key off 
of, and this would always be present.  But that presumption doesn’t hold true 
with the current TEAP update that we’re working on and that may be problematic. 
 In any case, this means that that at least the externalized identity can be 
used to route, and that normal TLS semantics can be used for authenticating.  
It does require that tickets be managed on both ends.

My presumption is further that federation doesn’t really occur beyond the TLS 
endpoint, of it it does that is entirely an internal matter for the server.  We 
have a working example of callouts based on the identity of a client for 
purposes of authorization, but for authentication, I would think that would be 
largely a bad idea, due to secret sharing issues (when I say “federation” I 
mean that there should be no trust TLS secret sharing).

Is my understanding correct?

Eliot


> ---
> 
>  Alan DeKok.
> 



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


Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

2019-10-30 Thread Eliot Lear


> On 30 Oct 2019, at 06:22, Joseph Salowey  wrote:
> 
> 
> 
> On Fri, Oct 11, 2019 at 7:34 AM Eliot Lear  <mailto:l...@cisco.com>> wrote:
> 
> 
> > On 11 Oct 2019, at 16:09, Michael Richardson  > <mailto:m...@sandelman.ca>> wrote:
> >
> > So, can wired just be a degenerate version of wifi, where there can be only
> > one "ESSID", and there are no beacons to consider?
> 
> 
> On the whole that has been my thought.  But it is a matter of which mechanism 
> to degenerate to.  Is it TLS-PSK?  eDPP++?  TLS with naked public keys++?  
> And again, this is the on-prem case.  For cloud, we are well along.
> 
> [Joe] We are currently in a holding pattern with EAP-TLS.  It does not seem 
> right to delay it for functionality that we are not sure we have a use case 
> for.  If a use case develops then we can publish an update to EAP-TLS 1.3.  
> Do we have a use case for EAP-TLS-PSK that is blocked in the current 
> situation?
> 

I would suggest that we do have a well-identified use case, although it has 
some issues, and that is IoT onboarding for on-prem equipment, as Owen 
described.  I do not know if we will end up executing on that use case, but it 
is a use case.  On the whole, the argument has to go the other way: why should 
we cripple a particular TLS method without strong justification?  The more we 
specialize the longer it takes to deliver new services, and the harder they are 
to support.

A fair argument, if it can be made, and I am not convinced it has been fully 
expressed, is the idea that there is no context by which one can separate fast 
restart and initial authentication.  This is Alan’s concern.  I’m not saying 
it’s without merit, but what I cannot yet see is whether it is an 
implementation or a protocol matter.

Eliot

> 
> 
> Eliot



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


Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

2019-10-11 Thread Eliot Lear


> On 11 Oct 2019, at 16:09, Michael Richardson  wrote:
> 
> So, can wired just be a degenerate version of wifi, where there can be only
> one "ESSID", and there are no beacons to consider?


On the whole that has been my thought.  But it is a matter of which mechanism 
to degenerate to.  Is it TLS-PSK?  eDPP++?  TLS with naked public keys++?  And 
again, this is the on-prem case.  For cloud, we are well along.

Eliot


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


Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

2019-10-11 Thread Eliot Lear


> On 11 Oct 2019, at 13:04, Michael Richardson  wrote:
> 
> 
> Eliot Lear  wrote:
>> Before we nail this down, it seems like we need to have a discussion
>> about how best to onboard wired IoT devices in particular from an
>> on-prem view.  The issue here is that EAP-TLS-PSK is useful for that
>> purpose, as we discussed.  Now there is nothing particularly special
>> about PSK and we could run with a naked public key pair as well in 1.3,
>> but we have to choose something.
> 
> okay, so why do you prefer PSK?

I do not.  But we need to have *a* flow for on prem onboarding.  TLS-PSK is one 
approach, but there are others.  I just want a discussion before we nail this 
down, as I wrote.

> 
>> The fundamental question is what does
>> a manufacturer stamp into the device and what is placed on a label.  We
>> have a running example of DPP doing this for wireless with public key
>> code, but that doesn’t get us to proper onboarding for wired – the
>> signaling just isn’t there.
> 
> I don't understand this.
> Are you saying that because it's wired, people do not expect to scan
> anything?

No quite the opposite- I’m saying that there is at least one way to do this 
with Wifi, but no way to do this for wired right now, an we need one.

Eliot

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



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


Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

2019-10-10 Thread Eliot Lear
Hi Mohit,

> On 10 Oct 2019, at 09:55, Mohit Sethi M  wrote:
> @Elliot: I understand your discomfort with constraining TLS 1.3. But there is 
> clearl precedent. The original EAP-TLS specification in RFC 5216 
> (https://tools.ietf.org/html/rfc5216 <https://tools.ietf.org/html/rfc5216>) 
> has no mention of PSKs.
> 

*Architecturally* I am angling toward code impact.  Is there a fundamental 
issue with TLS-PSK or is it just EAP-TLS-PSK?  This is a matter of how one 
would want to address the problem in OpenSSL/GNUTLS/TinySSL/WolfSSL and what 
the calling interfaces should be.

I want to stress again: whether it’s PSK or public key is conceptually not that 
different here.  There is some potential theft protection in public key 
mechanisms, but only if a real TEE is used.  We’re not seeing that as much as 
we would like yet, but it may make sense to aim in that direction.

Thus one potential outcome of this discussion is: PSK is just bad, and never 
use it, regardless of EAP or other.  Another potential outcome is the opposite. 
 And then there are some states in between.

Eliot
> --Mohit
> 
> On 10/10/19 10:44 AM, John Mattsson wrote:
>> Hi Eliot,
>> 
>> I agree that the question boils down to IoT. There are currently a lot of 
>> IoT systems using PSK, and many of them will likely want to stay on PSK, 
>> rather than migrating to RPK. Using a protocol with PFS is nowadays 
>> recommended practice. EAP-PSK does not provide PFS, and EAP-PWD is not 
>> suitable for IoT. I strongly think we need an EAP method with PSK + PFS for 
>> IoT, and the easiest way to achieve that seems to be EAP-TLS-PSK.
>> 
>> Cheers,
>> John
>> 
>> From: Eliot Lear  <mailto:l...@cisco.com>
>> Date: Thursday, 10 October 2019 at 09:14
>> To: Joseph Salowey  <mailto:j...@salowey.net>
>> Cc: John Mattsson  
>> <mailto:john.mattsson=40ericsson@dmarc.ietf.org>, 
>> "draft-ietf-emu-eap-tl...@ietf.org" 
>> <mailto:draft-ietf-emu-eap-tl...@ietf.org> 
>>  
>> <mailto:draft-ietf-emu-eap-tl...@ietf.org>, EMU WG  
>> <mailto:emu@ietf.org>
>> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
>> Resent from:  <mailto:alias-boun...@ietf.org>
>> Resent to: John Mattsson  
>> <mailto:john.matts...@ericsson.com>,  
>> <mailto:mo...@piuha.net>
>> Resent date: Thu, 10 Oct 2019 00:14:49 -0700 (PDT)
>> 
>> Hi Joe,
>> 
>> 
>> On 7 Oct 2019, at 02:42, Joseph Salowey > <mailto:j...@salowey.net>> wrote:
>> 
>> There is a TLS working group draft on importing external PSKs for use with 
>> TLS - https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-01 
>> <https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-01>.  This 
>> draft can mitigate some of the issues with using external PSKs.
>> 
>> My suggesting is to leave the draft as is and deal with external PSKs as an 
>> update to EAP-TLS 1.3 or as a separate method.
>> 
>> 
>> Before we nail this down, it seems like we need to have a discussion about 
>> how best to onboard wired IoT devices in particular from an on-prem view.  
>> The issue here is that EAP-TLS-PSK is useful for that purpose, as we 
>> discussed.  Now there is nothing particularly special about PSK and we could 
>> run with a naked public key pair as well in 1.3, but we have to choose 
>> something.  The fundamental question is what does a manufacturer stamp into 
>> the device and what is placed on a label.  We have a running example of DPP 
>> doing this for wireless with public key code, but that doesn’t get us to 
>> proper onboarding for wired – the signaling just isn’t there.
>> 
>> Also, maybe it’s me, but I remain uncomfortable about this group 
>> constraining TLS 1.3.
>> 
>> Eliot
>> 
>> 
>> 
>> Is the current published version up to date with the rest of the comments?
>> 
>> Thanks,
>> 
>> Joe
>> 
>> On Fri, Sep 20, 2019 at 3:42 AM John Mattsson 
>> > <mailto:40ericsson@dmarc.ietf.org>> wrote:
>> Hi Alan,
>> 
>> I added references to RFC 8446 Section 8.1, and 8.2, and 4.2.11. Agree that 
>> they are good to point out.
>> 
>> I am not sure about the other suggestions, I am hesitant to discuss anything 
>> detailed about TLS 1.3 that does not have a specific connection to EAP-TLS 
>> or are useful for users of EAP-TLS. My feeling is that adding some 
>> extension, but not other would be even more confusing. The diagrams are 
>> there to show the message flows, which have a strong connection t

Re: [Emu] TEAP errata 5770

2019-10-10 Thread Eliot Lear
Just one comment:

TEAP does not require an inner method, and indeed for IoT it is not necessary.

Eliot

> On 9 Oct 2019, at 07:46, Joseph Salowey  wrote:
> 
> Based on Jouni's analysis the derivation of the S-IMCKs is not well 
> specified.  To me it looks like the solution to handle an arbitrary number of 
> methods that may or may not make an EMSK available would be fairly complex.
> 
> I think the most straight forward solution is to either always assume that 
> for an EMSK generating method the EMSK is either always available or always 
> unavailable.  It seems that it is safer to always assume that the EMSK is 
> unavailable and will therefore never be used.  I think this has the following 
> implications:
> 
> -  The S-IMCK is always generated from the inner method MSK or the all-zero 
> value if the method does not generate key material.
> -  The EMSK compound MAC is not used
> -  Implementations must have a policy that accepts MSK MACs
> 
> It would appear that from a cryptographic analysis point of view the MSK and 
> EMSK are equivalent since these keys will only be used in these TEAP 
> calculations and not for other purposes..  There are documented drawbacks of 
> using the MSK described in RFC7029 
> (https://tools.ietf.org/html/rfc7029#page-12 
> ).   If the properties of the 
> EMSK binding are needed in the use cases currently under consideration then I 
> think we could redefine the way the EMSK MAC to be computed from the EMSK of 
> the inner method changing the above to
> 
> -  The S-IMCK is always generated from the inner method MSK or the all-zero 
> value if the method does not generate key material.
> - Compute EMSK MAC from the inner-method EMSK instead of the S-IMCK
>  Compound-MAC = MAC( EMSK[J], BUFFER )
> -  Implementations have a policy that prevents EMSK downgrade to MSK
> 
> Hopefully there is a more elegant solution. Any ideas?
> 
> Joe
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu



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


Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

2019-10-10 Thread Eliot Lear
I do think this is where we can make TEAP’s sweet spot.  But we should avoid 
differences in TLS implementations between TEAP and EAP-TLS.  That just 
complicates libraries.  And it’s for that same reason that I’m just a bit 
nervous about us constraining TLS 1.3.  Put another way: before we do so we 
have to answer this question: what is so different about EAP than other TLS 
applications?  If the answer is “nothing” for a particular case, then either we 
have it wrong or TLS 1.3 has it wrong, and we should sort that.

Eliot

> On 10 Oct 2019, at 09:44, John Mattsson  wrote:
> 
> Hi Eliot,
> 
> I agree that the question boils down to IoT. There are currently a lot of IoT 
> systems using PSK, and many of them will likely want to stay on PSK, rather 
> than migrating to RPK. Using a protocol with PFS is nowadays recommended 
> practice. EAP-PSK does not provide PFS, and EAP-PWD is not suitable for IoT. 
> I strongly think we need an EAP method with PSK + PFS for IoT, and the 
> easiest way to achieve that seems to be EAP-TLS-PSK.
> 
> Cheers,
> John
> 
> From: Eliot Lear mailto:l...@cisco.com>>
> Date: Thursday, 10 October 2019 at 09:14
> To: Joseph Salowey mailto:j...@salowey.net>>
> Cc: John Mattsson  <mailto:john.mattsson=40ericsson@dmarc.ietf.org>>, 
> "draft-ietf-emu-eap-tl...@ietf.org 
> <mailto:draft-ietf-emu-eap-tl...@ietf.org>" 
>  <mailto:draft-ietf-emu-eap-tl...@ietf.org>>, EMU WG  <mailto:emu@ietf.org>>
> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> Resent from: mailto:alias-boun...@ietf.org>>
> Resent to: John Mattsson  <mailto:john.matts...@ericsson.com>>,  <mailto:mo...@piuha.net>>
> Resent date: Thu, 10 Oct 2019 00:14:49 -0700 (PDT)
> 
> Hi Joe,
> 
> 
>> On 7 Oct 2019, at 02:42, Joseph Salowey > <mailto:j...@salowey.net>> wrote:
>> 
>> There is a TLS working group draft on importing external PSKs for use with 
>> TLS - https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-01 
>> <https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-01>.  This 
>> draft can mitigate some of the issues with using external PSKs.
>> 
>> My suggesting is to leave the draft as is and deal with external PSKs as an 
>> update to EAP-TLS 1.3 or as a separate method.
> 
> 
> Before we nail this down, it seems like we need to have a discussion about 
> how best to onboard wired IoT devices in particular from an on-prem view.  
> The issue here is that EAP-TLS-PSK is useful for that purpose, as we 
> discussed.  Now there is nothing particularly special about PSK and we could 
> run with a naked public key pair as well in 1.3, but we have to choose 
> something.  The fundamental question is what does a manufacturer stamp into 
> the device and what is placed on a label.  We have a running example of DPP 
> doing this for wireless with public key code, but that doesn’t get us to 
> proper onboarding for wired – the signaling just isn’t there.
> 
> Also, maybe it’s me, but I remain uncomfortable about this group constraining 
> TLS 1.3.
> 
> Eliot
> 
> 
>> 
>> Is the current published version up to date with the rest of the comments?
>> 
>> Thanks,
>> 
>> Joe
>> 
>> On Fri, Sep 20, 2019 at 3:42 AM John Mattsson 
>> > <mailto:40ericsson@dmarc.ietf.org>> wrote:
>>> Hi Alan,
>>> 
>>> I added references to RFC 8446 Section 8.1, and 8.2, and 4.2.11. Agree that 
>>> they are good to point out.
>>> 
>>> I am not sure about the other suggestions, I am hesitant to discuss 
>>> anything detailed about TLS 1.3 that does not have a specific connection to 
>>> EAP-TLS or are useful for users of EAP-TLS. My feeling is that adding some 
>>> extension, but not other would be even more confusing. The diagrams are 
>>> there to show the message flows, which have a strong connection to the EAP 
>>> state machine. For other details I think implementors have to read RFC 8466.
>>> 
>>> /John
>>> 
>>> -Original Message-
>>> From: Alan DeKok >> <mailto:al...@deployingradius.com>>
>>> Date: Wednesday, 18 September 2019 at 15:21
>>> To: "draft-ietf-emu-eap-tl...@ietf.org 
>>> <mailto:draft-ietf-emu-eap-tl...@ietf.org>" 
>>> >> <mailto:draft-ietf-emu-eap-tl...@ietf.org>>, EMU WG >> <mailto:emu@ietf.org>>
>>> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
>>> Resent from: mailto:alias-boun...@ietf.org>>
>>> Resent to: John Mattsson >> <ma

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

2019-10-07 Thread Eliot Lear


> On 7 Oct 2019, at 15:10, Alan DeKok  wrote:
> 
> On Oct 7, 2019, at 2:32 AM, John Mattsson 
>  wrote:
>> 
>> Joseph Salowey  wrote:
>> 
>>> Is the current published version up to date with the rest of the comments?
>> 
>> Yes, to my knowledge, the current draft handles all the other comments. If 
>> we decide to leave EAP-TLS PSK discussions for another draft, I think 
>> draft-ietf-emu-eap-tls13-07 is ready to move forward in the publication 
>> process.
> 
>  I agree.
> 
>  My one worry is that if we update EAP-TLS without also updating PEAP and 
> TTLS, then bad things will happen.
> 
>  My $0.02 is to remove the discussion of FAST and TEAP from 
> draft-dekok-emu-tls-eap-types, as the remaining items are not controversial.  
> The document should then be published simultaneously with the EAP-TLS updates.


If we evolve draft-lear-eap-teap-brski into a more generic TEAP update we could 
cover TLS 1.3 there.

Eliot



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


[Emu] Another side meeting on IOT onboarding

2019-03-25 Thread Eliot Lear
For those who are interested, we will be continuing our IoT Onboarding 
discussion Wednesday @ 2:00pm in Karlin 3.  Topics will include review of the 
various onboarding mechanisms that we listed on Github, review of the questions 
we were asking, some live editing of THAT, and some mapping of all of the 
various BRSKI-related work.  There’s a lot of it.

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


Re: [Emu] Review of draft-ietf-emu-eap-tls13-04

2019-03-21 Thread Eliot Lear
Hi

> On 20 Mar 2019, at 11:03, Jim Schaad  wrote:
> 
> TLS 1.3 introduced early application data;  if a server receives a client
> hello with early application data it MUST abort the handshake with an
> EAP-Failure.  The server MAY generate a TLS-Alert as well.


This precise text actually may have implications for onboarding, where the 
notion is to validate the data retrospectively.  In particular this impacts the 
previous statement: The EAP server MUST authenticate with a certificate and 
SHOULD require the EAP peer to authenticate with a certificate.

draft-ietf-anima-bootstrapping-key-infra defers the authentication during 
onboaridng stages, which I would expect draft-lear-eap-teap-brski to do as 
well.  However, the purpose of the deferral is extremely limited, and the 
information exchanged must be authenticated in order for any state generated to 
be retained.

Some eyes on this particular aspect would be useful next week.

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


Re: [Emu] [Iot-onboarding] On boarding again

2019-03-06 Thread Eliot Lear
PRs welcome!

> On 7 Mar 2019, at 08:28, Szymon Słupik  wrote:
> 
> Hi Eliot,
> 
> It'd be great to include Bluetooth mesh in here, as (despite sharing the 
> brand and the underlying radio with Bluetooth LE) it is a completely 
> different animal, when it comes to onboarding, authentication, security. I 
> will add some initial bullets for Bluetooth mesh here, hope to do this next 
> week.
> 
> Best
> Szymon Slupik
> President, CTO
> +1-415-696-9111 
> 
> ul. Jasnogórska 44
> 31-358 Kraków
> Poland
> 
> www.silvair.com <http://www.silvair.com/>
>  <https://www.facebook.com/meetsilvair/>
> <https://www.linkedin.com/company/meetsilvair/>
> <https://twitter.com/meetsilvair>
> NOTICE TO RECIPIENT
> We inform you that Silvair sp. z o.o. with its registered office in Cracow 
> (31-358), at Jasnogórska Street 44 is the controller of your personal data. 
> You can find more information about processing personal data and your rights 
> here 
> <https://silvair.com/media/filer_public/e5/ba/e5ba1ed2-84e6-47da-8277-f10df2eed7cc/information_on_personal_data_processing_of_representative_of_entity_mail_contacts_to_establish_maintain_business_relationshipsfn.pdf>.
> This e-mail message and any documents accompanying it contain information 
> that belongs to SILVAIR. This e-mail is meant for only the intended recipient 
> of the transmission, and may be a communication privileged by law, 
> confidential and/or otherwise protected from disclosure. If you received this 
> e-mail in error and you are not the intended recipient, any review, use, 
> dissemination, distribution, or copying of this e-mail or attachment is 
> strictly prohibited. Please notify us immediately of the error by return 
> e-mail and please delete this message from your system.
> 
> 
> 
> On Wed, Mar 6, 2019 at 2:32 PM Eliot Lear  <mailto:l...@cisco.com>> wrote:
> Hi everyone,
> 
> For those who are interested in discussing onboarding, I’ve reserved an hour 
> on Wednesday afternoon (27 Mar) at 14:00 at the IETF in Karlin 3.  Since our 
> last conversation, a few of us put a bit of an inventory together, regarding 
> the mechanisms that are available.  Some of the questions we have Aren’t 
> Quite There Yet, but at least the inventory is coming along.
> 
> Goal of discussion this time around  would a shared understanding of how 
> these mechanisms work, what sort of commonality they have, and to perhaps 
> have some notion of applicability of each.
> 
> For your entertainment, you can take a look at a table… it’s a Github table 
> so you have to scroll a bit- see 
> https://github.com/iot-onboarding/catalog/blob/master/Onboard-Table.md 
> <https://github.com/iot-onboarding/catalog/blob/master/Onboard-Table.md>.  
> Feel free to issue PRs.
> 
> Also, feel free to agenda bash on iot-onboard...@ietf.org 
> <mailto:iot-onboard...@ietf.org>.
> 
> Eliot
> --
> Iot-onboarding mailing list
> iot-onboard...@ietf.org <mailto:iot-onboard...@ietf.org>
> https://www.ietf.org/mailman/listinfo/iot-onboarding 
> <https://www.ietf.org/mailman/listinfo/iot-onboarding>



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


Re: [Emu] Questions about EAP-NOOB

2019-03-06 Thread Eliot Lear
Hi Aura,

Just on this one point:

> On 6 Mar 2019, at 13:23, Aura Tuomas  wrote:
> 
> 
> The realm used by the peer is initially “eap-noob.net 
> ”. The server can assign another realm in Initial 
> Exchange. The main purpose for assigning another realm is that the peer can 
> later use it for roaming in access networks that have AAA routing set up for 
> the assigned realm.
> 

Since this is going to be somewhat common between new mechanisms as a routing 
function (and it’s a very good idea!), it makes sense for the realm to be 
properly registered as a protocol parameter.  A few of us had a discussion 
about this.  The suggestion was made that this should fall under the .ARPA 
domain, so that it is properly reserved.  I propose that we discuss this a bit 
in Prague.  (FWIW, I didn’t come up with the .ARPA idea, but I like it).

Eliot



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


Re: [Emu] Questions about EAP-NOOB

2019-03-06 Thread Eliot Lear
And indeed it was Alan who I was referring to in my message.  I generally agree 
with Alan’s thinking below.

Eliot

> On 6 Mar 2019, at 13:45, Alan DeKok  wrote:
> 
> On Mar 6, 2019, at 7:23 AM, Aura Tuomas  wrote:
>> The realm used by the peer is initially “eap-noob.net”. The server can 
>> assign another realm in Initial Exchange. The main purpose for assigning 
>> another realm is that the peer can later use it for roaming in access 
>> networks that have AAA routing set up for the assigned realm.
> 
>  This is fine for an initial draft.  I'd avoid implementing anything that 
> uses "eap-noob.net", though.
> 
>  The correct domain to use is .arpa:
> 
>   https://www.iana.org/domains/arpa
> 
>  The controlling document here is RFC 3172.
> 
>  It looks like EAP-TEAP-BRSKI requires a similar NAI for provisioning.  So it 
> would best best to coordinate both the name, and the use of it.  Perhaps 
> "provisioning.arpa" could be used as a generic name, and then subdomains 
> within that could be used for particular purposes.
> 
>  Alan DeKok.
> 
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu



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


[Emu] On boarding again

2019-03-06 Thread Eliot Lear
Hi everyone,

For those who are interested in discussing onboarding, I’ve reserved an hour on 
Wednesday afternoon (27 Mar) at 14:00 at the IETF in Karlin 3.  Since our last 
conversation, a few of us put a bit of an inventory together, regarding the 
mechanisms that are available.  Some of the questions we have Aren’t Quite 
There Yet, but at least the inventory is coming along.

Goal of discussion this time around  would a shared understanding of how these 
mechanisms work, what sort of commonality they have, and to perhaps have some 
notion of applicability of each.

For your entertainment, you can take a look at a table… it’s a Github table so 
you have to scroll a bit- see 
https://github.com/iot-onboarding/catalog/blob/master/Onboard-Table.md 
.  Feel 
free to issue PRs.

Also, feel free to agenda bash on iot-onboard...@ietf.org 
.

Eliot


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


[Emu] side meeting on IoT onboarding

2018-11-07 Thread Eliot Lear
Hi everyone,

Thanks to those 30 or so people who participated in a side meeting just
after OPSAWG on IoT onboarding.  There was pretty clear agreement that
there is at least some fragmentation occurring in onboarding solutions,
leading to some confusion amongst some of the players.  In some cases,
like consumer, some didn't care that much, but everyone seemed to see
the problem in enterprise and industrial.  A few notes:

  * “Onboarding” means different things at different layers. As we move
forward we are primarily thinking about network onboarding here, but
if the credential used for network onboarding can be used for
application onboarding, that's a nice feature.
  * This matter spans multiple standards organizations.  In the meeting
yesterday we had participants from at least five, for example.
  * We agreed to try to flesh out a wiki that talks about all the
different mechanisms.  Some of these are cataloged in various
places, and some are not.  We are not at this point limiting
ourselves to just IP.
  * We also want to try to articulate architectural requirements.
  * As we build out the inventory of mechanisms we will seek to identify
common architectural components.
  * We'll try to get far along on the wiki for a December conference
call just to see how well we did, and to talk about next steps.
  * The activity is entirely open.  I've asked for a mailing list to be
created, and I have created a github repository known, funnily
enough, as "iot-onboarding".

If you're interested in this activity, please feel free to join the
mailing list when it is announced or otherwise add to the repository. 
If you were in the room and want to add your views, great.

Eliot




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


[Emu] change of venue: onboarding side meeting

2018-11-05 Thread Eliot Lear
As we seem to have a lot of interest in the topic of onboarding, we are
at risk of overflowing the very small room we were assigned.  Therefore,
the side meeting will now take place immediately after OPSAWG in Chitlada 2.

This meeting is intended as a discussion about whatever common
architectural blocks we can find between mechanisms such as ANIMA BRSKI,
DPP, EAP-NOOB, and others.

Regards,

Eliot





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


Re: [Emu] [Anima] ship and forget use cases for onboarding

2018-10-23 Thread Eliot Lear
Hi Michael,


On 22.10.18 21:54, Michael Richardson wrote:
>
>
> https://en.wikipedia.org/wiki/Joe_Isuzu  ... I asked google, and I'm not
> quite sure I get the connection.

Sorry- this was a reference to an earlier message.  There is a mode in
which the MASA is acting based on its relationship with the registrar. 
The punch line with Joe Isuzu was “Trust me!”
> It's not enough to say that they are going to be deployed in disconnected
> environments.  It's that they one wants to drop-ship them from the
> *manufacturers* warehouse to the disconnected location.

There are quite a number of use cases where connectivity may be an issue:

  * A secure building, where Internet access is limited, and even
carrying in a USB stick is problematic.  This can range from a
military installation to a pharmaceutical laboratory, to certain
departments of financial institutions.
  * It could simply be an order of operations matter, where the device
has arrived in advance of Internet connectivity but still wants to
function (think fire suppression systems).

You may say, “but onboard them advance of their deployment”.  That may
or may not be practicable.

> When one thinks about drop-ship to a disconnected location, one tends to
> think about containers of humanitarian AID going out the back of a aircraft
> (C-2, Hercules, etc.) with a parachute.   If anything, that situation is
> probably *NOT* the case we are thinking about, because in that case the kit
> would have already gone through the owner's warehouse (whether the owner is
> a UN aid agency, some FEMA equivalent).  The entire kit could have been
> onboarded (wirelessly) as it went *onto* the aircraft, or could even occur
> as late as when it's on the aircraft.

I think we're get a better feel for some of this as time goes on, but
one could imagine components sitting in a drawer for five years. 
>
> And you said, "online MASA", when it could well be that it's an offline
> MASA.  If you buy enough product, the manufacturer could well just put
> a custom trust anchor in and give you the private key.  That's essentially
> what happens in Industrial 4.0 802.15.4 deployments today.

I certainly know manufacturers who do that, and they mostly hate it,
because it requires custom builds.

>
> So I'm saying, let's not invent a problem before we understand who actually
> has the problem and make sure that the people who can solve the problem
> are at our table.

This sounds like an EXCELLENT conversation for the next few weeks.

Eliot

>
> --
> Michael Richardson , Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
>
>
> ___
> Anima mailing list
> an...@ietf.org
> https://www.ietf.org/mailman/listinfo/anima



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


Re: [Emu] Fwd: New Version Notification for draft-lear-brski-pop-00.txt

2018-10-22 Thread Eliot Lear
[Christian, read down a ways]


On 22.10.18 20:15, Michael Richardson wrote:
> Eliot, thanks for this document. If nothing else, it means that
> we BRSKI authors can deal with some review comments by pointing to "future
> work" :-)
>
> (A)"request-voucher-with-possession" <-- what about intent to traffic? :-)
>   (for those that don't get the joke:
>   
> https://criminal.findlaw.com/criminal-charges/possession-with-the-intent-to-distribute.html
>  )
>
> if leaf out-of-band-claim to be set by the PLEDGE?
> I think it is set by the Registar?

In all cases, any out of band claim has to be collected by the
Registrar.  It is possible that having received such a claim from the
Registrar, the pledge forwards it along to the MASA.

>
> The document sadly ends too soon...

Gosh.  You want it all at once, don' you?!  Become an editor ;-)
>
> You say it is trying to do a few things.
>   1) deal with middle value pledge,
>  (and low-value pledges in very congested places)
>  where an out-of-band supply-chain integration is unavailable,
>  and the MASA has a any-registar policy for the device.

Yes.
>
>   2) provide a ship-and-forget mechanism.

Yes.
>
> It seems that the cryptographic POP mechanism is an ends to accomplish a
> means, rather than a core goal of the protocol.

I never employ hashes just for fun ;-)

> The Pledge already can
> sign it's voucher-request, and since it includes the Registrar's key when it
> does a proximity assertion, it's pretty good proof of possession for the
> *Registrar*, but it might provide inadequate assurance to the MASA of it's
> freshness.

I think this covers the Joe Isuzu case that can fall out of the draft,
and maybe one other.  The fundamental issue with the others is that the
Pledge needs some reason to believe that it is really on the correct
network.  Proof of possession can come in several forms, depending on
the device, but we're assuming that there's no user input to the device
available (e.g., no buttons, to touch screen, etc).  It could also be
that the Pledge really doesn't want to validate proof of possession by
itself.  In that case, there's no reason for the pledge to even know the
proof of possession.


>If the MASA could provide a nonce for the pledge to sign
> (requiring another round trip, and even more online assurance), that would
> provide even more proof.
>
> Given that you pushed this out before today's cutoff, I am not upset
> that there is so few details.  I am suspecting that in your thinking that you
> created the three objects, and realized that could accomplish
> "ship-and-forget" using a combination of them?

That's part of the thinking, yes.

>
> I also wonder if cryptographic-POP is being confused with "proof of
> ownership", which I think is what you really want to accomplish.

We can have that discussion .
>
> If one assumes some machine readable (QR) code that comes with the product,
> then there are a few things one can do to differently.  One of the things
> that I have thought a lot about is that one uses the printed code in the
> Registrar to establish a relationship with the MASA.  That is, one creates
> the supply-chain-integration by using the QR code with some zero-knowledge
> proof (I think that PAKE is the latest one) to establish that one is the
> legitimate Registrar for the product.  One can do this as *any time*
> (some mumble about the lifetime of the CA of the Registrar's key), and
> the product will be enrolled correctly at any future time.

Good point.  One possible thought in terms of the evolution of this work
would be “More stuff you can do with vouchers” with a plethora of
documented uses.  Or we might want to spawn a few more drafts.  Again,
worth discussion.

>
> About my joke (A) above, I think that ship-and-forget is an interesting
> goal, and in particular, if also may enable desireable "traffic"ing.  That
> is, if the manufacturer can transfer the product to my ownership without any
> online interaction, then presumably, I can also *resell* the device to
> you using the same lack-of-interaction?

Yes.  In fact that is a goal that I think both Christian and Randy have
motivated.  I would want to explore a bit whether or not to split out
ship and forget, but I would rather we tried to solve for that problem
because it really is here (see below).
>
> 
>
>> In addition, some manufacturers may prefer not to require the
>> existence of a MASA.  In these circumstances proof of possession to
>> the device is required.
>
> I would prefer that we split this into a different draft.
>
> I am very concerned that ship-and-forget is not a desireable property
> in the IoT space.  It essentially means that the manufacturer has no further
> interest in providing any kind of updates for the device.I have serious
> cybersecurity concerns about such devices being out there (sitting unpatched
> and untracked in a warehouse somewhere), as well as significant environmental
> concerns about devices 

[Emu] Fwd: New Version Notification for draft-lear-brski-pop-00.txt

2018-10-20 Thread Eliot Lear
As promised, here is a draft that attempts to wangle BRSKI to allow for
proof of possession tests.  This is very early work and intended for
discussion at this point during OPSAWG and at the side meeting we have
scheduled for Tuesday night.  If people like what they see, we can
discuss in more detail in Prague.

This draft includes three specific test types, one of which may come out
Real Soon:

 1. The registrar has obtained proof of possession and provides that
proof to the MASA.  This solves a wireless case.
 2. The registrar has obtained proof of possession and, rather than
providing proof to the MASA, provides proof to the pledge (two-party
instead of three).
 3. The registrar tells the MASA, “Trust Me!  Really!” in its best Joe
Isuzu voice*.  (This may be redundant, which is why it may come out.)

Discussion points:

  * The basis of all of this work is really that Max, Michael, and Kent
did a bang up job by coming up with the voucher concept, and so
let's all agree PLEASE that no matter how we slice it, a voucher
request needs to be generated, and a voucher response needs to be
delivered.  The means for proof, and even the identity returned, can
be stretched.
  * Should we stretch further, and include different keying material
objects?  I'm CCing EAP folk because that is a big fat question for
them.

Eliot

* See https://www.youtube.com/watch?v=mR361ASrMew


--- Begin Message ---

A new version of I-D, draft-lear-brski-pop-00.txt
has been successfully submitted by Eliot Lear and posted to the
IETF repository.

Name:   draft-lear-brski-pop
Revision:   00
Title:  Proof of Possession to Devices for Onboarding
Document date:  2018-10-20
Group:  Individual Submission
Pages:  7
URL:https://www.ietf.org/internet-drafts/draft-lear-brski-pop-00.txt
Status: https://datatracker.ietf.org/doc/draft-lear-brski-pop/
Htmlized:   https://tools.ietf.org/html/draft-lear-brski-pop-00
Htmlized:   https://datatracker.ietf.org/doc/html/draft-lear-brski-pop


Abstract:
   This memo specifies a RESTful interface for local deployments to
   demonstrate proof of possession to a device or to a manufacturer
   authorized signing authority (MASA).  This covers the case where a
   MASA would not otherwise have knowledge of where a device is
   deployed, or when a MASA may not be required.  Such knowledge is
   important to onboard certain classes of devices, such as those on
   IEEE 802.11 networks.


  


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.

The IETF Secretariat


--- End Message ---


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


Re: [Emu] Comments on draft-lear-eap-teap-brski

2018-10-09 Thread Eliot Lear
Hi Alan,

My apologies for the long delay in this reply


On 21.07.18 16:11, Alan DeKok wrote:
>   One of the confusions from the meeting was "How can a device authenticate 
> via 802.1X if it doesn't trust the network?"
>
>   I think the confusion is due to terminology.  The discussion in the 
> meeting, and in the draft was about the device "authenticating" to the 
> network during initial bootstrapping.  The authors may correct me if I'm 
> wrong, but this step is really "provisioning".

I think I caught one instance where "authentication" was really
superfluous.  I would be happy to find more cases.

>
>   i.e. the device gets on the network without authenticating itself in the 
> traditional sense (password, certificate, etc.)
>
>   The document isn't clear on this, which makes it more difficult to 
> understand.
>
>   From Section 3.1 of the document:
>
>The device establishes an outer TEAP tunnel with the TEAP server and
>does not validate the server certificate.
>
>   I would also add that the TEAP server does not authenticate the device (as 
> such).  Instead, this step is about provisioning.

Added words to this effect.



>
>   Continuing from Section 3.1:
>
>The device sends a BRSKI-RequestVoucher TLV to the TEAP server.  The
>TEAP server forwards the RequestVoucher message to the MASA server,
>and the MASA server replies with a signed voucher.  The TEAP server
>sends a BRSKI-Voucher TLV to the device.
>
>If the MASA server does not issue a signed voucher, the TEAP server
>sends an EAP-Error TLV with a suitable error code to the device.
>
>   It would help to say that neither the TEAP server nor the MASA server has 
> (as yet) authenticated the device.  Which means that the device has 
> established a secure tunnel to an unknown endpoint.  That endpoint may later 
> reject the device, at which point the device tries another SSID.
>
>   As a practical example, there may be two businesses who wish to install 
> WiFi cameras.  Each business has their own SSID.  Any new device will 
> randomly connect to one of the SSIDs.  If the device is known (somehow) to 
> the business, it will be provisioned and allowed onto the network.  If the 
> device is not known, it will be rejected, and will try the other SSID.

This is a really good point.  I've added some text along these lines.

>
>   I think it would help future discussions to consistently refer to this 
> phase as "provisioning", and not "authentication".
I'm sure we'll miss a few.  Please keep us on our toes.
>   i.e. "the device provisionally connects to the 802.1X network".  Or "the 
> device connects to the 802.1X network for initial provisioning".

Let's see how the next version reads.  We can continue to evolve this text.
>
>   Once the device is provisioned, it can "authenticate" to the 802.1X network 
> as normal.  i.e. from Section 3.1 again:
>
>Once step 5 is complete, the device has completed the BRSKI flow and
>has established trust with the network.
>
>   I would add "the device can then perform normal 802.1X authentication with 
> it's provisioned credentials, and with the provisioned network information."

Not quite yet, right?  It still needs an LDevID.  But yes, later.

>
>   From section 4.1:
>
> If the client is bootstrapping and has
>not yet completed a BRSKI flow, it will not have trust anchors
>installed yet, and thus will not be able to validate the server's
>certificate.
>
>   It would help instead to use consistent terminology:
>
> If the client is in the provisioning phase and has
>not yet completed a BRSKI flow, it will not have trust anchors
>installed yet, and thus will not be able to validate the server's
>certificate.
Ok.
>
>   And the same applies later:
>
>It is recommended that the client validate the certificate presented
>by the server in the server's Certificate message, but this may not
>be possible for bootstrapping clients that do not have appropriate
>trust anchors installed yet.

Ok.
>
> to:
>
>It is recommended that the client validate the certificate presented
>by the server in the server's Certificate message, but this may not
>be possible for clients which have not yet been provisioned with
>the appropriate trust anchors.
>
>   The referenced IDs use the term bootstrapping", 
> (ietf-anima-bootstrapping-keyinfra).  But RFC 7170 (TEAP) uses 
> "bootstrapping" once, and "provisioning" many times.
>
>   My $0.02 is that "provisioning" is clearer in this context than 
> "bootstrapping".
Thank you!

Eliot
>   Alan DeKok.
>
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>




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