ecrit@ietf.org
[Top] [All Lists]

Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks o

Subject: Re: [Ecrit] emergency access and EAP-TLS and denial of serviceattacks on the emergency.com domain
From: Bernard Aboba
Date: Tue, 23 Mar 2010 00:32:33 -0700
No, because the "anonymous" NAI is typically used in protocols (like EAP-TTLSv0, EAP-FAST or PEAP) where mutual authentication is required.  So while the NAS or an eavesdropper can't determine the client identity, the AAA server can and does determine it (and in turn, proves its identity to the client).

So at least in EAP, "anonymous" != "unauthenticated"




> CC: jsalowey@xxxxxxxxx; dirk.kroeselberg@xxxxxxx; hgs@xxxxxxxxxxxxxxx; ecrit@xxxxxxxx; emu@xxxxxxxx
> From: rbarnes@xxxxxxx
> To: bernard_aboba@xxxxxxxxxxx
> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain)
> Date: Mon, 22 Mar 2010 22:43:28 -0700
>
> Doesn't it functionally amount to the same thing, though? Just the
> client choosing not to authenticate vs not being able to authenticate?
> --Richard
>
>
> On Mar 22, 2010, at 10:29 PM, Bernard Aboba wrote:
>
> > Yes, there is an "anonymous" NAI, but the goal of that is to hide
> > the identity from the NAS and eavesdroppers, not to enable client
> > unauthenticated access.
> >
> > On Mar 22, 2010, at 10:23 PM, Richard Barnes <rbarnes@xxxxxxx> wrote:
> >
> >> In particular, providing unauthenticated *network* access is a
> >> prerequisite for providing unauthenticated *VoIP* access.
> >>
> >> Also, Bernard: Does your below mention of "anonymous" NAI indicate
> >> that there is actually a reserved NAI "anonymous"? If so, then I
> >> don't really see the use for a separate "sos" NAI -- you can just
> >> provide ECRIT access to "anonymous".
> >>
> >> --Richard
> >>
> >>
> >>
> >> On Mar 22, 2010, at 6:28 PM, Bernard Aboba wrote:
> >>
> >>> Part of the confusion here may be that we're talking about
> >>> "unauthenticated" at multiple layers. There is unauthenticated
> >>> network access, and then there is unauthenticated VOIP signaling.
> >>>
> >>> These are two orthogonal things. The VOIP signaling should not
> >>> change regardless of whether the network access is authenticated
> >>> or unauthenticated.
> >>>
> >>> Similarly, it's possible to use authenticated or unauthenticated
> >>> VOIP signaling over authenticated or unauthenticated access.
> >>>
> >>> Focusing solely on how to obtain "unauthenticated" access, the
> >>> question is how the client signals that it is interested in
> >>> "unauthenticated" access. This is important, because otherwise
> >>> the server might request client authentication (e.g. a client
> >>> certificate request). Essentially the "sos" NAI is functioning
> >>> similar to the "anonymous" NAI in that this results in special
> >>> processing on the AAA server side.
> >>>
> >>>
> >>>
> >>> Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of
> >>> serviceattacks on the emergency.com domain)
> >>> Date: Mon, 22 Mar 2010 18:14:59 -0700
> >>> From: jsalowey@xxxxxxxxx
> >>> To: dirk.kroeselberg@xxxxxxx; hgs@xxxxxxxxxxxxxxx; bernard_aboba@xxxxxxxxxxx
> >>> CC: ecrit@xxxxxxxx
> >>>
> >>> I do not think EAP or NAI should be used as a signaling mechanism
> >>> for emergency. These mechanisms are ways to obtain network
> >>> access when you cannot in some other way. Once you have network
> >>> access it seems that the emergency procedures should be the same
> >>> whether you authenticated to get network access or you gained
> >>> access though another mechanism.
> >>>
> >>> I am probably missing some ECRIT specific nuances here, but I feel
> >>> that tying emergency procedures at higher layers to EAP usage will
> >>> be fraught with problems.
> >>>
> >>> Joe
> >>>
> >>>
> >>> From: ecrit-bounces@xxxxxxxx [mailto:ecrit-bounces@xxxxxxxx] On
> >>> Behalf Of Kroeselberg, Dirk (NSN - DE/Munich)
> >>> Sent: Monday, March 22, 2010 5:26 PM
> >>> To: ext Henning Schulzrinne; Bernard Aboba
> >>> Cc: ecrit@xxxxxxxx
> >>> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of
> >>> serviceattacks on the emergency.com domain)
> >>>
> >>> yes, fixing the NAI to a simple string is simple (this would
> >>> basically be a NAI that is username only, correct?).
> >>>
> >>> However, let me repeat my question from the other thread: How to
> >>> handle the 'authenticated' emergency case where the NAI carries
> >>> the regular username? The draft may be about unauthenticated, but
> >>> just covering unauthenticated and leaving the authenticated case
> >>> open seems less useful to me.
> >>>
> >>> Dirk
> >>>
> >>> From: ext Henning Schulzrinne [mailto:hgs@xxxxxxxxxxxxxxx]
> >>> Sent: Tuesday, March 23, 2010 1:02 AM
> >>> To: Bernard Aboba
> >>> Cc: Kroeselberg, Dirk (NSN - DE/Munich); ecrit@xxxxxxxx
> >>> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of
> >>> service attacks on the emergency.com domain)
> >>>
> >>> The "sos" name seems to be a reasonable approach that's simple and
> >>> easy.
> >>>
> >>> Longer term, I think a better option is to have a semi-
> >>> authenticated mode: Imagine a setup where VSPs or other trustable
> >>> bodies hand out tokens (e.g., using the OAuth-WARP work) that the
> >>> ISP recognizes. The ISP is given the right to monitor the usage of
> >>> 'sos' sessions and can hand the token to the appropriate
> >>> authorities for prosecution in case of abuse. That way, you get
> >>> emergency access, but make it unlikely that the system will be
> >>> abused on a large scale. In some countries, you might get such a
> >>> token from your local public authority when you're registering
> >>> your residence.
> >>>
> >>> Henning
> >>>
> >>> On Mar 22, 2010, at 7:50 PM, Bernard Aboba wrote:
> >>>
> >>>
> >>> If all you want to do is to gain emergency access to the local
> >>> network, you don't need to discover the domain. You can just use
> >>> an NAI of "sos". That will be more convenient in situations
> >>> where the local access mechanism (e.g. 802.1X) doesn't permit IP
> >>> packets (including DHCP) to pass prior to completing
> >>> authentication, so that "domain discovery" couldn't occur until
> >>> afterwards.
> >>>
> >>>
> >>> _______________________________________________
> >>> Ecrit mailing list
> >>> Ecrit@xxxxxxxx
> >>> https://www.ietf.org/mailman/listinfo/ecrit
> >>
> >>
>
_______________________________________________
Ecrit mailing list
Ecrit@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ecrit
<Prev in Thread] Current Thread [Next in Thread>