|
|
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
|
|