On Mon, 10 Apr 2023 at 19:20, Karl Norrman wrote:
[K]: I have described only one. I also gave a concrete example, which may
> have caused confusion.
> I will try to describe it again in clearer terms, but shorter. Point 2
> answers the direct question.
>
> 1. There is an EAP server S and a pass-t
Hi!
> "Use PFS methods" is a good
> step. Warning people of the limitations of PFS is a good step. Past that, I
> don't
> see any recommendations which I can implement.
[K]: Excellent. If we can get that in a general AAA document read by people
deploying
EAP/AAA, I'd be much happier than hav
On Apr 10, 2023, at 12:20 PM, Karl Norrman wrote:
> [K]: What above made you believe I meant the clients authenticating via EAP?
You mentioned EAP session keys being compromised. That would tend to imply
end users being affected.
> I mean that the organization(s) deploying EAP and the authen
Hi!
> > [K]: OK. I don't argue that PFS is important here. My point is just
> > that those who *do* believe that PFS is important need to take care
> > when using long-lived TLS/IPsec sessions. That is:
> > 1. Assuming a system user wants PFS, the question is whether they get
> > it by enabling PF
> I would suggest that these attacks aren't very relevant. Or if they
are, there
> is very little which can be done about them.
+1
An AAA infrastructure is a logical extension of the NAS that enables
authentication, key derivation and other security functions to be
externalised. That externali
On Apr 10, 2023, at 4:54 AM, Karl Norrman wrote:
> [K]: OK. I don't argue that PFS is important here. My point is just that those
> who *do* believe that PFS is important need to take care when using
> long-lived TLS/IPsec sessions. That is:
> 1. Assuming a system user wants PFS, the question is w
Hi!
> From a practical point of view, I think PFS issues are less of a problem
> than
> other issues.
[K]: OK. I don't argue that PFS is important here. My point is just that those
who *do* believe that PFS is important need to take care when using
long-lived TLS/IPsec sessions. That is:
1. As
On Apr 9, 2023, at 3:51 PM, Karl Norrman wrote:
> [K]: Correct. The assumption in 1 is that the traffic is protected with IPsec
> or TLS.
> Thanks for the reference. I read it, but it does not seem to consider the
> forward secrecy
> aspects I try to describe here.
I can add some text about P
Hi!
Thanks for the quick reply.
Please see [K] inline.
> -Original Message-
> From: Alan DeKok
> Sent: Sunday, 9 April 2023 20:56
> To: Karl Norrman
> Cc: emu@ietf.org
> Subject: Re: [Emu] System level forward secrecy for EAP+AAA
>
> On Apr 9, 2023, at 2:06 P
On Apr 9, 2023, at 2:06 PM, Karl Norrman
wrote:
> Is there any RFC to reference for forward secrecy for the EAP+AAA framework,
> which gives recommendations for preventing the attack below?
>
> Many RFCs for EAP methods and AAA contain various recommendations regarding
> forward secrecy, but I
10 matches
Mail list logo
