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: Richard Barnes
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>