> The one change I think you might consider doing is to put a "future version
> note" into the document with the suggestion that this be considered.
Good idea. I will write something.
Jari
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mail
This message had my response in the wrong place. I was responding to Tim's
comments and not to Alan's comments. I completely agree with Alan that this
information needs to be fed back to the NAS and not rely on what the client
starts out saying.
> -Original Message-
> From: Emu On Be
On Nov 14, 2018, at 1:34 PM, Jim Schaad wrote:
>> The only way to provide the real identity back to the NAS would be sending it
>> back as the IETF User-Name in the Access-Accept with the assumption that
>> the NAS would honor it.
>
> My first response to this would be - what happens as an attack
> -Original Message-
> From: Jari Arkko
> Sent: Wednesday, November 14, 2018 9:47 AM
> To: Jim Schaad
> Cc: emu@ietf.org; draft-ietf-emu-rfc5448...@ietf.org
> Subject: Re: [Emu] WGLC for draft-ietf-emu-rfc5448bis
>
> Thanks for your review, Jim.
>
> > Any issues that I have here might
> -Original Message-
> From: Emu On Behalf Of Cappalli, Tim (Aruba
> Security)
> Sent: Wednesday, November 14, 2018 6:49 AM
> To: Alan DeKok
> Cc: emu@ietf.org; John Mattsson
> Subject: Re: [Emu] FW: New Version Notification for draft-ietf-emu-eap-
> tls13-03.txt
>
> The question was
Thanks for your review, Jim.
> Any issues that I have here might have already been raised and discussed. If
> so just not that and ignore.
>
> Section 3.4 - I am curious why you did not make the hash function a property
> of the HKDF function rather than making it a hard coded value. I would
Alan DeKok wrote:
> For me, I would be fine with making the anonymous NAI mandatory. I
> just don't see any end-user benefit to exposing their identities. And
> there are benefits to privacy.
>> In terms of infrastructure, logging into a wireless controller, switch
>>or NMS
On Nov 14, 2018, at 9:04 AM, John Mattsson wrote:
>
> Hi all,
>
> I think the draft is now in quite good shape. It would be good to get some
> reviews.
A quick review, mostly NITs:
Weaknesses found in previous versions of TLS, as well as new
requirements for security, privacy, and re
On Nov 14, 2018, at 9:48 AM, Cappalli, Tim (Aruba Security)
wrote:
>
> The question was asked about making it anonymous NAI mandatory in the
> Identity Response. That is what my comments were targeted to.
OK.
For me, I would be fine with making the anonymous NAI mandatory. I just
don't
The question was asked about making it anonymous NAI mandatory in the Identity
Response. That is what my comments were targeted to.
In terms of infrastructure, logging into a wireless controller, switch or NMS
and seeing hundreds of "anonym...@enterprise.co" makes an administrator's life
misera
I would be very hesitant to mandate RFC 7924. Most EAP-TLS
implementations use existing TLS libraries rather than implementing
their own TLS stack. And many popular TLS libraries don't provide
support for RFC 7924. Please look at :
https://github.com/openssl/openssl/issues/5040 for example.
Us
Hi Russ,
Thanks for reporting this. I have now fixed the nit and updated the
missing sentence after checking the audio recording. The updated meeting
minutes are here:
https://datatracker.ietf.org/meeting/103/materials/minutes-103-emu-01
--Mohit
On 11/14/18 10:02 AM, Russ Housley wrote:
> Con
On Nov 14, 2018, at 9:04 AM, John Mattsson wrote:
> draft-ietf-emu-eap-tls13-03 adds:
>
> "The use of Certificate Status Requests to determine the current status of
> the EAP server's certificate is RECOMMENDED."
I think that's good.
> For EAP-TLS where the peer often does not have internet
I think mandatory support and use of stapling is a great idea. There have been
so many changes across platforms the past few years w.r.t. status checks during
an EAP exchange which has caused significant admin and end user headache. This
solves that by making it consistent while adding the secur
Hi all,
I think the draft is now in quite good shape. It would be good to get some
reviews. One thing that I would like to discuss is what the draft should say
about various extensions and mechanisms. In particular:
- Revocation
--
RFC 5216
On Nov 14, 2018, at 8:16 AM, Cappalli, Tim (Aruba Security)
wrote:
>
> Making it mandatory to use an anonymous NAI will be a huge issue in
> enterprise where the infrastructure, device and enterprise identity is owned
> by the enterprise. There is no proxy or third party provider.
I don't se
Making it mandatory to use an anonymous NAI will be a huge issue in enterprise
where the infrastructure, device and enterprise identity is owned by the
enterprise. There is no proxy or third party provider.
Seeing "anonym...@enterprise.com" across all network infrastructure is not
going to be a
Hi,
We have updated the draft according to the discussion and conclusions at IETF
103.
- New figure showing the message flow for EAP-TLS client rejection of
NewSessionTicket
- The draft did not mention that TLS has both warning and fatal alerts. We
changed "TLS Alert Message" to " TLS Fata
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the EAP Method Update WG of the IETF.
Title : Using EAP-TLS with TLS 1.3
Authors : John Mattsson
Mohit Sethi
Filename
Concern:
Jari: Need feedback. See this as WG document? We might be able to stick this in
and have affect on organizations that want to spy on. We might actually get
this deployed if .
The end of the sentence is missing...
Nit:
Russ: MAC is dependent on the based AKA authentication.
s/based
20 matches
Mail list logo
