I am going to come down on the side of no PSK should not be supported.
However my issues have nothing to do with how things are implemented and
more to do with the security properties of the EAP method.
When you use certificates, there is no leakage of who the client is as this
is encrypted by TLS
On Sep 18, 2019, at 5:42 PM, Owen Friel (ofriel) wrote:
> Giving some implementation guidance seems appropriate here. Naively, one
> could envisage the implementation simply having a DB table for extern PSKs
> and a table that holds NewSessionTickets. An implementation could simply
> check the
And one other draft of interest:
https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-00
> -Original Message-
> From: Emu On Behalf Of Owen Friel (ofriel)
> Sent: 18 September 2019 22:42
> To: Alan DeKok ; John Mattsson
>
> Cc: draft-ietf-emu-eap-tl...@ietf.org; EMU WG
> Su
> -Original Message-
> From: Alan DeKok
> Sent: 18 September 2019 14:40
> To: John Mattsson
> Cc: Owen Friel (ofriel) ; draft-ietf-emu-eap-
> tl...@ietf.org; EMU WG
> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
>
>
>
> > On Sep 18, 2019, at 9:21 AM, John Mattsson
> On Sep 18, 2019, at 9:21 AM, John Mattsson wrote:
>
> If I understand you correctly Alan, your implementation would have different
> databases (one resumption DB and one external PSK DB) and you do not want to
> do two database lookups.
It's more about what *can* be done. RFC 8446 Sect
If I understand you correctly Alan, your implementation would have different
databases (one resumption DB and one external PSK DB) and you do not want to do
two database lookups. The format of the PSKidentities is free for the
deployment to decide upon and the resumption PSKs can be completely b
Just re-reading the text on PSK, I noticed a few things. The text in Section
2.1.2 talks about PSK, the session ticket, and a "key_share" extension. The
accompanying diagram doesn't include any of those. I suggest updating the
diagram to include them.
As a related note, if the PSK *is*
On Sep 18, 2019, at 8:45 AM, Owen Friel (ofriel) wrote:
>
>>
>> Which means that if PSK was allowed, the server can't look at the packets to
>> distinguish resumption from "raw" PSK. Instead, the server has to look at
>> it's
>> resumption cache which may be in a DB.
>
> The server can use t
> -Original Message-
> From: Emu On Behalf Of Alan DeKok
> Sent: 12 September 2019 16:28
> To: John Mattsson
> Cc: draft-ietf-emu-eap-tl...@ietf.org; EMU WG
> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
>
> On Sep 12, 2019, at 10:55 AM, John Mattsson
> wrote:
> >
Dear Joe, Mohit and all,
In overall I find the text well written, while the objectives well defined.
Below I have very few comments :
* TLS is not defined.
* Perfect Forward Secrecy (PFS) is defined twice.
* - An update to enable the use of TLS 1.3 in the context of EAP-TLS (RFC
5216). This doc
10 matches
Mail list logo
