Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[Eliot Lear]

On 25.10.2023 17:31, Michael Richardson wrote:

As a goal, we need to migrate to more use of EAP-TLS in home environments.


TEAP!



OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key


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

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[Eliot Lear]

Ahah!  Ok.  I suggest a slight rename: FIDO's got tokens and Fido's got 
FDO, and the two are quite separate.  EAP-FIDO-TOKEN?


Eliot

On 24.10.2023 12:24, Jan-Frederik Rieckers wrote:

On 24.10.23 09:12, Eliot Lear wrote:> Thanks for the draft.  Question:


Is the intent that the FDO authentication happen each and every time, 
or just during ownership transfer?


The intent is to do a FIDO authentication every time (maybe with the 
exception of TLS session resumption, Text for that is still TODO).


But with CTAP v2 you can trigger silent authentication, so the user 
does not need to touch their FIDO token every time they need to 
re-authenticate, the token just needs to be available (which is more 
complex with hardware tokens like YubiKeys, but very easy with 
OS-backed FIDO implementations)


Cheers,
Janfred


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


OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key


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

Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[Eliot Lear]

Hi Jan-Frederik

Thanks for the draft.  Question:

Is the intent that the FDO authentication happen each and every time, or 
just during ownership transfer?


Thanks,

eliot

On 24.10.2023 00:38, Jan-Frederik Rieckers wrote:

Hi emu folks,

as already teased at the last IETF, we finally have a first I-D ready 
for EAP-FIDO.[1]


The basic idea:
Password-based network authentication is not really state-of-the-art 
any more and, due to failure to verify the server certificate, 
sometimes even completely broken.
Almost every device nowadays has a TPM chip or something similar, that 
is able to speak FIDO, either with the help of the OS or generically.

So, why not use FIDO to log in to networks?

There is a proof-of-concept implementation (not compatible with the 
spec in the draft yet, just to show that "It works™") that was used to 
perform an eduroam login at a conference with an EAP-FIDO key.


We will hold a side-meeting on Monday evening, 18:00 in Room Karlin 4, 
to discuss some of the open design questions and to gather feedback on 
what else may be needed in the specification.


We have also requested a time slot at the emu session on Tuesday, to 
shortly present the work.


Any feedback is welcome.

Cheers
Janfred

[1]: https://datatracker.ietf.org/doc/draft-janfred-eap-fido/


___
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: PKCS exchange notes

[Eliot Lear]

On 28.08.23 20:10, Heikki Vatiainen wrote:
Here are some notes that I thought could be useful to sharpen how PKCS 
exchange is documented.


Example exchange C.11. PKCS Exchange shows how certificate 
provisioning is done with TEAP:

https://www.ietf.org/archive/id/draft-ietf-emu-rfc7170bis-13.html#name-c11-pkcs-exchange

Section 3.11.1 "Certificate Provisioning within the Tunnel" describes 
the process:

https://www.ietf.org/archive/id/draft-ietf-emu-rfc7170bis-13.html#section-3.11.1

First, section 3.11.1 states that authentication is needed before 
provisioning, but C.11. does not show any authentication. Should the 
diagram show phase 1 client certificate authentication or phase 2 
tunnelled authentication? Are both valid types of authentication as 
required by section 3.1.1?


C.11 assumes bi-directional certificate exchange OR POK.  Perhaps that 
should be stated.





Second, C.11. shows that provisioning ends with Crypto-Binding TLV 
exchange. What is the EMSK and/or MSK used to calculate the TLVs? Is 
this a case where IMSK is an all-zeroes MSK? Should Section 3.11.1 
define these?


Yes and yes.




Third, the draft does not say that PKCS exchange is an inner method. 
It's not an inner authentication method, but according to example 
C.11. the exchange ends with Crypto-Binding and Intermediate-Result 
TLV exchange similarly to inner authentication methods. Would it be 
possible to clarify the type of PKCS exchange (inner method, something 
else). Because it appears to be an inner method, also add text to 
section 3.11. where the use of the two TLV types is required.


Agree.  It's an inner method, as indicated in Section 4.3.2.

Eliot



--
Heikki Vatiainen
h...@radiatorsoftware.com

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


OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key


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

Re: [Emu] I-D Action: draft-ietf-emu-rfc7170bis-13.txt

[Eliot Lear]

Hi Heikki

Ok, so *I* let it soak for a few days ;-) and I'm comfortable with the 
wording.


Eliot

On 27.08.23 16:42, Heikki Vatiainen wrote:

On Fri, 25 Aug 2023 at 22:30, Eliot Lear  wrote:

I agree with the sentiment, but I think it would be good for the
words
to soak a bit, since the paragraphs are a little involved. There
may be
a simpler way to say the same thing.


The diff between RFC 7170 and the current draft may help with the 
proposed change. I just noticed that 'EAP' was used more in the RFC 
than in the draft:


https://author-tools.ietf.org/diff?doc_1=RFC7170_2=draft-ietf-emu-rfc7170bis%2F 
<https://author-tools.ietf.org/diff?doc_1=RFC7170_2=draft-ietf-emu-rfc7170bis%2F>


If one looks at section 5.2, 'EAP method' is simplified in the draft 
to just 'method'. Then later in section 5.2 and in section 5.3. 
there's new text that says 'If no inner EAP authentication method is 
run then no EMSK or MSK will be generated ...'. Since, for example, 
vendor specific (authentication?) methods are required to support 
"calculation of the Crypto-Binding TLV (section 3.6)", it seems it's 
incorrect to state only EAP can generate EMSK or MSK.


I've also just pushed a one-line update to git to update the first 
paragraph of section 5.3 "Computing the Compound MAC" which currently 
says this:


 After each successful inner EAP authentication, EAP EMSK and/or
MSKs are cryptographically combined ...


The update simply drops the both instances of 'EAP '. I'd say this is 
in-line with the text already present in the draft sections 5.2 and 
5.3 which talk about how all inner methods need to updated the 
compound values.


I've only updated sections 5.2 and 5.3 to complete the s/EAP// changes 
that were already partially done in the earlier draft versions.


Related to this, a closer look at the draft shows that at least the 
following terms are used in interchangeable manner:

- EAP authentication method
- EAP method
- authentication method
- method
- inner method
- Phase 2 authentications
- authentication
- conversation (Sequence C.6. with chained EAPs)

In terminology section only 'Inner method' is defined and it seems to 
me that in many cases 'Inner method' would suffice when some of the 
term is used. There are of course cases when a specific term, such as 
'EAP method', is needed.


Heikki


Eliot

On 25.08.23 21:27, Alan DeKok wrote:
> On Aug 25, 2023, at 10:07 AM, Heikki Vatiainen
 wrote:
>> I have one small suggestion.
>> ...
>> I've created a pull request that updates the 'EAP
authentication' part to say 'inner authentication' so that in case
there's an inner method (perhaps provisioning?) that's not EAP but
that can provide keying material, the text won't be too restrictive.
>>
>> https://github.com/emu-wg/rfc7170bis/pull/26
>    I think that's reasonable.  Unless there are objections, I'll
pull it in.
>
>    Alan DeKok.
>
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>



--
Heikki Vatiainen
h...@radiatorsoftware.com

___
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] Patch: revert some IMSK derivation changes

[Eliot Lear]

Heikki

This change looks good.  I want to code it with the PKCS ops to make 
sure it's okay.  That'll take a little bit.


Eliot

On 27.08.23 19:16, Heikki Vatiainen wrote:

RFC 7170 and the current draft have diverged in how IMSK is calculated.

In short:
1. RFC 7170 pass EMSK to TLS-PRF whereas the draft passes both EMSK 
and MSK to TLS-PRF.
2. While RFC 7170 adjusts only MSK to 32 octet length, the draft 
adjusts both EMSK and MSK.


See section 5.2 "Intermediate Compound Key Derivations" in the diff 
for the current changes:
https://author-tools.ietf.org/diff?doc_1=RFC7170_2=draft-ietf-emu-rfc7170bis-13%2F 



I've created a pull request with more details about which two commits 
have lead to this change and my suggested fix.


https://github.com/emu-wg/rfc7170bis/pull/27

Alex, please comment. I've discussed this with a colleague and we 
think the current draft would break compatibility with the existing 
implementations.


--
Heikki Vatiainen
h...@radiatorsoftware.com

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


OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key


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

Re: [Emu] I-D Action: draft-ietf-emu-rfc7170bis-13.txt

[Eliot Lear]

I agree with the sentiment, but I think it would be good for the words 
to soak a bit, since the paragraphs are a little involved. There may be 
a simpler way to say the same thing.


Eliot

On 25.08.23 21:27, Alan DeKok wrote:

On Aug 25, 2023, at 10:07 AM, Heikki Vatiainen  
wrote:

I have one small suggestion.
...
I've created a pull request that updates the 'EAP authentication' part to say 
'inner authentication' so that in case there's an inner method (perhaps 
provisioning?)  that's not EAP but that can provide keying material, the text 
won't be too restrictive.

https://github.com/emu-wg/rfc7170bis/pull/26

   I think that's reasonable.  Unless there are objections, I'll pull it in.

   Alan DeKok.

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



OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key


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

Re: [Emu] WGLC on draft-ietf-emu-rfc7170bis-11

[Eliot Lear]

https://datatracker.ietf.org/doc/draft-ietf-emu-bootstrapped-tls/

On 19.08.23 21:12, Michael Richardson wrote:

Eliot Lear  wrote:
 >> We don't need or want anonymous ciphersuites here.

 > We should keep the TLS-POK work in mind.

I didn't find an obvious draft about that in the TLS WG.


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






OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key


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

Re: [Emu] WGLC on draft-ietf-emu-rfc7170bis-11

[Eliot Lear]

On 18 Aug 2023, at 23:26, Michael Richardson  wrote:
> 
> If we are talking about an RFC8995 (BRSKI) mechanism then:
> 
> a) It requires that the Peer defer validation of the Server's certificate
>   until later on when another signed artifact is received (RFC8366 voucher).
> b) The server still validates the Peers' client (IDevID) certificate.
> 
> We don't need or want anonymous ciphersuites here.

We should keep the TLS-POK work in mind. 

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

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

[Eliot Lear]

Just to follow up:

On 18.08.23 19:47, Alan DeKok wrote:

On Aug 18, 2023, at 1:33 PM, Eliot Lear  wrote:

 The peer SHOULD verify the validity of the EAP server
 certificate and SHOULD also examine the EAP server name 
presented in
 the certificate in order to determine whether the EAP server 
can be
 trusted.

How?  Let me put this another way: if we don't specify the how, we should omit 
the text and leave it as a matter of policy for the peer.

   I'll punt, and say the same way as RFC 9190?  The subsequent text also 
references 5280, which contains additional validation rules.

   So I don't see this text as any different from what's done in 5216, 9190, 
TTLS, PEAP, etc.


 In addition,
 implementations MUST support matching the realm portion of the 
peer's
 NAI against a SubjectAltName of type dNSName within the server
 certificate.

I interpret that text to mean that the peer MUST verify that the rhs of the NAI 
that it sent matches the dnsName of the server cert SAN.  The value of this 
being to validate that the radius packet has been routed to the right server?  
I think this is okay.

   Yes.


Upon reflection this might answer my previous “How” question.



With regard to:



 Note that since TLS client certificates are sent in the clear 
with
 TLS 1.2 and earlier, if identity protection is required, then 
it is
 possible for the TLS authentication to be renegotiated after 
the
 first server authentication.  To accomplish this, the server 
will
 typically not request a certificate in the server_hello; then, 
after
 the server_finished message is sent and before TEAP Phase 2, 
the
 server MAY send a TLS hello_request.


Has anyone coded this for TEAP?  Also, I think the diagrams in the Appendix may 
need some updating.

   I don't think anyone has implemented this.


This is more of an issue.

Eliot


OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key


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

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

[Eliot Lear]

Alan,

A few things with this text:

I'm having some issues with Section 3.3:


    The peer SHOULD verify the validity of the EAP server
    certificate and SHOULD also examine the EAP server 
name presented in
        the certificate in order to determine whether the EAP 
server can be

        trusted.


How?  Let me put this another way: if we don't specify the how, we 
should omit the text and leave it as a matter of policy for the peer.



                In addition,
        implementations MUST support matching the realm 
portion of the peer's
        NAI against a SubjectAltName of type dNSName within 
the server

        certificate.

I interpret that text to mean that the *peer* MUST verify that the rhs 
of the NAI that it sent matches the dnsName of the server cert SAN.  The 
value of this being to validate that the radius packet has been routed 
to the right server?  I *think* this is okay.



With regard to:

    Note that since TLS client certificates are sent in 
the clear with
        TLS 1.2 and earlier, if identity protection is 
required, then it is
        possible for the TLS authentication to be renegotiated 
after the
        first server authentication.  To accomplish this, the 
server will
        typically not request a certificate in the 
server_hello; then, after
        the server_finished message is sent and before TEAP 
Phase 2, the

        server MAY send a TLS hello_request.



Has anyone coded this for TEAP?  Also, I think the diagrams in the 
Appendix may need some updating.


On the following addition:

            Where the inner method does not provide an MSK or EMSK, 
the Crypto-
        Binding TLV offers little protection, as it cannot tie 
the inner EMSK
        to the TLS session via the TLS-PRF.  As a result, the 
TEAP session
        will be vulnerable to on-path active attacks. 
Implementations and
        deployments SHOULD adopt various mitigation strategies 
described in

        [RFC7029] Section 3.2.


Does this have an impact either with cert ops or the Phase 1 auth and 
close as discussed previously?


I may have a few more comments after the weekend.

Eliot

On 18.08.23 19:13, internet-dra...@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the EAP Method Update (EMU)
WG of the IETF.

Title   : Tunnel Extensible Authentication Protocol (TEAP) Version 1
Author  : Alan DeKok
Filename: draft-ietf-emu-rfc7170bis-12.txt
Pages   : 108
Date: 2023-08-18

Abstract:
This document defines the Tunnel Extensible Authentication Protocol
(TEAP) version 1.  TEAP is a tunnel-based EAP method that enables
secure communication between a peer and a server by using the
Transport Layer Security (TLS) protocol to establish a mutually
authenticated tunnel.  Within the tunnel, TLV objects are used to
convey authentication-related data between the EAP peer and the EAP
server.  This document obsoletes RFC 7170.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-emu-rfc7170bis/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-emu-rfc7170bis-12.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-emu-rfc7170bis-12

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


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



OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key


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

Re: [Emu] WGLC on draft-ietf-emu-rfc7170bis-11

[Eliot Lear]

On 18.08.23 15:31, Alan DeKok wrote:

   I don't see why we would want to_allow_  inner method resumption.  What 
benefit does it bring over just using resumption on the outer TLS session?


+1.  What's the use case?

Eliot

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

Re: [Emu] WGLC on draft-ietf-emu-rfc7170bis-11

[Eliot Lear]

I plan to implement.

On 17.08.23 21:11, Michael Richardson wrote:

 wrote:
 > Alan has issued -11 of draft-ietf-emu-rfc7170bis. He
 > believes it covers all of the outstanding issues that needed to be
 > resolved.  We held up the WGLC until we could have our session at IETF
 > 117. With post-117 changes incorporated, now's seems like the time for
 > the WGLC to go forward. Please post your comments to the mailing list
 > by August 28th. Even a "good to go" is genuinely helpful input.

If you have, or plan to implement, the document shepherd would like to know.

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





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


OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key


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

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

[Eliot Lear]

I went through -11 and find it entirely editorial in nature with no 
substantive changes, and entirely unobjectionable.


On 14.08.23 16:58, internet-dra...@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the EAP Method Update (EMU)
WG of the IETF.

Title   : Tunnel Extensible Authentication Protocol (TEAP) Version 1
Author  : Alan DeKok
Filename: draft-ietf-emu-rfc7170bis-11.txt
Pages   : 105
Date: 2023-08-14

Abstract:
This document defines the Tunnel Extensible Authentication Protocol
(TEAP) version 1.  TEAP is a tunnel-based EAP method that enables
secure communication between a peer and a server by using the
Transport Layer Security (TLS) protocol to establish a mutually
authenticated tunnel.  Within the tunnel, TLV objects are used to
convey authentication-related data between the EAP peer and the EAP
server.  This document obsoletes RFC 7170.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-emu-rfc7170bis/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-emu-rfc7170bis-11.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-emu-rfc7170bis-11

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


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



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

Re: [Emu] I-D Action: draft-ietf-emu-rfc7170bis-10.txt

[Eliot Lear]

I think this is okay.  I'd like to just check the diagrams, but that 
could happen as part of WGLC.


Eliot

On 03.08.23 20:34, Alan DeKok wrote:

The diff is perhaps more interesting:  
https://author-tools.ietf.org/iddiff?url1=draft-ietf-emu-rfc7170bis-09=draft-ietf-emu-rfc7170bis-10=--html

* clarify terminology on inner / outer TLVs as per Eliot's suggestion

* add paragraphs on resumption and provisioning as per recent discussion on the 
list.

   I believe that this addresses all concerns.


On Aug 3, 2023, at 2:30 PM, internet-dra...@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the EAP Method Update (EMU)
WG of the IETF.

   Title   : Tunnel Extensible Authentication Protocol (TEAP) Version 1
   Author  : Alan DeKok
   Filename: draft-ietf-emu-rfc7170bis-10.txt
   Pages   : 104
   Date: 2023-08-03

Abstract:
   This document defines the Tunnel Extensible Authentication Protocol
   (TEAP) version 1.  TEAP is a tunnel-based EAP method that enables
   secure communication between a peer and a server by using the
   Transport Layer Security (TLS) protocol to establish a mutually
   authenticated tunnel.  Within the tunnel, TLV objects are used to
   convey authentication-related data between the EAP peer and the EAP
   server.  This document obsoletes RFC 7170.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-emu-rfc7170bis/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-emu-rfc7170bis-10.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-emu-rfc7170bis-10

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


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

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



OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key


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

Re: [Emu] Housekeeping functionality (Was: Re: I-D Action: draft-ietf-emu-rfc7170bis-09.txt)

[Eliot Lear]

Ok, we might be having an Agree-O-thon...

On 04.08.23 11:49, Alan DeKok wrote:


   Access policies are applied after provisioning has been done.  So they are 
entirely irrelevant until the server replies with an EAP Success.


Yes.  So COAs and Disconnects aren't necessary at that point.




   Once the server replies with an EAP Success, access policies should be 
applied based on the provisioned (i.e. new) credentials.  This addresses all of 
the concerns which were raised over the last few days.


Yupper.



   i.e. there is no "change" of authorization when a user is provisioned.


Yup.



They're running EAP, and don't have network access.


Yup.



Since they have no current authorization, it can't be changed.


Yup.



Instead, they either get EAP Failure or Success.  So the only real question is 
which identity is used as the basis for access policies.  And that's simple, 
too: the new one.


Yep.

Eliot




   Alan DeKok.




OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key


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

Re: [Emu] Housekeeping functionality (Was: Re: I-D Action: draft-ietf-emu-rfc7170bis-09.txt)

[Eliot Lear]

Hi Alan,

Having given this a bit of thought, I think we are chasing our tails, 
and no text is required.  Let's look at two cases: expired credentials, 
and credentials that have not yet expired.


Expired Credentials

Handling an expired credential occurs in one of several ways in enterprises:

1. Don't bother doing anything at the network level and sort it at the
   application level (e.g., just allow access)
2. Don't bother doing anything at the network level *for now* and sort
   it on re-connect (this is a good case simply deleting the ticket,
   for example), and then into a sandbox.
3. CoA into a sandbox
4. Radius disconnect, and then into a sandbox.
5. Radius disconnect and then make use of request
   action(Result=Failure,...)

Most IoT can't handle 2-4 (what does it mean to put a device without a 
display into a sandbox?!), and may not even be able to handle 5!


My experience is that most enterprises use (1) while SPs don't normally 
rotate credentials at all, *although that may change*. There are 
*definitely* exceptions.  In any case, we can take the first use case 
off the table since it's not our problem.  (2) doesn't require anything 
new on-the-wire.  (3) and (4) require implementation of either CoA or 
Disconnect and are independent of EAP.  5 is new, but it's a pretty hard 
fail that *might* be appropriate so long as it really is recoverable.**


Now we get to the point where the credential has been renewed, and that 
was what we were discussing.  Once the credential has been renewed, 
cases 2-4 need to be dealt with.  3 and 4 require a tie in to some sort 
of application infrastructure and would require either a CoA or a 
Disconnect, and it's not happening at the EAP layer.  5 doesn't require 
a CoA or a disconnect, since EAP is not yet complete.


Not yet expired credentials

This now leaves the case where a renewal is taking place *prior* to 
credential expiration.  The *only* issue here is really whether there is 
any case that, based on renewal alone, an access policy change would 
ever take place *during* an ongoing communication.  My suggestion would 
be to recommend against such an action in the RFC, but if it is 
required, if we're in an EAP exchange then authorization will follow and 
there is no need for a CoA/Disconnect, since radius authorization 
information will follow.


What am I missing?

Eliot

On 03.08.23 16:07, Alan DeKok wrote:

On Aug 3, 2023, at 4:10 AM, Eliot Lear  wrote:

I think it's good to consider what's going on on both sides here.  At the 
beginning, both the identity and the role of the device in a network may be 
unknown, and so a certain access is given.  After bootstrapping has occurred 
(however that happens), then both the role of the device and the identity is 
established.  If the role of the device changes, then a COA seems appropriate 
where possible, or otherwise a Radius Disconnect.

   My one concern is that not all systems may support RADIUS CoA or Disconnect. 
 The original spec (3576) is only 20 years old.


I don't think EAP Failure should ever really be contemplated during a 
housekeeping operation unless an intermediate-success is first generated, 
because otherwise we can bet that at least some clients will take that as a 
signal that the house keeping operation failed, and they'll loop retrying.

   Since no one does provisioning yet, we have time to fix this.

   But yes, there must be an intermediate success.

   If we do require that provisioning finishes with EAP Failure, Section 3.4.4 
already suggests that a peer may received a Result TLV with Success from the 
server, and reply with a Request-Action indicating Success or Failure.  The 
server can then ignore that, or reply with more negotiation.

   Perhaps we could state that upon finishing of provisioning, the peer replies 
with Request-Action TLV, Status Failure, Action 3 Provisioning finished, and no 
TLVs.  The server can then reply with EAP Failure.

   I'll note that the peer can always simply stop doing EAP once it's fully 
provisioned.  i.e. it doesn't need to get an EAP Failure or EAP Success from 
the server.  However, such behavior is unfriendly to the server.  It leaves the 
server with a blocked EAP session that has to be eventually timed out.

   But that may not be necessary, see below.


Under the hood, housekeeping operations that update credentials are just 
updating entries in one or more tables that index to the same device as before, 
and so absent a change in role of the device, one shouldn't expect much in the 
way of a change of authorization policy.  There's one BIG exception: expired 
credentials.  Here again, this is server-side policy that might involve 
sandboxing the device, setting the result to EAP Failure in a request action 
TLV, opening a trouble ticket, firing an employee, or some such.

   For me, that's just "failure to authenticate".  It's already handled 
reasonably well.  And since EAP failure is returned, no change of aut

Re: [Emu] Housekeeping functionality (Was: Re: I-D Action: draft-ietf-emu-rfc7170bis-09.txt)

[Eliot Lear]

Hi Alan

I think it's good to consider what's going on on both sides here.  At 
the beginning, both the identity and the role of the device in a network 
may be unknown, and so a certain access is given.  After bootstrapping 
has occurred (however that happens), then both the role of the device 
and the identity is established. If the role of the device changes, then 
a COA seems appropriate where possible, or otherwise a Radius Disconnect.


I don't think EAP Failure should ever really be contemplated during a 
housekeeping operation *unless* an intermediate-success is first 
generated, because otherwise we can bet that at least some clients will 
take that as a signal that the house keeping operation failed, and 
they'll loop retrying.


Under the hood, housekeeping operations that update credentials are just 
updating entries in one or more tables that index to the same device as 
before, and so absent a change in role of the device, one shouldn't 
expect much in the way of a change of authorization policy.  There's one 
BIG exception: expired credentials.  Here again, this is server-side 
policy that might involve sandboxing the device, setting the result to 
EAP Failure in a request action TLV, opening a trouble ticket, firing an 
employee, or some such.


Let's also consider the crypto here.  The session key that was derived 
from a full authentication is still valid for resumption so long as one 
trusts the keying material to not have been observed/obtained.  That is 
independent of the cert/user password update taking place.


What I'm getting at is that house keeping operations are MOSTLY 
independent of authorization decisions (excluding expired credentials).


Coming back to your wording:


If the identity changes, as with some provisioning flows. the server SHOULD 
cause the EAP peer to re-authenticate.  This reauthentication can be done by 
returning an EAP Failure in order to cause the client to reconnect, or via a 
RADIUS Disconnect-Request packet after authentication, or change the 
authorization via a RADIUS CoA-Request, via other means.  This reauthentication 
is done in order to ensure that the user or device is accessing the network not 
only with the correct credentials,


My suggestion would be something along the lines of the following:

Under normal circumstances, house keeping operations should complete and 
the EAP connection SHOULD successfully complete.  If a change of 
authorization is required for some reason, the server SHOULD make use of 
a Radius COA, and not involve the peer so as to not impose excess 
operations on the peer (or itself).  In exceptional circumstances, a 
Radius-Disconnect MAY be used as a signal to a client directly after 
such operations to disconnect and authenticate with the new updated 
credentials.


Regards,

Eliot



OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key


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

Re: [Emu] Housekeeping functionality (Was: Re: I-D Action: draft-ietf-emu-rfc7170bis-09.txt)

[Eliot Lear]

I don't think this is a substantive change, because what Heikki is 
raising is entirely a matter of server-side policy.  I also am not sure 
it's the right change.  For one thing, if a server is willing to issue a 
new certificate, that's likely a policy statement that everything is 
AOK.  For another, this ISN'T a change of identity, and so there is 
really no need to re-evaluate other policy aspects.  Finally, in my 
opinion, it makes sense that during onboarding a device might need to be 
classified into a policy group, but if that is to change, then a COA 
seems more appropriate at the radius level, rather than forcing a 
re-connect.


Keep this in mind: end devices should be presumed to be pressed for 
resources, and anything requiring additional unnecessary authentications 
should be avoided in that case.


But again, this is all server side policy.  The only aspect for the 
client is that it should know when to re-authenticate if the server 
requires it.


Eliot

On 02.08.23 02:59, Alan DeKok wrote:

On Aug 1, 2023, at 7:08 PM, Heikki Vatiainen  wrote:

Using the above as an example case: When a client renews a certificate, should 
the server mark the current TLS session as non-resumable? With EAP-TLS, the 
server never knows immediately, because renewal is not in-band, when a 
certificate is renewed, therefore this is not an issue for EAP-TLS. Here we 
know that a renewal is in process and can take immediate action. While it's 
possible that the certificate renewal is for non-TEAP use, it shouldn't harm if 
the next authentication is full authentication.

   These are all good points I wish I had thought of earlier.

   i.e. any provisioning step should really be limited to provisioning.  The user should 
immediately drop the connection, and then reconnect using the provisioned credentials.  
This means that any authorization phase always operates the same way, on full 
credentials.  And there is no mixing of provisioning + "real" authorization.

   The simplest way to do this may be to require that any provisioning phase 
result in EAP Failure.  The inner tunnel can return the credentials, 
crypto-binding TLV, and a Result TLV which indicates success.  But the final 
outer EAP packet should be EAP Failure.

   I'm unsure if this is a substantive change to the document at this phase.  
Given that no one has implemented PKCS provisioning yet, it may be acceptable 
to make this change.


In general, here are some implementation related thoughts:

First, when housekeeping services are run in phase 2, should the current TLS 
session be made non-resumable?

   Yes.  If Phase 2 is provisioning, OR if the users credentials are expired / 
renewed in Phase 2, the current TLS session must be non-resumable.


The draft uses password and PIN change as examples of "housekeeping" and I'd say 
certificate renewal and peer's use of Trusted-Server-Root TLV are also "housekeeping" 
functions. Most, if not all, of these housekeeping services update or affect peer's credentials and 
for this reason, it may be desired to force full authentication the next time the peer 
authenticates again. More exactly: all currently cached TLS sessions with the peer may need to be 
considered as non-acceptable for resumption.

   Yes.


Second, in many cases there's some type of authorisation that follows 
successful authentication. For example, VLAN assignment may be returned with 
RADIUS Access-Accept that carries the EAP-Success. Maybe the draft should give 
implementation guidance on being careful to ensure that authorisation happens 
in controlled fashion?

   I would say that authorization only follows full authentication.  It cannot 
follow a provisioning step.


To put this differently, EAP-Success doesn't happen in vacuum but grants access 
to something. If housekeeping gets differently authorised access, then the 
server must be careful to handle correctly those clients that try something 
that a well-behaved client does not do.

For example, if peer authorisation happens differently when housekeeping is done, the 
server should be careful to decline TLS resumption or otherwise the client may get a 
shortcut to the housekeeping network. That is: resumption ok => Crypto-Binding TLS 
+ Intermediate-Result TLV + Result TLV all saying success => access to 
housekeeping network without housekeeping.

   That's hard to manage.  It may be easier to just mandate that servers reply 
with EAP Failure after a provisioning step.


Another example: If the client does TLS resumption and then proceeds to 
housekeeping, the server must be careful to ensure that authentication 
information cached from the last full authentication is still fresh enough for 
the housekeeping purposes.

   Yes.


Third, EAP-FAST Dynamic Provisioning RFC 5422 suggests denying after 
Server-Unauthenticated Provisioning Mode.
   https://datatracker.ietf.org/doc/html/rfc5422#section-3.5
Would this type of functionality useful for some housekeeping cases? I've 

Re: [Emu] I-D Action: draft-ietf-emu-rfc7170bis-09.txt

[Eliot Lear]

On 01.08.23 04:02, Alan DeKok wrote:

On Jul 31, 2023, at 6:00 PM, Eliot Lear  wrote:

We're not quite done.  The following text needs to be removed, an additional 
example added:


If there is no Phase 2 data, then the EAP
server MUST reject the session.  There is no reason to have TEAP
devolve to EAP-TLS.

   The intent was clarified in the next paragraph:

Note that the Phase 2 data could simply be a Result TLV with value
Success, along with a Crypto-Binding TLV and Intermediate-Result TLV.
This Phase 2 data serves as a protected success indication as
discussed in {{RFC9190}} Section 2.1.1

   i.e. TEAP with outer client certificate and no Phase 2 crypto-binding seems 
wrong.


IoT devices need a way to authenticate as TEAP is EAP-TLS under nominal 
conditions.  When a certificate is about to expire, then the expectation is 
that either the client will issue a PKCS#10 request or the server will issue a 
request action TLV with PKCS#10, so that the client knows the server wants it 
to renew.

   Sure.

   Perhaps the text could just remove the last sentence about devolving to 
EAP-TLS.


Yes, I think that would do nicely, thanks, along with the diagram 
demonstrating it (I think I sent that along to you).  Also, I would 
suggest a small editorial change to help call out the really important 
concept of outer versus inner, as follows:


OLD:

   TEAP packets may include TLVs both inside and outside the TLS tunnel.
   The term "Outer TLVs" is used to refer to optional TLVs outside the
   TLS tunnel, which are only allowed in the first two messages in the
   TEAP protocol.  That is the first EAP-server-to-peer message and
   first peer-to-EAP-server message.  If the message is fragmented, the
   whole set of messages is counted as one message.  The term "Inner
   TLVs" is used to refer to TLVs sent within the TLS tunnel.  In TEAP
   Phase 1, Outer TLVs are used to help establish the TLS tunnel, but no
   Inner TLVs are used.  In Phase 2 of the TEAP conversation, TLS
   records may encapsulate zero or more Inner TLVs, but no Outer TLVs.

   Methods for encapsulating EAP within carrier protocols are already
   defined.  For example, IEEE 802.1X [IEEE.802-1X.2013] may be used to
   transport EAP between the peer and the authenticator; RADIUS
   [RFC3579] or Diameter [RFC4072] may be used to transport EAP between
   the authenticator and the EAP server.

NEW

   Methods for encapsulating EAP within carrier protocols are already
   defined.  For example, IEEE 802.1X [IEEE.802-1X.2013] may be used to
   transport EAP between the peer and the authenticator; RADIUS
   [RFC3579] or Diameter [RFC4072] may be used to transport EAP between
   the authenticator and the EAP server.

   2.3 Outer TLVs versus Inner TLVs

   TEAP packets may include TLVs both inside and outside the TLS tunnel
   defined as follows:

   Outer TLV: this term is used to refer to optional TLVs outside the
   TLS tunnel, which are only allowed in the first two
   messages in the TEAP protocol.  That is the first,
   EAP-server-to-peer message and first peer-to-EAP-server
   message.  If the message is fragmented, the whole set
   of messages is counted as one message.

   Inner TLV:  this term is used to refer to TLVs sent within the TLS
   tunnel.

   In TEAP Phase 1, Outer TLVs are used to help establish the TLS
   tunnel, but no Inner TLVs are used. In Phase 2 of the TEAP
   conversation, TLS records may encapsulate zero or more Inner TLVs,
   but no Outer TLVs.

This just reverses the order of two paragraphs and visually separates 
outer / inner definitions.  We could in theory do the same with phase 
1/phase 2, but I think this is good enough.


Thanks,

Eliot


   Alan DeKok.


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

Re: [Emu] I-D Action: draft-ietf-emu-rfc7170bis-09.txt

[Eliot Lear]

[Sorry- meant to copy the WG]

Alan,

We're not quite done.  The following text needs to be removed, an 
additional example added:



If there is no Phase 2 data, then the EAP
server MUST reject the session.  There is no reason to have TEAP
devolve to EAP-TLS.


IoT devices need a way to authenticate as TEAP is EAP-TLS under nominal 
conditions.  When a certificate is about to expire, then the expectation 
is that either the client will issue a PKCS#10 request *or* the server 
will issue a request action TLV with PKCS#10, so that the client knows 
the server wants it to renew.


This text *really *has to go.

Eliot


On 31.07.23 23:06, Alan DeKok wrote:

   This version includes a typo fix from Heikki, and much extra discussion on 
resumption based on Heikki's comments at IETF 117.

   I've reviewed the text in this draft against RFC 9190 and RFC 9427.  I've 
tried to align the text as much as possible across documents.

   I've also reviewed the text in this draft against the public implementations 
of TEAP.  The text in the draft matches what the implementations do.

   Barring any updates from a final review of the GitHub issues, I think the 
document is (again) finally done.


On Jul 31, 2023, at 5:02 PM,internet-dra...@ietf.org  wrote:


A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the EAP Method Update (EMU)
WG of the IETF.

   Title   : Tunnel Extensible Authentication Protocol (TEAP) Version 1
   Author  : Alan DeKok
   Filename: draft-ietf-emu-rfc7170bis-09.txt
   Pages   : 103
   Date: 2023-07-31

Abstract:
   This document defines the Tunnel Extensible Authentication Protocol
   (TEAP) version 1.  TEAP is a tunnel-based EAP method that enables
   secure communication between a peer and a server by using the
   Transport Layer Security (TLS) protocol to establish a mutually
   authenticated tunnel.  Within the tunnel, TLV objects are used to
   convey authentication-related data between the EAP peer and the EAP
   server.  This document obsoletes RFC 7170.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-emu-rfc7170bis/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-emu-rfc7170bis-09.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-emu-rfc7170bis-09

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


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

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

[Emu] Iotdir early review of draft-ietf-ace-wg-coap-eap-08

[Eliot Lear via Datatracker]

Reviewer: Eliot Lear
Review result: On the Right Track

This draft provides a means for EAP authentication via CoAP.  This is
an evolution on top of EAPoL/EAP so as to not require 802.1X on
certain classes of devices.  The general goal of reusing existing EAP
methods – and code – is admirable.

I would like to bring several issues to the attention of the working group:

1.  There is, I think, a fundamental change between 802.1X and CoAP
that needs to be better stated: when used without a bypass (MAB),
802.1X prevents *any* IP connectivity to a network.  While Section 7.1
discusses authorization, it does not really note this aspect, and in
my opinion it should.

2.  While the draft describes out to derive an EMSK, and while the
appendices begin to talk about application, it would be good to show
at least one entire flow in which that EMSK is used by L2, and in
particular may I suggest any of the 802.15.4 specifications such as
THREAD.  A key point is that many of these technologies have their own
encryption practices, and understanding how they fit together will
make this work far more applicable.  I suggest this because it is not
clear to me how to bridge the gap.

3.  The terminology is a problem.  On the one hand, some people like
to use the terms "IoT Device" and "Controller".  In the EAP world,
this term is meaningless.  We use "peer", "authenticator", and
"authentication server".  I would suggest that those implementing this
work will be from the EAP world, and that this document will be far
more accessible to them if those terms are used.  Also, the use of
"IoT Device", while demonstrating application, limits applicability of
the work.  In the immortal words of Larry Wall, "So don't do that."

4.  The discussion about packet sizes is interesting, but too
abstract.  Some form of an example involving the use of certificates
seems in order, since the most taxing examples may involve methods
such as EAP-FAST, TEAP, and EAP-TLS.  These have been made to work
perfectly reasonably across 802.11 networks, and a reasonable question
is whether any adaption layer for smaller MTUs should occur here,
doubly so since the draft state:

   Lower layers need to provide an EAP MTU size of 1020
   octets or greater.

I realize this is a can of worms.  Certainly fellow EMU colleagues
will have had more experience at opening and managing it than I have.





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

Re: [Emu] RFC 7170 bis

[Eliot Lear]

On 03.07.23 19:08, Alan DeKok wrote:

On Jun 27, 2023, at 7:04 PM, Joseph Salowey  wrote:

We are nearing completion of RFC7170bis.   There are a few open issues in 
github - https://github.com/emu-wg/rfc7170bis/issues

Issue 21 - links to the errata to verify that they have been addressed in the draft and 
provides text for resolving the errata.  In many cases it might be easier to resolve as 
"wait for document update".  Please review to make sure the errata have been 
correctly addressed.

Issue 20 - we are waiting on some flows on PKCS #10/#7 - I think Eliot has this 
action item.
Issue 8 - is also a related item, perhaps these can be addressed together.

Issue 17 - this is a request to add mandatory to implement ciphersuites.  Some 
more discussion is needed on this.

Issue 15 - Discusses an issue with chained EAP methods and proposes that we add 
some text and a new error message to address this problem.  Do people think 
this needs addressing?

Once we resolve these issues we can move the draft forward.

   I've updated the document and will issue a new revision shortly.

   There are a few questions coming from the updates.

   RFC 3.3.1 says that TEAP should note devolve into EAP-TLS:

Further, when a client
certificate is sent outside of the TLS tunnel, the server MUST proceed
with phase 2, either for authentication or provisioning.  If there is
no Phase 2 data, then the EAP server MUST reject the session.  There
is no reason to have TEAP devolve to EAP-TLS.

   Eliot notes that you can't renew a client certificate in EAP-TLS.  Therefore, there 
may be good reason to use TEAP in "client certificate only" mode.



I'll just add that the current TEAP support in wpa_supplicant supports 
just this case.




   There is a related question is for client certificates provisions via TEAP.  
Section 3.8.1 says:

Provisioning of a peer's certificate is supported in TEAP by
performing the Simple PKI Request/Response from {{RFC5272}} using
PKCS#10 and PKCS#7 TLVs, respectively.

   That's all well and good, but there is nothing which ties that certificate 
to TEAP.

   Do we want to say that the provisioned credentials MUST NOT be used for 
anything other than TEAP?



I would suggest that we provide some guidance, but perhaps not 
normative.  The reason is that RFC 7170 states that the 
Trusted-Server-Root TLV may return a list of certs, and it may be in 
some cases to provision multiple root certificates.  That having been 
said, the text in that section is not as clear as it could be with 
regard to the purpose of those other certs.  In an enterprise 
environment, it may be broadly desirable to inform an IOT device of a 
trust anchor within the enterprise.  On the other hand, if the device is 
a collaboration device or some other human oriented system, that advice 
taken blindly may lead to exposing communications on a personal system.


In short, my suggestion is to add some text in Security Considerations, 
and some text suggesting that the primary use be for EAP authentication 
and renewal, and that other uses should be considered carefully by 
clients.  This might also lead to an EKU discussion, and that might be 
something we want to address here.


Eliot




   Alan DeKok.

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



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

Re: [Emu] RFC 7170 bis

[Eliot Lear]

On 28.06.23 01:04, Joseph Salowey wrote:
We are nearing completion of RFC7170bis.   There are a few open issues 
in github - https://github.com/emu-wg/rfc7170bis/issues


Issue 21  - links to 
the errata to verify that they have been addressed in the draft and 
provides text for resolving the errata.  In many cases it might be 
easier to resolve as "wait for document update".  Please review to 
make sure the errata have been correctly addressed.


Issue 20  - we are 
waiting on some flows on PKCS #10/#7 - I think Eliot has this action 
item.
Issue 8  - is also a 
related item, perhaps these can be addressed together.


RFC 2315 uses the term, and I take "degenerate" here to mean that the 
PKCS#7 object is not itself signed.  This is how we implemented.




OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key


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

Re: [Emu] RFC 7170 bis

[Eliot Lear]

Hi Joe,

I've sent a set of diagrams to Alan for inclusion.  They are the following:

 * An example flow in which request action is used to ask the client to
   renew a certificate.
 * An example error flow of the above
 * An example flow where only the TLS authentication is required.

Eliot

On 28.06.23 01:04, Joseph Salowey wrote:
We are nearing completion of RFC7170bis.   There are a few open issues 
in github - https://github.com/emu-wg/rfc7170bis/issues


Issue 21  - links to 
the errata to verify that they have been addressed in the draft and 
provides text for resolving the errata.  In many cases it might be 
easier to resolve as "wait for document update".  Please review to 
make sure the errata have been correctly addressed.


Issue 20  - we are 
waiting on some flows on PKCS #10/#7 - I think Eliot has this action 
item.
Issue 8  - is also a 
related item, perhaps these can be addressed together.


Issue 17  - this is a 
request to add mandatory to implement ciphersuites.  Some more 
discussion is needed on this.


Issue 15  - Discusses 
an issue with chained EAP methods and proposes that we add some text 
and a new error message to address this problem.  Do people think this 
needs addressing?


Once we resolve these issues we can move the draft forward.

Cheers,

Joe

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

[Emu] other things

[Eliot Lear]

I think I owe a second PR on handling request action TLVs, and I may 
have found a small inconsistency that we should at least discuss.  See 
next message.


Eliot

On 04.04.23 16:59, Alan DeKok wrote:

On Mar 30, 2023, at 1:06 PM, Eliot Lear  wrote:

This is one of two PRs I said I would deliver.  There is now text for CSR 
attributes in TEAP.[1]  As we discussed in the WG meeting, I have linked that 
work to the LAMPS draft on CSR Attributes.  The text essentially leverages RFC 
7030 with one modification- there is no need to based64 encode/decode.

I've also modified the appropriate table to indicate how and when it can be 
offered.  This is sort of treated as a request by the server in that table, but 
really it is an informational element. The client will be doing something 
similar for identity-type because it will be sending what would otherwise be a 
gratuitious response.  What's important for implementations is simply to note 
the values of the TLVs in each case, as now further protocol machinery is 
invoked.

Could you please review this text?

   I think it looks good.  I'll merge it in shortly.


I have also opened up one new issue.  It became clear in the meeting that we 
have an additional deficit in the draft, which is that there is no example flow 
for PKCS#10/PKCS#7 transactions.  I would like to add that flow, and so I 
opened an issue.  I am hoping to provide that text in the next week or so as 
well.

   Sounds good, thanks.

   I also need to add text on the Identity-Hint TLV.   And after that I think 
the document is pretty much done.

   Are there any other issues we need to address?  The EMU minutes aren't up 
yet, but I think that's it.

   Alan DeKok,




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

[Emu] CSR Attributes TLV and associated text now in PR#6

[Eliot Lear]

Hi everyone,

This is one of two PRs I said I would deliver.  There is now text for 
CSR attributes in TEAP.[1]  As we discussed in the WG meeting, I have 
linked that work to the LAMPS draft on CSR Attributes.  The text 
essentially leverages RFC 7030 with one modification- there is no need 
to based64 encode/decode.


I've also modified the appropriate table to indicate how and when it can 
be offered.  This is sort of treated as a request by the server in that 
table, but really it is an informational element. The client will be 
doing something similar for identity-type because it will be sending 
what would otherwise be a gratuitious response.  What's important for 
implementations is simply to note the values of the TLVs in each case, 
as now further protocol machinery is invoked.


Could you please review this text?

I have also opened up one new issue.  It became clear in the meeting 
that we have an additional deficit in the draft, which is that there is 
no example flow for PKCS#10/PKCS#7 transactions.  I would like to add 
that flow, and so I opened an issue.  I am hoping to provide that text 
in the next week or so as well.


Eliot

[1] https://github.com/emu-wg/rfc7170bis/pull/19

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

Re: [Emu] Working group Last Call for RFC 7170bis

[Eliot Lear]

On 25.03.23 14:28, Alexander Clouter wrote:

On Sat, 25 Mar 2023, at 12:03, Eliot Lear wrote:


I ask that as you consider this thread, you think beyond Basic-Auth 
to the PKCS operations.




I definitely am not qualified to think on this, I would be a fool to 
not yield to those using those attributes!


Other than your group, is anyone aware of any other implementation of 
the PKCS machinery and using it in anger?


My group is a group of partners.



Does the draft for RFC7170bis describe completely something that your 
group implemented? Does it need your proposed CSR related TLV 
attribute to be included?



The CSR helps, and is a hindrance if it's not there.  We implemented an 
earlier version of the spec in which we added a new mode to 
wpa_supplicant in which there is no intermediate result required for 
those last components, but it won't be a lot of trouble to reimplement 
based on what is in the spec.





Maybe worth bringing up is I have no idea what the language mentioned 
in https://github.com/emu-wg/rfc7170bis/issues/8 actually does to an 
implementation using these attributes; ""..in a degenerate 
Certificates Only PKCS#7 SignedData Content as defined in [RFC5652]." 
what is 'degenerate' here do or mean?



Sorry- 'degenerate case'.  There are two normal uses of TEAP in this case:

 * Just a simple EAP-TLS-like authentication (no inner eap).
 * Renewal flow (whether that's the trust anchor or the client cert or
   both).

But we should be prepared for other stuff in the future. Consider a RATS 
attestation token as an extension, for instance. That might become part 
of a regular flow.


Eliot



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

Re: [Emu] Working group Last Call for RFC 7170bis

[Eliot Lear]

I ask that as you consider this thread, you think beyond Basic-Auth to 
the PKCS operations.  Those are becoming really important to our base.


Eliot

On 25.03.23 09:52, Alexander Clouter wrote:

On Sat, 25 Mar 2023, at 01:08, Heikki Vatiainen wrote:



If you are using eapol_test prior to a few TEAP patches
(reversed EAP-FAST MSK calculation and ordering of the
Cryptobinding processing) then it should just work out the box.


I think the case in question where the inner methods were two 
Basic-Password-Auths (e.g., machine and user type). eapol_test was 
from the latest git source exactly of the reasons you mentioned.


Ahhh, we only implemented EAP-Payload and ignored Basic-Password-Auth.

RFC 7170 is from 2014. It may have been useful at that time, but is 
this still the case? Is it reasonable to implement TEAP in 2020s but 
not having EMSK supported for an inner EAP that has EMSK defined.


Conjuring up a scenario so it can be picked apart and discussed...

Is it possible to build an implementation of something like EAP-TLS 
backed by an external system (ie. TPM/hardward-offload) and the EMSK 
material are not avaliable?


RFC5247 section 1.2 has this to say about the EMSK: "...and is never 
shared with a third party." I read this to include any userspace code 
implementation (ie. Radiator, FreeRADIUS, hostapd, ...) as a 'third 
party' as section 1.5 there also labels the backend authentication 
server as a third party.


If the other end was an implementation though that does provide the 
EMSK, we would have a legitimate split.


Of course, if no one is doing this do we need to describe it? 
Otherwise could we describe it confidently? Probably not.


Just to spice things up a bit, Vendor-Specific-TLVs also can be the 
authentication method here which means they could do anything they 
want, including not providing an EMSK.


Thing is it looks like neither Cisco or Microsoft have implemented 
Vendor-Specific-TLVs in this way so one option could be to remove 
support for them for authentication and instead point to that they 
should be implemented via an vendor specific EAP method (wrapped in 
EAP-Payload-TLV).


Removing Vendor-Specific-TLVs would then leave Basic-Password-Auth as 
the oddity...which leads to other than Radiator and hostapd ("pants 
may explode and here be dragons" labelling)...has anyone else 
implemented and use in the wild Basic-Password-Auth? Microsoft only do 
EAP-{TLS,MSCHAPv2} and it looks like Cisco too from 
https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/216510-eap-chaining-with-teap.html#anc6


...maybe we can burn Basic-Password-Auth too?

At the moment there is no way anyway for Windows to push the users 
plaintext password to the server anyway, so not sure if anything 
tangible would be lost in doing this. Also provides an opportunity to 
punt people towards EAP-PWD?


TEAP can be implemented as the draft currently says. Mandatory EMSK 
would make it simpler, though.


The PAC was removed as it turned out no one implemented it, so if this 
is tweak is also something that 'empirically' continues to work then I 
would support this.



None of this is here because we want it, it is there as it looks
to be how Windows implemented things.

We haven't tried with Windows yet. Windows doesn't export EMSK for 
all methods that could support it?


You are right, it does, so we could probably just do this.

Means we could also burn the MSK CMAC if we burn Basic-Password-Auth :)

Starting to think if it ever happens that TEAPv2 is going to look very 
different to TEAPv1...



Ending up with different EMSK values

I do not understand why the EMSK calculations would be different
for the same method?

In other words, because the peer and server do not know about each 
other's EMSK capabilities, they can end up calculating different 
tracking for EMSK derived compound values. Wouldn't this be the case 
with non-mandatory EMSK support?


I see, yes, this would be problematic.

Cheers

___
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] CSR Attributes (Re: Working group Last Call for RFC 7170bis)

[Eliot Lear]

On 13.03.23 07:58, Eliot Lear wrote:



On 10.03.23 18:54, Alexander Clouter wrote:

On Fri, 10 Mar 2023, at 16:17, Eliot Lear wrote:

In Section 4.2.9, the beginning text reads:


The Request-Action TLV MAY be sent by both the peer and the server in
response to a successful or failed Result TLV.

I believe this text is overly restrictive, and should be relaxed to say:


The Request-Action TLV MAY be sent by both the peer and the server.

The reason for this is as follows: if the server notices that the client
certificate is expiring, or if the server otherwise has need of the
client renewing its certificate early (say due to impending change to
trust anchors), the server should be able to issue a Request-Action TLV
upon successful TLS hellos, without the need for a Result or
Intermediate-Result frame.

This might be awkward when implementing a state machine.
I think it may also open up a potential security problem around processing an 
Request-Action TLV in lieu of a Cryptobinding TLV.

At the moment, my expectation is:

  1. do some authenticating
  2. look at the result
  3. process some Cryptobinding TLV
  4. see if I need to do anything more (another round of authentication, 
process Request-Action TLVs, ...)


That authentication might simply be TLS for inner TLVs. Consider a 
normal machine authentication, in which certificates are simply verified.




If we make it so it can be sent at any time, being extreme, including the 
mid-EAP-Payload-TLV?

Is is valid after a successful authentication to send a lone Request-Action 
TLV? The state machine of the client is probably still pondering if the 
authentication was okay or not.

...or is this because you have just highlighted that in a Request-Action TLV 
the 'status' field takes on magical superpowers for the situation of before an 
actual Result/Intermediate-Result TLV is sent?

I do think what you are proposing is okay if the restrictions are changed to:

  * must be after an authentication


If you modify this to *"*after an authentication or with a TLS 
finish"*, *that would work.  Keep in mind, this is an informational frame.




Sorry- I mixed my replies up.  This is not simply an informational 
frame, but it still holds that a request-action should still be able to 
be sent along these lines.


Eliot


Eliot


  * for a successful authentication, a cryptobinding must be sent and processed 
first, but the value of the 'status' field of the Request-Action TLV can be 
anything
  * for a failed authentication, the Request-Action TLV 'status' field must be 
failure

I think this works for your example, and irons out some grey areas, there may 
be other scenarios though...this is all straight off the top of my head, so 
maybe I have missed something.

Cheers

___
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


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

Re: [Emu] CSR Attributes (Re: Working group Last Call for RFC 7170bis)

[Eliot Lear]

On 10.03.23 18:54, Alexander Clouter wrote:

On Fri, 10 Mar 2023, at 16:17, Eliot Lear wrote:

In Section 4.2.9, the beginning text reads:


The Request-Action TLV MAY be sent by both the peer and the server in
response to a successful or failed Result TLV.

I believe this text is overly restrictive, and should be relaxed to say:


The Request-Action TLV MAY be sent by both the peer and the server.

The reason for this is as follows: if the server notices that the client
certificate is expiring, or if the server otherwise has need of the
client renewing its certificate early (say due to impending change to
trust anchors), the server should be able to issue a Request-Action TLV
upon successful TLS hellos, without the need for a Result or
Intermediate-Result frame.

This might be awkward when implementing a state machine.

I think it may also open up a potential security problem around processing an 
Request-Action TLV in lieu of a Cryptobinding TLV.

At the moment, my expectation is:

  1. do some authenticating
  2. look at the result
  3. process some Cryptobinding TLV
  4. see if I need to do anything more (another round of authentication, 
process Request-Action TLVs, ...)


That authentication might simply be TLS for inner TLVs.  Consider a 
normal machine authentication, in which certificates are simply verified.





If we make it so it can be sent at any time, being extreme, including the 
mid-EAP-Payload-TLV?

Is is valid after a successful authentication to send a lone Request-Action 
TLV? The state machine of the client is probably still pondering if the 
authentication was okay or not.

...or is this because you have just highlighted that in a Request-Action TLV 
the 'status' field takes on magical superpowers for the situation of before an 
actual Result/Intermediate-Result TLV is sent?

I do think what you are proposing is okay if the restrictions are changed to:

  * must be after an authentication


If you modify this to *"*after an authentication or with a TLS finish"*, 
*that would work.  Keep in mind, this is an informational frame.


Eliot
**


  * for a successful authentication, a cryptobinding must be sent and processed 
first, but the value of the 'status' field of the Request-Action TLV can be 
anything
  * for a failed authentication, the Request-Action TLV 'status' field must be 
failure

I think this works for your example, and irons out some grey areas, there may 
be other scenarios though...this is all straight off the top of my head, so 
maybe I have missed something.

Cheers

___
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

[Emu] Add CSR Attributes TLV(Was: Re: Working group Last Call for RFC 7170bis)

[Eliot Lear]

This is the second issue that I'd like to address:

As discussed early in the development of this document, TEAP currently 
doesn't support a CSR Attributes TLV.  I propose that it be added, and 
that its form be the same used in EST (RFC 7030 and 
draft-ietf-lamps-rfc7030-csrattrs-01) Section 4.5.2, that the server may 
provide optionally this TLV to clients that are expected to issue 
PKCS#10 requests (the earlier in the transaction the better). The 
mandatory bit should be 0.


Eliot

On 10.03.23 16:58, Joseph Salowey wrote:
This is the working group last call for draft-ietf-emu-rfc7170bis-05 
[1].  Please review the draft and send comments to the list or open 
issues in GitHub [2].  Further discussion on the open issues will be 
considered as part of the last call. The last call ends March 24, 
2023.  The chairs would appreciate earlier reviews so we can plan to 
resolve issues during our Monday meeting on the 27th.


Thanks,

Peter and Joe
[1] https://datatracker.ietf.org/doc/draft-ietf-emu-rfc7170bis
[2] https://github.com/emu-wg/rfc7170bis/issues

___
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] request-action (Re: Working group Last Call for RFC 7170bis)

[Eliot Lear]

I'm sorry- the subject is wrong.  The IMCK derivation IS clear. This is 
related solely to Request-Action (doh!).


On 10.03.23 17:17, Eliot Lear wrote:

Hi Joe,

First and foremost, I'd like to again thank Alan for taking this on.

Second, because I expect to have a few comments, to keep them 
separate, I'll start different threads.


In Section 4.2.9, the beginning text reads:

The Request-Action TLV MAY be sent by both the peer and the server in 
response to a successful or failed Result TLV.


I believe this text is overly restrictive, and should be relaxed to say:


The Request-Action TLV MAY be sent by both the peer and the server.


The reason for this is as follows: if the server notices that the 
client certificate is expiring, or if the server otherwise has need of 
the client renewing its certificate early (say due to impending change 
to trust anchors), the server should be able to issue a Request-Action 
TLV upon successful TLS hellos, without the need for a Result or 
Intermediate-Result frame.


Thanks,

Eliot


On 10.03.23 16:58, Joseph Salowey wrote:
This is the working group last call for draft-ietf-emu-rfc7170bis-05 
[1].  Please review the draft and send comments to the list or open 
issues in GitHub [2].  Further discussion on the open issues will be 
considered as part of the last call. The last call ends March 24, 
2023.  The chairs would appreciate earlier reviews so we can plan to 
resolve issues during our Monday meeting on the 27th.


Thanks,

Peter and Joe
[1] https://datatracker.ietf.org/doc/draft-ietf-emu-rfc7170bis
[2] https://github.com/emu-wg/rfc7170bis/issues

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


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



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

[Emu] IMCK derivation for PKCS ops still not clear (Re: Working group Last Call for RFC 7170bis)

[Eliot Lear]

Hi Joe,

First and foremost, I'd like to again thank Alan for taking this on.

Second, because I expect to have a few comments, to keep them separate, 
I'll start different threads.


In Section 4.2.9, the beginning text reads:

The Request-Action TLV MAY be sent by both the peer and the server in 
response to a successful or failed Result TLV.


I believe this text is overly restrictive, and should be relaxed to say:


The Request-Action TLV MAY be sent by both the peer and the server.


The reason for this is as follows: if the server notices that the client 
certificate is expiring, or if the server otherwise has need of the 
client renewing its certificate early (say due to impending change to 
trust anchors), the server should be able to issue a Request-Action TLV 
upon successful TLS hellos, without the need for a Result or 
Intermediate-Result frame.


Thanks,

Eliot


On 10.03.23 16:58, Joseph Salowey wrote:
This is the working group last call for draft-ietf-emu-rfc7170bis-05 
[1].  Please review the draft and send comments to the list or open 
issues in GitHub [2].  Further discussion on the open issues will be 
considered as part of the last call. The last call ends March 24, 
2023.  The chairs would appreciate earlier reviews so we can plan to 
resolve issues during our Monday meeting on the 27th.


Thanks,

Peter and Joe
[1] https://datatracker.ietf.org/doc/draft-ietf-emu-rfc7170bis
[2] https://github.com/emu-wg/rfc7170bis/issues

___
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] RFC7170bis and lack of identities

[Eliot Lear]

On 04.02.23 08:57, Alexander Clouter wrote:

I agree on both points, Result TLV should be final and is easy to explain to 
others.


It may be easy, but I don't think it's quite right.

To me, the way to look at this is that when a Result TLV is transmitted 
by the server, it is a signal that the server has no more requirements 
of the peer, and if it is transmitted by the peer, then it is a signal 
that the peer has no more requirements of the server.


So it is possible that there is more work to do if one side isn't 
finished.  And this is important to recognize because Result-TLVs can be 
piggybacked on Intermediate-Result-TLVs, if we believe C.3 in 7170.  
Also, see C.9.


In particular, because either side may send a Request-Action frame, one 
side may not know when it REALLY is finished. EAP-Success an only occur 
when the server has sent its last Result TLV and has seen the client's 
Result TLV.  And the client can only expect a completed state when the 
server has sent a Result TLV and the client has not sent anything after 
its last Result TLV.


So for example, if a server has no demands of a client in normal 
operating state, it might immediately send (under our current draft) an 
Intermediate-Result with CB Request and Result.  But then the peer sends 
back a PKCS#10 request because it wants to renew its cert earlier than 
the server may want it to.  The server will need to send another Result 
TLV eventually.


I don't think that behavior should be proscribed.

Eliot




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

Re: [Emu] Request-Action Frame only in response to successful or failed Result-TLV?

[Eliot Lear]

Sorry- I misread this text.  But I think the text still needs changing 
for the reasons given below.


Eliot

On 02.02.23 08:26, Eliot Lear wrote:


Section 4.2.9 reads:


   The Request-Action TLV MAY be sent by both the peer and the server in
   response to a successful or failed Result TLV.


I suggest that this text be changed to allow a Request-Action TLV to 
be sent at any time.  The reasoning for this is that even with a 
successful TLS exchange, the *server* may decide that the client needs 
a new certificate.  That may be due to many factors, including trust 
anchor changes or some sort of compromise condition.


Since nobody previously implemented the PKCS#10/PKCS#7 TLVs, this 
shouldn't cause interoperability problems with earlier configs.


Eliot


___
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] Request-Action Frame only in response to failed Result-TLV?

[Eliot Lear]

Section 4.2.9 reads:


   The Request-Action TLV MAY be sent by both the peer and the server in
   response to a successful or failed Result TLV.


I suggest that this text be changed to allow a Request-Action TLV to be 
sent at any time.  The reasoning for this is that even with a successful 
TLS exchange, the *server* may decide that the client needs a new 
certificate.  That may be due to many factors, including trust anchor 
changes or some sort of compromise condition.


Since nobody previously implemented the PKCS#10/PKCS#7 TLVs, this 
shouldn't cause interoperability problems with earlier configs.


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

Re: [Emu] RFC7170bis and lack of identities

[Eliot Lear]

I am wondering if we should close this issue.  At the end of the day, if 
the client knows it's doing something like 2FA that requires an EAP 
method, *it* can initiate.  If it doesn't and the server decides it 
needs it based on the Basic-Password-Auth-Resp, then the server can 
insist, using a Request-Action TLV that requests EAP.


I could be convinced otherwise, tho.

Eliot



On 01.02.23 21:42, Alan DeKok wrote:

   I've opened an issue:https://github.com/emu-wg/rfc7170bis/issues/14  , 
summarized as:

When using normal EAP, the server sees the EAP Identity before it selects which 
EAP type is being used.

However, with TEAP, the inner tunnel method (EAP or basic password) has to be 
chosen by the server before it sees any user identity. This limitation means 
that it is impossible for the server to divide users into groups, as with:

• users matching X get basic password auth
• all other users get EAP
Perhaps we have to define an Identity-Hint TLV which is sent by the peer as 
soon as the inner tunnel is established? The server can then use this hint to 
select which authentication method to use.


   i.e .when the EAP authenticator receives TEAP, it has no idea whether to pick EAP or 
basic password.  It just has to pick one randomly, and hope for the best.  If it picks 
the wrong one, then there are "extra" rounds of authentication, or users might 
not get authenticated.

   In practice, this likely means that TEAP implementations will either do 
password authentication all of the time, or EAP authentication all of the time. 
 But not both on the same server.

   At the minimum, this issue should be discussed in the document, with a warning of 
"here be dragons".

   If we're willing to extend TEAP, I don't think we need to rev the protocol.  
We could just add an optional Identity-Hint TLV which is sent by the supplicant 
as soon as the inner tunnel is established.

   If the server sees the TLV, it can use it.  Otherwise, it's an optional TLV, 
and the server is free to ignore it.

   I think this is almost the last open issue.  It would help to get feedback 
from people currently using TEAP, to see if (a) this is a real problem, or (b) 
it's fine and we can ignore it.

   Alan DeKok.

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

Re: [Emu] draft-ietf-emu-rfc7170bis-03.txt and password length

[Eliot Lear]

Hiya,


On 27.01.23 12:17, Heikki Vatiainen wrote:

For example, an OTP system could do this:
- Start authentication with username + static password; if ok then
- Server prompts for the next method: Choose 1 for push to mobile app,
2 for telephone callback, 3 for emergency use pre-printed code. Leave
password empty for the default method (not mandatory: can always
choose one of 1-3).
- The next server response then depends on what was chosen by the user

The above may need to run as one exchange without any
Intermediate-Result TLV between static password and OTP dialogue
because it gets proxied as Radius PAP to "Inner Method server" as
described in section 2.1 of the draft


Hold the phone on this.  That's *not* how Jouni's code works, and that's 
*not* what we just agreed to on the calls.  Jouni's code has something 
of a filler intermediate-result and CB, and we just agreed that 
everything should have that.  Now, I am still not a fan of that 
decision, but it's what we decided. Do we need to revisit?


Eliot

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

Re: [Emu] draft-ietf-emu-rfc7170bis-03.txt and password length

[Eliot Lear]

In thinking about this flow, the real issue boils down to this:

If the user is going to use 2FA, then the peer needs to know in 
advance.  If the peer tries to use Basic Auth and server won't accept 
it, it should simply produce an error.  That's the simplifying flow.


If the peer doesn't know that 2FA is to be used, then the mechanics of 
all of this become a mess.


Eliot

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

Re: [Emu] draft-ietf-emu-rfc7170bis-03.txt and password length

[Eliot Lear]

First, I agree that this is a nit.

On 25.01.23 14:54, Alan DeKok wrote:

On Jan 25, 2023, at 8:27 AM, Eliot Lear  wrote:

No negotiation required.  It gets the username as part of basic auth, sees the 
name and then makes a decision to initiate a new inner method.

   It has to finish the current method first.  i.e. the server only gets the username 
after sending a Basic-Password-Auth-Req TLV.  The response contains a username 
&& password.


Sure, but 7170 doesn't say you can't have a null password.  So it can 
finish the current method and then decide to add another by sending a 
request-action TLV (a corner case to be sure).  Or it can reject the 
null password.


We could also say, “don't try that or we'll send the protocol police 
after you” ;-)


Eliot

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

Re: [Emu] draft-ietf-emu-rfc7170bis-03.txt and password length

[Eliot Lear]

On 25.01.23 14:22, Alan DeKok wrote:


   What I'm not clear on is how they would negotiate a special username which 
triggers a new auth, but without doing a password check.  That seems odd to me.


No negotiation required.  It gets the username as part of basic auth, 
sees the name and then makes a decision to initiate a new inner method.  
Imagine two groups of usernames on a server: one that use basic auth and 
another that has 2FA, where the 2FA is invoked in an EAP method.  This 
may not be the BEST method (you could probably think of better), but 
TEAP doesn't say you can't do it (perhaps we're here because TEAP 
doesn't forbid enough stuff ;-)


Eliot

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

Re: [Emu] draft-ietf-emu-rfc7170bis-03.txt and password length

[Eliot Lear]

On 25.01.23 09:21, John Mattsson wrote:


That sounds good. Would be good to have text stating that passwords of 
length 255 characters (the current max) shall be allowed. Requiring a 
minimum length of 8 or a least 6 characters would be good.


If you want to add some implementation guidance I think that's fine, but 
this isn't really a protocol consideration.  I could envision the 
following circumstance, by the way: a username triggers the server to 
initiate a new inner method, and the password is not sent, knowing 
this.  Or the password is ignored.


Eliot




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

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

[Eliot Lear]

On 09.01.23 23:36, Alan DeKok wrote:

   How about:

The order in TLVs are encoded in a TEAP packet does not
matter, however there is an order in which TLVs must be processed:

1. Crypto-Binding-TLV
2. Intermediate-Result-TLV
3. Result-TLV
4. Identity-Type TLV
5. EAP-Payload TLV[Identity-Request] or Basic-Password-Auth-Req TLV

That is, cryptographic binding is checked before any result is used,
and identities are checked before proposing authentication methods, as the
identity may influence the chosen authentication method.


You've left out the other TLVs, but I think most fit in (5).  We need to 
consider what happens in the case of a request-action TLV.


Eliot

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

[Emu] Meta Issue (Re: I-D Action: draft-ietf-emu-rfc7170bis-02.txt)

[Eliot Lear]

My suggestion is that this draft not be moved to WGLC until we have 
working code in hostap for it.  Even better if FR and ISE also match and 
can test against MSFT.


Eliot

On 09.01.23 08:43, Alexander Clouter wrote:

On Thu, 5 Jan 2023, at 20:13, internet-dra...@ietf.org wrote:

   Title   : Tunnel Extensible Authentication Protocol (TEAP) Version 1
   Filename: draft-ietf-emu-rfc7170bis-02.txt
   Pages   : 101
   Date: 2023-01-05

Abstract:

obseletes -> obsoletes

Section 1.1 - Specification Requirements

'RFC2119'/'RFC8174' do they need to be turned into links like the other 
references?

Section 2 - Protocol Overview

"...the master secret for the session. If TEAP [LINE BREAK] Phase 2 is used to 
distribute..." - line break mid sentence

Section 2.2 - Protocol-Layering Model

We can take the opportunity to amend the layering diagram to be more lopsided 
to highlight that the outer-TLVs are on the 'outside' of the TLS jacket:

  +--+
  | Inner EAP Method | Other TLV information |
  |--|
  | TLV Encapsulation (TLVs) |
  |--+-+
  |  TLS | Optional Outer TLVs |
  ||
  |TEAP|
  ||
  |EAP |
  ||
  | Carrier Protocol (EAP over LAN, RADIUS, Diameter, etc.)|
  ++

Section 3.2 - TEAP Authentication Phase 1: Tunnel Establishment

"man-in-the- middle" - stray space; due to markdown-to-HTML as it breaks over a 
newline

"...server's identity that may be useful in helping the [LINE BREAK] peer select the 
appropriate credential..." - line break mid sentence

Section 3.3.1 - EAP Sequences

* "Upon completion of each EAP method in the tunnel, the server MUST send an 
Intermediate-Result TLV indicating the result of the inner EAP method. The peer MUST 
respond to the Intermediate-Result TLV indicating its result. If the result indicates 
success, the Intermediate-Result TLV MUST be accompanied by a Crypto-Binding TLV."

This could be interpreted as the peer sends the Crypto-Binding TLV (without 
reading further) and not the server. Can we amend this to something more front 
loaded such as:

"Upon completion of each EAP method in the tunnel, the server MUST send an 
Intermediate-Result TLV indicating the result of the inner EAP method. When the result 
indicates success it MUST be accompanied by a Crypto-Binding TLV. The peer MUST respond 
to the Intermediate-Result TLV indicating its own result and similarly on success MUST 
accompany the TLV with it's own Crypto-Binding TLV."

Section 3.5 - TEAP Session Identifier

The definition probably should be in a code block like the other definitions.

Section 3.7 - Fragmentation

I think this section should be removed as it adds nothing over RFC5216 section 
2.1.5 (EAP Fragmentation) and doing a word diff it is mostly just word smithing 
changes that (at least for me) does nothing to improve understanding.

If we want to keep it to minimise changes to RFC7170, I suggest we just truncate the 
section and state "go read RFC5216 section 2.1.5".

Section 3.8 - Peer Services

"Alternatively, peer services can be used if an inner EAP method providing mutual 
authentication and an Extended Master Session Key (EMSK) is executed and cryptographic 
binding with the EMSK Compound Message Authentication Code (MAC) is correctly 
validated."

This can be read as if you can only do an unauthenticated server provisioning 
if the inner method provides an EMSK; note that EAP-(FAST)-MSCHAPv2 only 
provides an MSK.

RFC5422 section 3.2.2 (EAP-FAST unauthenticated provisioning) states only 
EAP-FAST-MSCHAPv2 can be used for this. For RFC7170 are we allowed to use 
EAP-FAST-MSCHAPv2 for this?

RFC7170 does not describe what is forbidden, and section 3.8.3 (Server 
Unauthenticated Provisioning Mode) does not say you cannot use an MSK (even a 
'zero' based one).

I suggest to reword this section to state (we we are allowed to use a non-zero 
MSK):

"Alternatively, peer services can be used if an inner EAP method providing mutual 
authentication and an Master Session Key (MSK) and/or Extended Master Session Key (EMSK) 
that is executed and cryptographic binding with the Compound Message Authentication Code 
(MAC) which is correctly validated."

Section 3.8.1 - PAC Provisioning

"The peer MUST send separate PAC TLVs for each type of PAC it wants to be 
provisioned. Multiple PAC TLVs can be sent in the same packet or in different packets. 
The EAP server will send the PACs after its internal policy 

[Emu] RFC 7170bis Issue 4: do we want to keep PAC/PAC-Ackonwledgment?

[Eliot Lear]

We have discussed not adding a lot into TEAP, but it might be good to 
consider removing some stuff. PAC tops the list of things I'd like to 
see removed.  This is relevant to Erratum 5844 in that the example given 
contains a PAC/PAC-Acknowledgment.  This also, has bearing on whether or 
not we bump the TEAP version.


Eliot

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

[Emu] RFC 7170bis: More small potatoes: use Obsoletes

[Eliot Lear]

This document is a complete specification, and as such should obsolete 
RFC 7170 (if approved).


Eliot

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

[Emu] RFC 7170bis: Small potatoes: IANA registry

[Eliot Lear]

This is almost editorial.

The TLV registry and the various registrations should now be pointed to 
*this* document as the authority rather than RFC 7170, and we should 
retain the registration policy statement for TLVs here. Frankly, 
specification required is just a little thin. We probably should provide 
a template. We should also leave a tombstone to indicate how the 
registries were formed.


I've opened GH issue 1 on this: 
https://github.com/emu-wg/rfc7170bis/issues/1


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

Re: [Emu] TEAP erratum 5775

[Eliot Lear]

Hi Alexander,

On 03.01.23 14:40, Alexander Clouter wrote:

On Tue, 3 Jan 2023, at 08:20, Eliot Lear wrote:


My use case is IOT.  I'm interested in two states:

  * Nominal: everything looks very similar to EAP-TLS.
  * Exceptional: a new certificate or a new trust anchor or something
else is needed.  In which case, I would expect the server to push
a “request action” TLV.

In either case, there is no inner method.  So either the calculation 
should not assume S-IMCK[0] exists, or we must define what that means.




I think for your use case to send a Request-Action-TLV the server must 
have also sent the Result-TLV and Cryptobinding-TLV:


https://datatracker.ietf.org/doc/html/draft-ietf-emu-rfc7170bis-01#section-3.3.4
https://datatracker.ietf.org/doc/html/draft-ietf-emu-rfc7170bis-01#section-4.2.9
https://datatracker.ietf.org/doc/html/draft-ietf-emu-rfc7170bis-01#name-c9-peer-requests-inner-meth 
- shows TLS completing and then just a bare Cryptobinding-TLV and 
Result-TLV so I figure nothing prevents slipping 
your Request-Action-TLV in there too



Yes, and...




My expectation is that you use the EMSK from the outer-TLS 
authentication to do this calculation.


However, I now understand your point about the *value* of doing this. 
Generating a Cryptobinding on the outer-TLS authentication does not 
protect the inner Request-Action-TLV.


Yes.  The purpose of a crypto binding is to bind one *identity* to 
another.  The place where that *might* be necessary is when 
PKCS#10/PKCS#7 exchanges are made, where the RA/CA can prove that the 
enrollee is the same as the EAP peer (and visa versa). What's important 
is that the CA not be duped into issuing a certificate to an 
intermediary.  But RFC 7170 Section 3.8.2 seems to cover that 
independent of CB.


What am I missing?

Eliot


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

Re: [Emu] TEAP erratum 5775

[Eliot Lear]

Hi Alexander!

Zooming down:

On 02.01.23 12:10, Alexander Clouter wrote:

Fewer conditionals/branching points in implementations?

At the moment the rule is "start with S-IMCK[0]" and then both:
 * mix in MSK goodness and track that progression
 * mix in EMSK goodness and track that progression

If we ignore that the RFC should have stated MSK/EMSK needs to be 
handled separately for IMSK/IMCK purposes, this is mostly straight 
forward.


My use case is IOT.  I'm interested in two states:

 * Nominal: everything looks very similar to EAP-TLS.
 * Exceptional: a new certificate or a new trust anchor or something
   else is needed.  In which case, I would expect the server to push a
   “request action” TLV.

In either case, there is no inner method.  So either the calculation 
should not assume S-IMCK[0] exists, or we must define what that means.  
Currently in our POC implementation we are following Jouni's example 
that he used for basic auth.  What I am concerned about is leading 
implementors or their users to believe that an operation provides any 
additional security when would does not.  So at the very least, we 
should be considering what to put in Security Considerations about this, 
but i the op really provides not value, we should consider the resource 
consumption of the operation against the code complexity.


Regards,

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

Re: [Emu] Adoption call for RFC 7170bis

[Eliot Lear]

Hi Alan,

On 22.12.22 23:45, Alan DeKok wrote:

   So I'd like to know what would be in TEAPv2, and what issues there would be if we just 
documented TEAPv1 "as implemented".


I don't see TEAPv2 as much more than functioning TEAPv1.  But if there 
are people out there who have a functioning TEAPv1, and we have tested 
against other vendors, we will hear from ALL of them if we break 
something.  That is- I don't want your document to be much longer than 
it already is.


Eliot

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

Re: [Emu] Adoption call for RFC 7170bis

[Eliot Lear]

Alan,

I view this differently.  First, we don't have good deployment numbers 
for TEAP.   If we bump the version and nobody is using TEAP, then nobody 
will care.  If we don't bump the version and people ARE using TEAP, 
we'll get to hear from everyone who cares! From a code standpoint, I 
imagine that the incompabitibilies will be small in number, and so we're 
talking about a handful of conditionals.


Eliot

On 22.12.22 15:43, Alan DeKok wrote:

On Dec 22, 2022, at 9:36 AM, Oleg Pekar  wrote:

I would like to provide comments as well. We should also bump the version of 
the protocol so as not to harm the existing implementations (yes, they 
implemented the spec with filed errata, the spec is sometimes ambiguous but 
those implementations are already on the market).

   What we have is a situation where no one has implemented RFC 7170, and there is no practical 
path to implementing it.  As a result, the -bis revision is documenting the implementations.  i.e. 
"this is what's going on" versus "what should be going on".

   It would be more relevant to update the version when there are incompatible 
changes to the protocol, *and* existing implementations which need to know 
which version they're negotiating.

   Since there is only one "TEAP version 1", I would argue that there's no need 
to change the version.

   Plus, if we change the version, then people have no idea what's currently 
implemented.  TEAP version 1 becomes an undocumented mess of unknowns.

   As an implementor, I'm happy to declare RFC 7170 as irrelevant, and to issue a new 
standard which defines TEAP version 1 "as implemented".

   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

[Emu] TEAP erratum 5844: intermediate response TLV for basic authentication?

[Eliot Lear]

This erratum can be found at 
https://www.rfc-editor.org/errata_search.php?rfc=7170=5844. I 
propose that this erratum be verified as written.  For a newer version 
of TEAP we might want to review this.


Eliot

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

[Emu] TEAP erratum 5775

[Eliot Lear]

Hi,

I am reviewing the errata on GitHub and would like to close on them.  
The first one I am addressing is 5775, which can be found on the RFC 
Editor page at https://www.rfc-editor.org/errata/eid5775.  Joe's 
proposed fix can be viewed at 
https://github.com/emu-wg/teap-errata/commit/6fdcc5b155b8b844c4b9e2e24cddf8701a309424.


Th proposed change is as follows:



4.2.13. Crypto-Binding TLV

The Crypto-Binding TLV is used to prove that both the peer and server 
participated in the tunnel establishment and sequence of 
authentications. It also provides verification of the TEAP type, 
version negotiated, and Outer TLVs exchanged before the TLS tunnel 
establishment.


The Crypto-Binding TLV MUST be exchanged and verified before the final 
Result TLV exchange, regardless of whether there is an inner EAP 
method authentication or not. It MUST be included with the 
Intermediate-Result TLV to perform cryptographic binding after each 
successful EAP method in a sequence of EAP methods, before proceeding 
with another inner EAP methodeach successful Intermediate-Result TLV 
to perform cryptographic binding after each EAP authenticaiton or 
basic password method, before proceeding with another authentication 
exchange. If no MSK or EMSK has been generated and a Crypto-Binding 
TLS is required then the MSK Compound MAC field contains the MAC using 
keys generated according to section 5.2. The Crypto-Binding TLV is 
valid only if the following checks pass:



I think we need to back up and review the three cases that we have:

1. There is an inner method.  This means there is no issue (yay!).
2. No inner method but authentication.
3. No inner method and just TLVs.

What value is crypto-binding offering in the latter two cases? I'm not 
sure I see any.  If that is the case, then we should suppress the 
crypto-binding TLV with the result TLV.  This would surely break 
existing TEAP implementations, and would require a version bump.  In 
this case, with regard to the erratum, we would HOLD FOR UPDATE.


If there is any value, then is simply zeroing the field seems wrong.  
Section 5.3 talks about the BUFFER being created from outer TLV 
information.  But outer TLVs are not protected.  Thus anyone can 
calculate this with zero'd fields.  This means we may wish to use TLS 
seed information.  But again, I'm not sure I see value here.


If we choose to zero the field as is suggested in Section 5.2, then I 
suggest we just say that in the text rather than referring to the 
entirety of Section 5.2.  In this case we could VERIFY the erratum.


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

Re: [Emu] [EXTERNAL] Re: More TEAP issues

[Eliot Lear]

No, but I would ask that we still have an interim to close the errata.

Eliot

On 01.12.22 06:22, Joseph Salowey wrote:
It sounds like we are gaining consensus to create a revision of TEAP.  
The emphasis would be (in priority order):


  * Aligning specification with current implementations
  * Clarifying the existing specification
  * Adding missing TLVs to make existing use cases work better

The goal is to get this revision done quickly to prevent further 
implementation divergence.  Changes will need to go through the 
working group process. Errata should be addressed when 
relevant portions of the document are updated.


Does anyone object to this approach?

Thanks,

Joe and Peter

On Wed, Nov 30, 2022 at 12:48 PM Bruno Pereira Vidal 
 wrote:


I also think option 3 is the preferred one at this point, given
the interoperable implementations that have already shipped. In
addition to Cisco ISE, the Windows TEAP implementation has also
been validated against Aruba ClearPass.

The person who implemented the Windows client code is no longer at
Microsoft and, unfortunately, I don't recall why this ended up
being implemented like this. It is likely that it was
inadvertently inherited from EAP-FAST as mentioned below.

Thanks,
Bruno

-Original Message-
From: Emu  On Behalf Of Jouni Malinen
Sent: Wednesday, November 30, 2022 10:33 AM
To: Alexander Clouter mailto:alex%2bi...@coremem.com>>
Cc: EMU WG 
Subject: [EXTERNAL] Re: [Emu] More TEAP issues

On Wed, Nov 30, 2022 at 03:01:08PM +, Alexander Clouter wrote:
> On Tue, 29 Nov 2022, at 22:34, Alan DeKok wrote:
> > Based on interoperability testing, it looks like implementations
> > followed EAP-FAST for derivation of the MS-MPPE keys, and not
RFC 7170:

> EAP-FAST almost does not document this until you look at a
latter RFC covering the provisioning component:
>
>
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> rfc-editor.org

%2Frfc%2Frfc5422%23section-3.2.3=05%7C01%7CBruno.Vi
> dal%40microsoft.com
%7C0e1894aabf524f8c70d708dad30154ed%7C72f988bf86f14
>
1af91ab2d7cd011db47%7C1%7C0%7C638054299953760498%7CUnknown%7CTWFpbGZsb
>
3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
>
7C3000%7C%7C%7C=PqpDLwSPz0sh%2BsSlXadTZCAWI2835mdqgZvR2jN1Vgw%3D
> =0

And that section has a history of its own.. If you take a look at
the latest draft (-10), that language is not there, i.e., it got
added quite late in the process and the related discussions were
not exactly considering this positively. If I remember correctly,
this mismatch with how EAP-MSCHAPv2 was defined was seen as
something that should not really have been done and the
EAP-FAST-MSCHAPv2 was named such to be distinguished from
EAP-MSCHAPv2 and also as a reminder not to use this variant for
anything else than EAP-FAST (which had already been deployed with
it). Nevertheless, here we are 15 years later hitting this exact
same thing with TEAP having been deployed with the design that was
not supposed to be repeated..

> Really easy to miss for an implementer, especially as when you
start implementing FAST (or TEAP) you begin with authentication
and think you can ignore the PAC component at first.

While I started working on TEAP implementation by copying FAST
implementation to be the starting point, one of my first steps was
to try to remove all the hacks needed to get EAP-FAST
interoperable since I was familiar with the history.. But yes, it
would be next to impossible to implement either EAP-FAST or
EAP-TEAP based on just the RFCs and get to something that
interoperates with anything already deployed.

> The other biggy is that it is easy to miss that for each EAP
method in a sequence, you need to include an EAP Identity response
along with the Identity-Type TLV to the peer.

And that will hopefully not include another instance of
Crypto-Binding for the EAP-Identity exchange. This is related to
one of my errata comments on EAP method vs. EAP authentication
method (the latter needs crypto binding; the former probably does
not, but RFC 7170 is not clear).

> > 3) declare 7170  irretrievably broken, and write 7170bis which
> > documents how TEAP version 1 operates in practice.
>
> This is my preference too.

While this might not result in the cleanest protocol design, I'd
agree that this is likely the best approach from the view point of
getting something useful out there and into wider use.


Regarding a separate comment about new TLVs (and new functionality
in general, I'd guess), I have no significant issues including
that in a new RFC, but I do hope that the initial focus would be
in addressing the 

Re: [Emu] More TEAP issues

[Eliot Lear]

I'd support a revision as well.  See below:

On 30.11.22 02:14, Joseph Salowey wrote:
[Joe] speaking as a participant, I'd be happy to assist with a 
revision.  I think it is needed.  Most of the current errata are 
tracked here - https://github.com/emu-wg/teap-errata/pulls. I think 
the target would be to obsolete 7170 with a revision that just fixes 
the errata and makes any needed clarifications.  We can also work on 
posting the Errata, but the revised document would be more effective 
at getting these issues fixed.


I'd also like to take some time to consider what additional TLVs may be 
required.  Right now there is an incongruence between TEAP and other 
protocols that sign certs in that there is no CSR attributes TLV.  There 
may be several others to consider.


Eliot

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

Re: [Emu] TEAP time again: Result and Intermediate and crypto binding TLVs with no inner EAP methods

[Eliot Lear]

On 07.10.22 22:46, Alan DeKok wrote:

On Oct 5, 2022, at 12:44 PM, Eliot Lear  wrote:

DR need clarity on how crypto-binding TLVs when there is no inner EAP 
method.  Also note the use of request-action.

Key questions: what value to pass for EMSK and MSK in crypto binding response 
when there is no inner method?  Zeros?

Also, can the flags indicate that there is no EMSK or MSK?  This would solve 
our first problem.

   Both approaches seem reasonable.


Hmm.  A 7/10 split!  The question: what's the best answer?




Finally, are we cool piggybacking Result and Crypto-binding on a PKCS#7 TLV?

Flows follow:
Use case 1:

Device just wants to use TEAP in the same way one would use EAP-TLS.  This would be what 
I would call "normal operations".  That is, we would expect something along the 
following lines:

   What additions are there from EAP-TLS?  Provisioning?


In this case, there are ZERO additions to EAP-TLS.  The behavior is the 
same.  However, the reason the client shouldn't use EAP-TLS is that the 
server *might* send a request-action TLV, or *might* send a new trust 
anchor update or some other as-of-yet-to-be-specified TLV.


In the second use case, indeed it's provisioning when the server *does* 
do one of those things or when the peer itself sends a PKCS#10 TLV.


Eliot



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

[Emu] TEAP no EAP: which "error" for EAP methods that are not available?

[Eliot Lear]

DR what to do when peer doesn't want to do an inner EAP method, but 
you still want to allow peer on the network?  My answer: 
intermediate-result TLV with status=failure.


One potential use case is when you have some devices that support 
individual users and some that do not.  In this case, the server might 
request an inner EAP method such as MSCHAPv2.  This would work fine for 
a laptop but not so well for a lightbulb.  The server may yet wish to 
make a policy decision to allow the lightbulb onto the network, even 
though it made use of no inner method.  RFC 7170 ponders this use case 
in Section 3.3.1:


   The result of failure of an EAP method does not
   always imply a failure of the overall authentication.  If one
   authentication method fails, the server may attempt to authenticate
   the peer with a different method.

What is less clear is what to do when no EAP method is available.  There 
are three choices:


1. Send a NAK TLV
2. Send an Error TLV
3. Send an intermediate result TLV with status = failure.

A NAK TLV seems to contemplate TLVs that are simply *not* implemented.  
I don't think that's the correct answer, but so long as the server 
understands that the peer means "don't send me no stinking EAP TLVs" and 
can intelligently apply policy, no big deal.  Still, I think that's not 
a good general answer.  It's possible that both the peer and the server 
could implement something like EAP-AKA, but that the server doesn't have 
access to the necessary credential information of the client, and may 
still want to allow the client online.


Section 3.6.3 states the following about using an Error TLV with an 
inner method:


   If there is a non-fatal error handling the inner method,
   instead of silently dropping the inner method request or response and
   not responding, the receiving side SHOULD use an Error TLV with error
   code Inner Method Error to indicate an error processing the current
   inner method.  The side receiving the Error TLV MAY decide to start a
   new inner method instead or send back a Result TLV to terminate the
   TEAP authentication session.

But this seems to be applicable when the inner method is already 
started.  Also, this seems to stretch the definition of what an "Error" 
is.  That militates against the SHOULD above, right?


Finally, the peer could simply respond with an Intermediate-Result-TLV 
with Status=Failure.  This seems to be the most straightforward way of 
responding, and it seems to be what was intended with the text I quoted 
from Section 3.3.1.  One might want to provide the EAP TLV as an 
optional TLV in the Intermediate-Result, but one seemingly cannot 
because because the Intermediate-TLV text reads the following in Section 
4.2.11:


  The TLVs in
  this field MUST NOT have the mandatory bit set.

I don't understand this, but there it is.  It spares me having to 
determine whether one is supposed to include just the TLV code in that 
space or the T, L, and V.  And this same question recurs with 
Request-Action TLVs.  Fortunately, in that context it makes more sense 
that only the type code is necessary, and this is indeed the practice 
that wpa_supplicant has followed.


If it seems to you like we're building up a little bit of an issue list 
for a TEAP update you'd be right ;-)


Eliot



OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key


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

Re: [Emu] TEAP time again: Result and Intermediate and crypto binding TLVs with no inner EAP methods

[Eliot Lear]

There seems to have been a bad edit on my previous message on the 2nd 
flow.  See below.


On 05.10.22 18:42, Eliot Lear wrote:


Hi everyone,

Picking up on some TEAP work again.

DR need clarity on how crypto-binding TLVs when there is no inner 
EAP method.  Also note the use of request-action.


Key questions: what value to pass for EMSK and MSK in crypto binding 
response when there is no inner method?  Zeros?


Also, can the flags indicate that there is no EMSK or MSK? This would 
solve our first problem.


Finally, are we cool piggybacking Result and Crypto-binding on a 
PKCS#7 TLV?


Flows follow:

Use case 1:

Device just wants to use TEAP in the same way one would use EAP-TLS.  
This would be what I would call "normal operations". That is, we would 
expect something along the following lines:


  ,.,--.
  |Peer||Server|
  `-+--'`--+---'
|1 EAP-Request/|
|Identity  |
| <-
|  |
|2 EAP-Response/   |
|Type=Identity |
| ->
|  |
 ,!.
 |Section 3.2 |_\
 `--'
|   3 EAP-Request/ |
|   Type=TEAP, |
|   TEAP Start,|
|   Authority-ID TLV   |
| <-
|  |
|   4 EAP-Response/|
|   Type=TEAP, |
|   TLS(ClientHello)   |
| ->
|  |
|  5 EAP-Request/  |
|  Type=TEAP,  |
|  TLS(ServerHello,|
|  ServerKeyExchange,  |
|  ServerHelloDone)|
| <-
|  |
|  6 EAP-Response/ |
|  Type=TEAP,  |
|  ClientKeyExchange,  |
|  CertificateVerify,  |
|  ChangeCipherSpec,   |
|  Finished)   |
| ->
|  |
 ,!.
 |Section 3.3.3   |_\
 `--'
| 7 EAP-Request/   |
| Type=TEAP,   |
| TLS(ChangeCipherSpec,|
| Finished),   |
| Result TLV,  |
| Crypto-Binding TLV   |
| <-
|  |
|  8 EAP-Response/ |
|  Type=TEAP,  |
|  Result TLV, |
|  Crypto-Binding TLV  |
| ->
|  |
| 9 EAP-Success|
| <-
  ,-+--.,--+---.
  |Peer||Server|
  `'`--'

Note the lack of an Intermediate Result TLV, because the text states 
that Intermediate Results are only required upon completion of an 
inner EAP method.


The second use case involves the use of PKCS#10/PKCS#7 messages.  We 
think that looks like this:



  ,. ,--.  ,--.
  |Peer| |Server|  |CA|
  `-+--' `--+---'  `+-'
|EAP-Request/   |   |
|Identity   |   |
| <--   |
|   |   |
|   EAP-Response/   |   |
|   Type=Identity   |   |
| -->   |
|   |   |
|  EAP-Request/ |   |
|  Type=TEAP,   |   |
|  TEAP Start,  |   |
|  Authority-ID TLV |   |
| <--   |
|   |   |
|  EAP-Response/|   |
|  Type=TEAP,   |   |
|  TLS(ClientHello) |   |
| -->   |
|   | 

[Emu] TEAP time again: Result and Intermediate and crypto binding TLVs with no inner EAP methods

[Eliot Lear]

Hi everyone,

Picking up on some TEAP work again.

DR need clarity on how crypto-binding TLVs when there is no inner 
EAP method.  Also note the use of request-action.


Key questions: what value to pass for EMSK and MSK in crypto binding 
response when there is no inner method?  Zeros?


Also, can the flags indicate that there is no EMSK or MSK?  This would 
solve our first problem.


Finally, are we cool piggybacking Result and Crypto-binding on a PKCS#7 TLV?

Flows follow:

Use case 1:

Device just wants to use TEAP in the same way one would use EAP-TLS.  
This would be what I would call "normal operations". That is, we would 
expect something along the following lines:


 ,.,--.
 |Peer||Server|
 `-+--'`--+---'
   |1 EAP-Request/|
   |Identity  |
   | <-
   |  |
   |2 EAP-Response/   |
   |Type=Identity |
   | ->
   |  |
,!.
|Section 3.2 |_\
`--'
   |   3 EAP-Request/ |
   |   Type=TEAP, |
   |   TEAP Start,|
   |   Authority-ID TLV   |
   | <-
   |  |
   |   4 EAP-Response/|
   |   Type=TEAP, |
   |   TLS(ClientHello)   |
   | ->
   |  |
   |  5 EAP-Request/  |
   |  Type=TEAP,  |
   |  TLS(ServerHello,|
   |  ServerKeyExchange,  |
   |  ServerHelloDone)|
   | <-
   |  |
   |  6 EAP-Response/ |
   |  Type=TEAP,  |
   |  ClientKeyExchange,  |
   |  CertificateVerify,  |
   |  ChangeCipherSpec,   |
   |  Finished)   |
   | ->
   |  |
,!.
|Section 3.3.3   |_\
`--'
   | 7 EAP-Request/   |
   | Type=TEAP,   |
   | TLS(ChangeCipherSpec,|
   | Finished),   |
   | Result TLV,  |
   | Crypto-Binding TLV   |
   | <-
   |  |
   |  8 EAP-Response/ |
   |  Type=TEAP,  |
   |  Result TLV, |
   |  Crypto-Binding TLV  |
   | ->
   |  |
   | 9 EAP-Success|
   | <-
 ,-+--.,--+---.
 |Peer||Server|
 `'`--'

Note the lack of an Intermediate Result TLV, because the text states 
that Intermediate Results are only required upon completion of an inner 
EAP method.


The second use case involves the use of PKCS#10/PKCS#7 messages. We 
think that looks like this:



 ,. ,--.  ,--.
 |Peer| |Server|  |CA|
 `-+--' `--+---'  `+-'
   |EAP-Request/   |   |
   |Identity   |   |
   | <--   |
   |   |   |
   |   EAP-Response/   |   |
   |   Type=Identity   |   |
   | -->   |
   |   |   |
   |  EAP-Request/ |   |
   |  Type=TEAP,   |   |
   |  TEAP Start,  |   |
   |  Authority-ID TLV |   |
   | <--   |
   |   |   |
   |  EAP-Response/|   |
   |  Type=TEAP,   |   |
   |  TLS(ClientHello) |   |
   | -->   |
   |   |   |
   | EAP-Request/  |   |
   | Type=TEAP,|   |
   | TLS(ServerHello,  |   |
   | ServerKeyExchange,|   |
   |

Re: [Emu] Adoption call for EAP-DPP

[Eliot Lear]

Hi Behcet,

On 08.09.22 17:43, Behcet Sarikaya wrote:Hi Peter, Joe,
Also the problem that this draft deals with and also Elliott mentioned 
in his mail, Wi-Fi Easy Connect already solves it.


DPP works with wired when L3 connectivity is pre-established. This is 
covered in Section 2.3.5 in the specification and is a valid method.  
IMHO the problem is better addressed at L2, and that was the analog to 
which I referred.


Eliot




OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key


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

Re: [Emu] Adoption call for EAP-DPP

[Eliot Lear]

Peter,

Let me clarify why I think it's important to adopt this work. The Wifi 
Alliance has already standardized the public/private key pair as well as 
other attributes that can be used to securely onboard a device.  They 
have also standardized the QR code used to represent this information.  
DPP has reasonably good support in the widely distributed wpa_supplicant 
code, and that gets us a long way... for wireless.


We need that sort of capability for wired devices as well. Owen's and 
Dan's work provides that parity using the *identical* bootstrapping 
information, QR code representation, and algorithm. *AND* there's 
already code.  And it's a pretty elegant solution.


So.. I'd ask that people take a look.

Eliot

On 08.09.22 06:57, Peter Yee wrote:

In retrospect, sending the call for adoption at the height of August
vacation season may not have guaranteed the most responses. To be honest,
the level of responses to this call has been a little light, so Joe and I
have decided to extend the call for adoption for one week from today.

We would really like to hear from anyone else who is interested in reviewing
and/or contributing to this specification or anyone who feels that it should
not be adopted. Please speak up by the 14th either way. This specification
would seemingly fit within the WG's existing charter, so let your voice be
heard!

Thanks,

Peter and Joe

-Original Message-
From: Peter Yee  
Sent: Tuesday, August 16, 2022 1:12 PM

To: 'emu@ietf.org'
Subject: Adoption call for EAP-DPP

This is an adoption call for EAP-DPP (draft-friel-tls-eap-dpp-05)[1]. This
document aligns with the charter item to "Define mechanisms by which EAP
methods can support creation of long-term credentials for the peer based on
initial limited-use credentials." The latest revision incorporates feedback
from both the TLS and EMU working groups. Please review and respond to the
list if you think this document is or is not an appropriate working group
item for EMU by September 1, 2022.

Thanks,

Peter and Joe

[1]https://datatracker.ietf.org/doc/draft-friel-tls-eap-dpp/


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



OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key


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

Re: [Emu] Adoption call for EAP-DPP

[Eliot Lear]

I agree with Behcet's comments, but otherwise support the work's adoption.

Eliot

On 17.08.22 23:36, Behcet Sarikaya wrote:

Hi Peter,

I quickly read this short document and have some comments.

In the informative references section, DPP is listed as Device 
Provisioning Profile while it should be Device Provisioning Protocol.
Actually, in the acronyms section the name is correctly given. 
However, the DPP acronym is not properly expanded in the first use of 
the acronym which is in Section 1. Also the same could be said of the 
other acronyms.


Also the date of DPP document seems to be wrong, I think the version 
1.1 was dated 2018.


Probably more seriously though, the document says DPP does not support 
wired network access in Section 1 but maybe the authors are not aware 
that there is something called wired only DPP which is defined in 
another WiFi Alliance document in Section 2.3.5 of


Wi-Fi Easy ConnectTM Specification v2.0

This document is dated 2020, maybe the authors should reference this 
document then the date will be correct .


Behcet

On Tue, Aug 16, 2022 at 3:12 PM Peter Yee  wrote:

This is an adoption call for EAP-DPP
(draft-friel-tls-eap-dpp-05)[1]. This
document aligns with the charter item to "Define mechanisms by
which EAP
methods can support creation of long-term credentials for the peer
based on
initial limited-use credentials." The latest revision incorporates
feedback
from both the TLS and EMU working groups. Please review and
respond to the
list if you think this document is or is not an appropriate
working group
item for EMU by September 1, 2022.

Thanks,

Peter and Joe

[1] https://datatracker.ietf.org/doc/draft-friel-tls-eap-dpp/


___
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


OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key


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

Re: [Emu] EAP Erratum 6154 on RFC 3579:

[Eliot Lear]

Ok.  I've updated the errata text.

On 01.04.22 14:16, Alan DeKok wrote:

   +1

   Other than that, they look OK, thanks.


On Apr 1, 2022, at 1:16 AM, Bernard Aboba  wrote:

I think the note in eid6259 is now superfluous.  Can we remove it?

On Thu, Mar 31, 2022 at 10:09 PM Independent Submissions Editor (Eliot Lear) 
 wrote:
Corrected URLs below:

On 01.04.22 06:48, Independent Submissions Editor (Eliot Lear) wrote:

Ok.

I have edited – but not yet verified – the two errata accordingly.
Please see:

https://www.rfc-editor.org/errata/eid6154
https://www.rfc-editor.org/errata/eid6259

___
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] EAP Erratum 6154 on RFC 3579:

[Independent Submissions Editor (Eliot Lear)]

Ok.  Then I will reject eid6259.

Eliot

On 01.04.22 14:16, Alan DeKok wrote:

   +1

   Other than that, they look OK, thanks.


On Apr 1, 2022, at 1:16 AM, Bernard Aboba  wrote:

I think the note in eid6259 is now superfluous.  Can we remove it?

On Thu, Mar 31, 2022 at 10:09 PM Independent Submissions Editor (Eliot Lear) 
 wrote:
Corrected URLs below:

On 01.04.22 06:48, Independent Submissions Editor (Eliot Lear) wrote:

Ok.

I have edited – but not yet verified – the two errata accordingly.
Please see:

https://www.rfc-editor.org/errata/eid6154
https://www.rfc-editor.org/errata/eid6259


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

Re: [Emu] EAP Erratum 6154 on RFC 3579:

[Independent Submissions Editor (Eliot Lear)]

Corrected URLs below:

On 01.04.22 06:48, Independent Submissions Editor (Eliot Lear) wrote:

Ok.

I have edited – but not yet verified – the two errata accordingly.  
Please see:


https://www.rfc-editor.org/errata/eid6154
https://www.rfc-editor.org/errata/eid6259

Are there any further edits that are required?

Eliot (ISE)

On 01.04.22 00:52, Alan DeKok wrote:
On Mar 31, 2022, at 4:40 PM, Bernard Aboba  
wrote:

Alan suggested:
"   EAP-Start is indicated by sending an EAP-Message attribute with a
    length of 3.  The single byte of data SHOULD be set to zero on
    transmission and MUST be ignored on receipt.  RADIUS clients 
MUST NOT
    send EAP-Message attributes of length 2, as attributes with no 
value
    are not permitted in RADIUS.  However, for historical reasons 
and for
    compatibility with existing practice, RADIUS servers MUST accept 
EAP-Messages

    of length 2, and treat them as EAP-Start.

   Just checking the source I have locally, the server accepts 
zero-length EAP-Message (or any other text/string attribute, for 
that matter).  So that's fine."


[BA] This suggested errata text looks good.

   Thanks.

[BA] This text is better. The implicit assumption here is that the 
NAS is sending an EAP-Request with a locally implemented EAP type, 
without talking to the RADIUS server.  Of course, the same thing 
could happen if the RADIUS server uses an inappropriate default 
type.  So perhaps this might work:


"  Where the initial EAP-Request sent by the NAS is for an
   authentication Type (4 or greater), the peer MAY respond with a Nak
   indicating that it would prefer another authentication method. In 
this

  case, the NAS should send an Access-Request encapsulating the
  received EAP-Response/Nak.  This allows a peer to suggest another
  EAP method where the NAS is configured to send a default EAP
   type (such as MD5-Challenge) which may not be appropriate."

   That looks good to me, thanks.

   Alan DeKok.



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



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

Re: [Emu] EAP Erratum 6154 on RFC 3579:

[Independent Submissions Editor (Eliot Lear)]

Ok.

I have edited – but not yet verified – the two errata accordingly.  
Please see:


https://www.rfc-editor.org/verify_errata_select.php?eid=6154
https://www.rfc-editor.org/verify_errata_select.php?eid=6259

Are there any further edits that are required?

Eliot (ISE)

On 01.04.22 00:52, Alan DeKok wrote:

On Mar 31, 2022, at 4:40 PM, Bernard Aboba  wrote:

Alan suggested:
"   EAP-Start is indicated by sending an EAP-Message attribute with a
length of 3.  The single byte of data SHOULD be set to zero on
transmission and MUST be ignored on receipt.  RADIUS clients MUST NOT
send EAP-Message attributes of length 2, as attributes with no value
are not permitted in RADIUS.  However, for historical reasons and for
compatibility with existing practice, RADIUS servers MUST accept 
EAP-Messages
of length 2, and treat them as EAP-Start.

   Just checking the source I have locally, the server accepts zero-length 
EAP-Message (or any other text/string attribute, for that matter).  So that's 
fine."

[BA] This suggested errata text looks good.

   Thanks.


[BA] This text is better. The implicit assumption here is that the NAS is 
sending an EAP-Request with a locally implemented EAP type, without talking to 
the RADIUS server.  Of course, the same thing could happen if the RADIUS server 
uses an inappropriate default type.  So perhaps this might work:

"  Where the initial EAP-Request sent by the NAS is for an
   authentication Type (4 or greater), the peer MAY respond with a Nak
   indicating that it would prefer another authentication method. In this
  case, the NAS should send an Access-Request encapsulating the
  received EAP-Response/Nak.  This allows a peer to suggest another
  EAP method where the NAS is configured to send a default EAP
   type (such as MD5-Challenge) which may not be appropriate."

   That looks good to me, thanks.

   Alan DeKok.



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

[Emu] EAP Erratum 6154 on RFC 3579:

[Independent Submissions Editor (Eliot Lear)]

Dear EMU working group,

Alan Dekok has reported two errata[1,2] against RFC 3579.  RFC 3579 is 
classed an independent submission, and thus falls under the purview of 
the Independent Submissions Editor (ISE).  The ISE is inclined to verify 
both errata, and will do so in the next two months unless this group 
advises otherwise.


Eliot Lear (ISE)

[1] https://www.rfc-editor.org/errata/eid6154
[2] https://www.rfc-editor.org/errata/eid6259

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

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

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

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

[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

[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

[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

[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

[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

[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

[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

[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

[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