Subject: Re: [Emu] [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain)

From: Bernard Aboba <[email-masked]>
Date: Mon, 22 Mar 2010 18:28:20 -0700

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: [email-masked]
To: [email-masked]; [email-masked]; [email-masked]
CC: [email-masked]

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:
[email-masked] [mailto:[email-masked]] On Behalf Of Kroeselberg,
Dirk (NSN - DE/Munich)

Sent: Monday, March 22, 2010 5:26 PM

To: ext Henning Schulzrinne; Bernard Aboba

Cc: [email-masked]

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:[email-masked]] 

Sent: Tuesday, March 23, 2010 1:02 AM

To: Bernard Aboba

Cc: Kroeselberg, Dirk (NSN - DE/Munich); [email-masked]

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.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 22 Mar 2010 22:29:37 -0700

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 <[email-masked]> 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  
>> 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.
>>
>> that tying emergency procedures at higher layers to EAP usage will  
>> be fraught with problems.
>>
>> Joe
>>
>>
>> From: [email-masked] [mailto:[email-masked]] On  
>> Behalf Of Kroeselberg, Dirk (NSN - DE/Munich)
>> 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:[email-masked]]
>> 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
>>
>> 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ecrit
>
>

---

From: Bernard Aboba <[email-masked]>
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: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
> From: [email-masked]
> To: [email-masked]
> 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.
> >
> >>> change regardless of whether the network access is authenticated  
> >>> or unauthenticated.
> >>>
> >>> "unauthenticated" access.  This is important, because otherwise  
> >>> the server might request client authentication (e.g. a client  
> >>> 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
> >>>
> >>> token from your local public authority when you're registering  
> >>> your residence.
> >>>
> >>> Henning
> >>>
> >>> 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.
> >>>
> >>>

---

From: "Kroeselberg, Dirk (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 23 Mar 2010 14:56:36 +0100

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

________________________________

	From: ext Bernard Aboba [mailto:[email-masked]] 
	Sent: Tuesday, March 23, 2010 8:33 AM
	To: [email-masked]
	Cc: Joseph Salowey (jsalowey); Kroeselberg, Dirk (NSN -
DE/Munich); [email-masked]; [email-masked]; [email-masked]
	Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of
serviceattacks on the emergency.com domain)

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

<http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood> 

	> CC: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
	> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial
of serviceattacks on the emergency.com domain)

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 23 Mar 2010 16:19:59 -0700

At least with the approach we've been talking about (e.g. "sos" NAI), explicit configuration and server-side work (e.g. server-only auth support) is going to be required to turn on "unauthenticated access".   So I don't think you have to worry about it being "turned on by default", given that few if any hosts or AAA servers support this today. 

About priority.  Enterprise customers tend to be dragged into E-9-1-1 deployments kicking and screaming to begin with, and (at least in the US), there is  currently no federal requirement for MLTS support for E-9-1-1, only state laws.  At various points, I've heard claims that this might be a legal requirement somewhere for anonymous access.  If that is true or might be true, it would be nice to have a pointer to a regulation or statute.  It's definitely not referenced in any U.S. 9-1-1 legislation or regulatory proceeding, or even in the recently introduced National Broadband plan or legislative proposals (HR 4829).  

> Date: Tue, 23 Mar 2010 17:09:15 -0400
> From: [email-masked]
> To: [email-masked]; [email-masked]
> CC: [email-masked]; [email-masked]
> 
> In this discussion, please keep in mind what I've said many times, in other
> related discussions:
> 
> A large percentage (in fact an overwhelming percentage) of PSAPs DON'T WANT
> unauthenticated access.  Their position is that they have lots of relevant
> experience, and its all bad (tens of thousands of calls with no good ones in
> some cases).
> 
> However, there are some PSAPs who want it, and there are some regulatory
> environments where there are some lawyers who think it's required to support
> it in some environments.
> 
> So, perhaps we eventually need to do this, however:
> 
> It should be completely disablable, and will be for a large number of cases
> It's not a high priority
> 
> Brian
> 
> 
> On 3/23/10 11:58 AM, "Richard Barnes" <[email-masked]> wrote:
> 
> > Ah, ok, that makes sense.  So maybe we just need an "unauthenticated"
> > token?  Still don't see anything really emergency-specific in this,
> > besides specifying what constraints you might put on unauthenticated
> > users.
> > 
> > --Richard
> > 
> > 
> > 
> > On Mar 23, 2010, at 12:32 AM, Bernard Aboba wrote:
> > 
> >> No, because the "anonymous" NAI is typically used in protocols (like
> >> EAP-TTLSv0, EAP-FAST or PEAP) where mutual authentication is
> >> client identity, the AAA server can and does determine it (and in
> >> turn, proves its identity to the client).
> >>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 23 Mar 2010 01:29:04 -0400

The goal is to provide a specific "emergency only" network access, rather than anonymous access. Indeed, anonymity is typically not the goal. As a hotel operator, I might be happy to provide emergency call access even to non-guests, but clearly don't want to free Internet access to the neighborhood. Thus, I think that the "sos" NAI in the short term, along with non-subscription-based access right token for emergency calling longer term, is a reasonable direction.

Henning

On Mar 23, 2010, at 1:23 AM, Richard Barnes 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

---

From: Richard Barnes <[email-masked]>
Date: Mon, 22 Mar 2010 22:43:28 -0700

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 23 Mar 2010 13:44:38 +0800

And it *could* be rephrased as follows.

An obligation to support unauthenticated emergency calling means:
1) Provide the option of establishing an unauthenticated IP context
2) It's sufficient if only emergency calling procedures are supported on that IP context

This is quite straightforward under an ECRIT-direct model - 2) is satisfied as long as HELD, LoST, and a SIP route to the relevant PSAP URI is available.

It's more difficult if you have to allow people to also proxy emergency calls via arbitrary VoIP providers... using arbitrary VoIP protocols.

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Tuesday, 23 March 2010 4:24 PM
To: Bernard Aboba
Cc: [email-masked]; [email-masked]
Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain)

--Richard

On Mar 22, 2010, at 6:28 PM, Bernard Aboba wrote:

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 23 Mar 2010 01:59:21 -0400

No, it indicates the desire to place an emergency call. Thus, if I use this access to visit Facebook, I'm doing the equivalent of parking in a handicapped parking spot. The "anonymous" notion would not.

Henning

On Mar 23, 2010, at 1:43 AM, Richard Barnes wrote:

> Doesn't it functionally amount to the same thing, though?   Just the client choosing not to authenticate vs not being able to authenticate?
> --Richard
>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 22 Mar 2010 23:00:40 -0700

Seems like kind of a false distinction -- if the network doesn't know  
you, it doesn't know you.  Are you envisioning anonymous users that  
*won't* be allowed emergency call access?
--Richard

On Mar 22, 2010, at 10:29 PM, Henning Schulzrinne wrote:

> The goal is to provide a specific "emergency only" network access,  
> rather than anonymous access. Indeed, anonymity is typically not the  
> goal. As a hotel operator, I might be happy to provide emergency  
> call access even to non-guests, but clearly don't want to free  
> Internet access to the neighborhood. Thus, I think that the "sos"  
> NAI in the short term, along with non-subscription-based access  
> right token for emergency calling longer term, is a reasonable  
> direction.
>
> Henning
>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 22 Mar 2010 22:23:53 -0700

--Richard

---

From: Richard Barnes <[email-masked]>
Date: Mon, 22 Mar 2010 23:26:50 -0700

I still don't follow.  The intent of the user is irrelevant here --  
either an unauthenticated user is allowed to make an emergency call or  
he isn't.  Again, are you supposing that a network would provide to  
classes of unauthenticated service, one that allows only emergency  
calling and one that allows me to use Facebook?  Why wouldn't I just  
always use the latter?

On Mar 22, 2010, at 10:59 PM, Henning Schulzrinne wrote:

> No, it indicates the desire to place an emergency call. Thus, if I  
> use this access to visit Facebook, I'm doing the equivalent of  
> parking in a handicapped parking spot. The "anonymous" notion would  
> not.
>
> Henning
>
>> Doesn't it functionally amount to the same thing, though?   Just  
>> the client choosing not to authenticate vs not being able to  
>> authenticate?
>> --Richard
>>
>

---

From: Richard Barnes <[email-masked]>
Date: Tue, 23 Mar 2010 08:58:17 -0700

--Richard

---

From: Brian Rosen <[email-masked]>
Date: Tue, 23 Mar 2010 17:09:15 -0400

It should be completely disableable, and will be for a large number of cases
It's not a high priority

Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 23 Mar 2010 18:32:06 -0400

I think part of the confusion is that unauthenticated network access does not mean unauthenticated caller. As I've been trying to point out for a while, with apparently limited success, is that it would be quite possible to have authenticated callers from unauthenticated network access, i.e., callers whose (billing) address and other identifying details would be known to the PSAP, or at least readily obtainable by normal legal means.

It may still be possible to get fake callers, if callers are willing to use stolen credit cards to establish a relationship to the VSP, or who use forged credentials with civic authorities, but that problem is presumably similar for regular cell phones (where the attraction to do that is larger, given the ability to get more useful services than just talking to a 911 operator).

To repeat myself: In that model, the 'sos' network access or some other token-based model is used, depending on the risk tolerance of the local wireless network provider (hotel, airport, Boingo, etc.). PAI or more sophisticated models are then used to authenticate the caller to the PSAP.

I don't know how PSAPs can object to that, given that this model doesn't exist today and has nothing to do with SIMless cell phones or whatever "unauthenticated" calls (pay phones?) they get today. I see such access as useful during time of cellular network stress (see 9/11, where cell phone usage in NYC was severely impaired, but the Internet worked just fine) and indoor usage (see Hilton Anaheim, where my cell phone ceases to work in the terminal room).

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 23 Mar 2010 18:40:40 -0400

You may find a recent article in CACM of interest. It argued, if I recall correctly, that the old role-based model of access control is actually not all that useful in many scenarios. The authors argued that, in many cases, a better model is to allow&audit, i.e., let people access information or resources and then deal with miscreants. This clearly doesn't work all the time, but in cases where the losses are bounded, this seems like a much more robust and simple-to-implement model. In this case, the ISP's potential losses are relatively minor (a bit of theoretical revenue loss); with the authentication token I mentioned, they can decide to go after the non-trivial abusers.

Henning

On Mar 23, 2010, at 11:58 AM, Richard Barnes wrote:

> Ah, ok, that makes sense.  So maybe we just need an "unauthenticated" token?  Still don't see anything really emergency-specific in this, besides specifying what constraints you might put on unauthenticated users.
> 
> --Richard
> 
> 
>