|
in addition
to what Bernard said, the functionality does not amount to the same thing
because an access network may well allow emergency but not
anonymous entry, may not want to put all anonymous users under emergency
treatment, etc. It is simple: the peer needs to spell out explicitly that the
access request is for emergency.
The network
needs to know this to apply proper treatment (whatever this will be is up
to the network, but it may include authorization decisions in the
AAA, priority for some messages, filtering, applying special QoS,
etc.). We don't care about this here, but an emergency indication
via the NAI has impact outside EAP and the EAP method in the
access.
Dirk
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
> >>
>
>>
>
|