Subject: [Ecrit] [Fwd: Re: [earlywarning] Informal Gathering at IETF#77]

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 22 Mar 2010 10:34:50 -0400

Some of you might be interested in this activity.

-------- Original Message --------
Subject: 	Re: [earlywarning] Informal Gathering at IETF#77
Date: 	Mon, 22 Mar 2010 10:28:53 -0400
From: 	Hannes Tschofenig <[email-masked]>
To: 	[email-masked]
References: 	<[email-masked]>

Hi all,

I got a few responses to my mail and hence I would propose to meet on 
Wednesday from 13:00 to 15:00. 
I will try to find a room.

We would be working on the charter text.

Ciao
Hannes

Hannes Tschofenig wrote:
> Hi all,
>
> the IETF#77 meeting is getting closer and I was wondering whether some 
> of you would like to get together to chat about the charter text. We, 
> for some reason, got a bit struck with the wording of the charter.
>
> Drop me a mail if you are interested to chat about this topic!
>
> Ciao
> Hannes
>
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 22 Mar 2010 11:19:38 -0500

Some might also be attending TSVAREA (Wed 1300-1500) who has a 
mini-BoF on RSVP's future in the IETF. I at least will be in that 
meeting -- as will several ADs interested in this topic.

James

At 09:34 AM 3/22/2010, Hannes Tschofenig wrote:
>I got a few responses to my mail and hence I would propose to meet 
>on Wednesday from 13:00 to 15:00. I will try to find a room.
>
>>the IETF#77 meeting is getting closer and I was wondering whether 
>>some of you would like to get together to chat about the charter 
>>text. We, for some reason, got a bit struck with the wording of the charter.
>>
>Geopriv mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Kroeselberg, Dirk (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 22 Mar 2010 18:22:08 +0100

Bernard, 

continuing discussion from this morning's session: RFC5216 only seems to
have the following statement for unauthenticated emergency access:

"While the EAP server SHOULD require peer authentication, this is not
mandatory, since there are circumstances in which peer authentication
will not be needed (e.g., emergency services, as described in [UNAUTH]),
or where the peer will authenticate via some other means."

This is good and there is no reason to deviate from that. But it would
not be sufficient on its own to indicate emergency.

So what else is in existing RFCs that could be used (instead of the NAI
options presented in the unauthenticated draft)?

Thanks,
Dirk

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 22 Mar 2010 11:02:57 -0700

Dirk said:

"So what else is in existing RFCs that could be used (instead of the NAI
options presented in the unauthenticated draft)?"

RFC 5113 Section 2.3 describes how domain-based routing typically functions
in AAA networks, as well as the long-term problems with use of decorated
NAIs.  As noted there, NAI-routing depends on routing table entries
maintained on proxy servers.  

While an NAI like "emergency" will be routed to the local AAA server, and
"[email-masked]" will be routed to the AAA server at example.com
(assuming that this domain is reachable from the local network), the NAI
"[email-masked]" will result in routing to the AAA server
maintained within the emergency.com domain (assuming that this domain was
reachable from the local network).  As noted below, emergency.com is a real
domain, so this could result in a Denial of Service attack on the legitimate
owner of that domain. 

Diverting unauthenticated emergency services calls to an existing domain
that has not authorized use of its resources for that purpose is problematic
to say the least.  

; <<>> DiG 9.6.1-P3 <<>> @192.168.1.1 emergency.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8716
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;emergency.com.                 IN      A

;; ANSWER SECTION:
emergency.com.          3600    IN      A       205.243.133.2

;; Query time: 118 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Mon Mar 22 10:56:32 2010
;; MSG SIZE  rcvd: 47

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 22 Mar 2010 19:26:18 -0400

One model is that a visiting user discovers the local domain (via DHCP, say) and then uses a well-known NAI user name. For example, if a user visits a Hilton Hotel in Anaheim, he'd use

[email-masked]

Is that what you have in mind?

Henning

On Mar 22, 2010, at 2:02 PM, Bernard Aboba wrote:

> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit
>

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 22 Mar 2010 16:50:09 -0700

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. 

> CC: [email-masked]; [email-masked]
> From: [email-masked]
> Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of service attacks on the emergency.com domain)
> Date: Mon, 22 Mar 2010 19:26:18 -0400
> To: [email-masked]
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 22 Mar 2010 20:02:24 -0400

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

---

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

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

		
		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: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 22 Mar 2010 18:14:59 -0700

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)

Dirk

	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.

---

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

not sure I understand correctly, but this is not about tying emergency
procedures at higher layers to EAP usage. At least what I thought of is
that for 'unauthorized' cases (say an existing prepaid account with
insufficient credits for regular calls) the AAA would need to know this
is for emergency to take the right authorization decision.
 
Dirk 

	From: ext Joseph Salowey (jsalowey) [mailto:[email-masked]] 
	Sent: Tuesday, March 23, 2010 2:15 AM
	To: Kroeselberg, Dirk (NSN - DE/Munich); 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)

	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. 

		Henning

---

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)

Cc: [email-masked]

 

 

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

To: Bernard Aboba

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

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: Richard Barnes <[email-masked]>
Date: Mon, 22 Mar 2010 22:23:53 -0700

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.
>
>
>
> 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  
> covering unauthenticated and leaving the authenticated case open  
> seems less useful to me.
>
> Dirk
>
> 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

---

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

>> 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.
>>
>> 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: Richard Barnes <[email-masked]>
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: "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

---

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 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: 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]
> Date: Mon, 22 Mar 2010 22:43:28 -0700
>

---

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)
	> Doesn't it functionally amount to the same thing, though? Just
the 

	> >>> I do not think EAP or NAI should be used as a signaling
mechanism 

	> >>> Subject: Re: [Ecrit] emergency access and EAP-TLS (and
denial of 
	> >>> Subject: Re: [Ecrit] emergency access and EAP-TLS (and
denial of 
	> >>> The "sos" name seems to be a reasonable approach that's
simple and 
	> >>> easy.
local

---

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

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

---

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

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 disableable, and will be for a large number of cases
It's not a high priority

Brian

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 24 Mar 2010 05:14:51 +0800

> environments where there are some lawyers who think it's required to

The good thing is: we don't set policy here.  I'm not seeing sufficient evidence that _everyone_ doesn't want this, only that some don't want this.

I can't comment on priority.  That would be policy too.

--Martin

---

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

I think the relevant part of this is 'it's not a high priority'.  That is
policy of the work group, which we do have control over.

If we have nothing else more important to do, then by all means, let's waste
a ton of time on unauthenticated access.  If we have other work to do,
perhaps we could defer this.

I am not the chair, but in general, anyone can discuss anything, regardless
of "priority" on the list.  However, when it comes to adopting work group
items, I think this should be way down our list.

I might also suggest that unauthenticated access really isn't within the
charter of the work group.  It may be that the reason unauthenticated access
may be needed is for emergency calling, but that means we may (eventually)
need to ask some other work group to do work for a requirement we generate.
It would seem that dealing with EAP is not within the domain of this work
group.

Brian

On 3/23/10 5:14 PM, "Thomson, Martin" <[email-masked]> wrote:

> The good thing is: we don't set policy here.  I'm not seeing sufficient
> evidence that _everyone_ doesn't want this, only that some don't want this.
>

---

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

as spelled out by others already, we need to separate the aspects here.
So the 'unauthenticated' draft intends to cover

1) the VSP/ASP related part
2) the access/ISP part. 
3) unauthenticated access (no credentials)
4) unauthorized cases like empty prepaid account, roaming not allowed
etc, where credentials are available but do not allow regular access.

Considerations for 3) and 4) are different between the VSP/ASP and
access/ISP cases. For the VSP/ASP part, we probably do not need to care
a lot about 4), but for access/ISP this is different. And unfortunately
regulatory requirements for 4) are pretty different from the
unauthenticated case.

Now, regarding EAP: 
Up to now, IETF does not provide any recommendation for 3) and 4). This
made different organizations come up with different incompatible ways to
solve the problem.
The idea behind adding the EAP considerations to our draft was to
discuss whether IETF is able to recommend a common way. Any such
recommendation needs to cover both 3) and 4) (not just unauthenticated).

Dirk

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of ext Brian Rosen
> Sent: Tuesday, March 23, 2010 10:29 PM
> To: Thomson, Martin; Richard Barnes; Bernard Aboba
> >> A large percentage (in fact an overwhelming percentage) of 
> PSAPs DON'T
> >> WANT
> >> experience, and its all bad (tens of thousands of calls 
> with no good
> >> ones in
> >> some cases).
> >> 
> >> environments where there are some lawyers who think it's 
> required to
> >> support
> >> it in some environments.
> >

---

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

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 24 Mar 2010 06:43:55 +0800

To elaborate on Brian's "counter point" - some jurisdictions may prefer to *forbid* access to the emergency service from unauthenticated/anonymous access as opposed to *require* it to be supported. Noting this is the equivalent of saying emergency calls for circuit service cannot be made from public phone booths; this is still a possible policy within a given jurisdiction.

I'd also posit that not only is it not a priority for IETF but that the question actually needs to be dealt with in more specific forums first. The ECRIT emergency procedures occur at or above the IP layer. Before anything that ECRIT describes becomes relevant, there needs to be an IP context.

So - it's more the domain of the IEEE, 3GPP, WiFi Alliance, the DSL forum, etc. as to how a device is able to get an unauthenticated IP context on their technology, for whatever purpose, before the policies on permitting/prohibiting ECRIT procedures or anything else that can be done on IP can be applied. This is easier on some access technologies than it is on others. I doubt that there's a reasonable assumption that the connecting device can necessarily provide an explicit "emergency intent" flag.

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Wednesday, 24 March 2010 8:29 AM
To: Thomson, Martin; Richard Barnes; Bernard Aboba
Cc: [email-masked]; [email-masked]
Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain)

Brian

---

From: "Kroeselberg, Dirk (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 24 Mar 2010 00:14:08 +0100

> So - it's more the domain of the IEEE, 3GPP, WiFi Alliance, 
> the DSL forum, etc. as to how a device is able to get an 
> unauthenticated IP context on their technology, for whatever 
> purpose, before the policies on permitting/prohibiting ECRIT  

but what is the concrete recommendation that you want to give here?

- Drop the access/ISP part from the draft and say access/ISP is
out-of-scope?
- move this to EMU?
- or deal with the EAP/NAI related aspects outside IETF as you seem to
suggest (which is already partially the case today due to lack of
guidance)?

> is on others. I doubt that there's a reasonable assumption 
> that the connecting device can necessarily provide an 
> explicit "emergency intent" flag.
maybe this is why some people do this via the NAI ;-)

Dirk

> On Behalf Of ext Dawson, Martin
> Sent: Tuesday, March 23, 2010 11:44 PM
> To: Brian Rosen; Thomson, Martin; Richard Barnes; Bernard Aboba
> To elaborate on Brian's "counter point" - some jurisdictions 
> may prefer to *forbid* access to the emergency service from 
> unauthenticated/anonymous access as opposed to *require* it 
> to be supported. Noting this is the equivalent of saying 
> emergency calls for circuit service cannot be made from 
> public phone booths; this is still a possible policy within a 
> given jurisdiction.
> 
> I'd also posit that not only is it not a priority for IETF 
> but that the question actually needs to be dealt with in more 
> specific forums first. The ECRIT emergency procedures occur 
> at or above the IP layer. Before anything that ECRIT 
> describes becomes relevant, there needs to be an IP context.
> 
> So - it's more the domain of the IEEE, 3GPP, WiFi Alliance, 
> the DSL forum, etc. as to how a device is able to get an 
> unauthenticated IP context on their technology, for whatever 
> purpose, before the policies on permitting/prohibiting ECRIT 
> procedures or anything else that can be done on IP can be 
> applied. This is easier on some access technologies than it 
> is on others. I doubt that there's a reasonable assumption 
> that the connecting device can necessarily provide an 
> explicit "emergency intent" flag.
> 
> Cheers,
> Martin
> 
> On Behalf Of Brian Rosen

---

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]
> 
> It should be completely disablable, and will be for a large number of cases
> It's not a high priority
> 
> Brian
> 
>

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 24 Mar 2010 09:14:35 +0800

Consider the access out of scope, certainly. Recommend to access-specific forums that they shouldn't *assume* the connecting device is actually the device making the emergency call (e.g. a WiFi device on a portable 3G router) so there's no reliable assumption the connecting device can provide an emergency flag.

Then it's whatever ECRIT might recommend as appropriate on top of IP. I think Richard's questions are along the line of what the value of this specific "emergency flag" is at the IP level. It's not like anyone but the device user knows whether the access really is only required for emergency purposes. It's a valid question; access policy may just be to bar or allow (depending on whether it's a prohibitive or a permissive policy) access to emergency specific things - such as routes to PSAPs. A flag is not necessarily required to apply that sort of policy.

Cheers,
Martin

-----Original Message-----
From: Kroeselberg, Dirk (NSN - DE/Munich) [mailto:[email-masked]] 
Sent: Wednesday, 24 March 2010 10:14 AM
To: Dawson, Martin; Brian Rosen; Thomson, Martin; Richard Barnes; Bernard Aboba
Cc: [email-masked]; [email-masked]
Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain)

Dirk

---

From: "Kroeselberg, Dirk (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 24 Mar 2010 04:11:55 +0100

see inline.

Dirk 

> From: ext Dawson, Martin [mailto:[email-masked]] 
> Sent: Wednesday, March 24, 2010 2:15 AM
> To: Kroeselberg, Dirk (NSN - DE/Munich); Brian Rosen; 
> Thomson, Martin; Richard Barnes; Bernard Aboba
> Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial 
> Consider the access out of scope, certainly. Recommend to 
> access-specific forums that they shouldn't *assume* the 
> connecting device is actually the device making the emergency 
> call (e.g. a WiFi device on a portable 3G router) so there's 
> no reliable assumption the connecting device can provide an 
> emergency flag.

I do not see a value in such recommendation from IETF would be. 
For layer-2 flags these organizations define such flags. They know.
 
> Then it's whatever ECRIT might recommend as appropriate on 
> top of IP. I think Richard's questions are along the line of 
> what the value of this specific "emergency flag" is at the IP 
> level. 
What flag are you refering to? Up to now we were only discussing options
to indicate emergency in EAP, which rather on top of layer-2 than IP.

It's not like anyone but the device user knows whether 
> the access really is only required for emergency purposes. 
> It's a valid question; access policy may just be to bar or 
> allow (depending on whether it's a prohibitive or a 
> permissive policy) access to emergency specific things - such 
> as routes to PSAPs. A flag is not necessarily required to 
> apply that sort of policy.
Without a full subscription (either insufficient authorization or no
subscription) you may want to enter the NW for other things than
emergency. So would you always hotline these entrants to the PSAP?

> Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 24 Mar 2010 12:42:23 +0800

Hi Dirk,

> For layer-2 flags these organizations define such flags. They know.

SDOs set their own agendas; that's fair enough. They don't always want to consider how their architectures interwork with specifications defined by, say, the IETF. So perhaps, as you say, it's pointless. While ECRIT procedures are at the IP level and are intended to support clients that are connecting on IP via a routing device at the access, a "link technology SDO" may still persist with the assumption that it's the connecting device that negotiates procedures in an emergency scenario. Alternatively, they may consider the ECRIT model and decide to do something different. It is, as you say, up to them.

> to indicate emergency in EAP, which rather on top of layer-2 than IP.

Which, if I understand it, is about negotiating an IP context in what is also an "emergency context". Leaving aside my point above as to whether that's a generally effective facility for supporting emergency connectivity, there's also the question (which I may be unfairly be attributing to Richard) as to what value it is to the access to know that this connectivity has been granted in an "emergency context". What's it going to do with this alleged context?

> emergency. So would you always hotline these entrants to the PSAP?

No - you wouldn't. But, then, the concept of "hotlining the entrant to a PSAP" refers to a procedure that isn't described by ECRIT. There's no "hotlining". The device knows it wants to initiate an emergency call; it gets location from the LIS, gets the PSAP URI from LoST, and initiates a SIP session to the PSAP. The proposition of "hotlining" based on a layer 2 technology specific procedure is the sort of thing I refer to above. An access technology specific SDO may, for their own reasons, decide to define this sort of thing. I think they're talking about use cases that are orthogonal to what ECRIT is describing. ECRIT describes emergency procedures for the Internet, on IP, and independent of access technology.

I guess the extent to which an SDO thinks these things are worth developing depends on the extent to which they think a) ECRIT is not a significant model or to which b) they think there are "emergency" use cases that are outside the Internet domain or to which c) there is some complementary subset of use cases for their link technology (e.g. WiFi phones in an enterprise environment with an "emergency" button that set up an emergency IP context and are hotlined to the enterprise softswitch that then does ECRIT procedures to the outside world). The SDO just needs to decide whether there is a benefit consistent with the effort in defining/implementing such functionality. I think it's good if their delegates are aware of ECRIT in making that decision.

Cheers,
Martin

-----Original Message-----
From: Kroeselberg, Dirk (NSN - DE/Munich) [mailto:[email-masked]] 
Sent: Wednesday, 24 March 2010 2:12 PM
To: Dawson, Martin; Brian Rosen; Thomson, Martin; Richard Barnes; Bernard Aboba
Cc: [email-masked]; [email-masked]
Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain)

see inline.

Dirk

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 24 Mar 2010 18:55:26 +0800

Hi Andres,

Could you take us step by step through the establishment of the anonymous connection and the initiation of the emergency call and highlight where/how this notification mechanism would be invoked and what it would do?

I would find that helpful. I'm interested in how people see the access network being able to limit the use of an arbitrary third party VoIP application to emergency calling, if that's the intent, in the context of unauthenticated/anonymous access.

BTW, I haven't said that access is completely out of scope. Actually, it obviously is in scope both in terms of what facilities it provides and what its policies are with respect to emergency calling procedures in the context of unaurthenticated/anonymous connections. It's the concept of gating the establishment of unauthenticated/anonymous connections on some kind of a priori knowledge or indication that its for the purpose of an emergency call that I question.

Regards,
Martin

-----Original Message-----
From: Kutt, Andres [mailto:[email-masked]] 
Sent: Wednesday, 24 March 2010 9:31 PM
To: Dawson, Martin
Cc: [email-masked]; [email-masked]
Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain)

Hi,
    
    Leaving access completely out of scope is of course the easiest course
but some synchronization must remain. In case of Skype, there is no way for
the access provider to tell whether the user is placing an emergency call or
chatting with their friends as the protocol used is opaque for the outsider.
This is true in any case the service provider uses a protocol not known or
understood by access provider and we must assume this can legally occur.
Thus, should anonymous access be required, a mechanism must exist to notify
the access provider about an attempted emergency call.

Yours,
Andres 

On 3/24/10 3:14 AM, "Dawson, Martin" <[email-masked]> wrote:

> Consider the access out of scope, certainly. Recommend to access-specific
> forums that they shouldn't *assume* the connecting device is actually the
> device making the emergency call (e.g. a WiFi device on a portable 3G router)
> so there's no reliable assumption the connecting device can provide an
> emergency flag.
> 
> Then it's whatever ECRIT might recommend as appropriate on top of IP. I think
> Richard's questions are along the line of what the value of this specific
> "emergency flag" is at the IP level. It's not like anyone but the device user
> knows whether the access really is only required for emergency purposes. It's
> a valid question; access policy may just be to bar or allow (depending on
> whether it's a prohibitive or a permissive policy) access to emergency
> specific things - such as routes to PSAPs. A flag is not necessarily required
> to apply that sort of policy.
> 
> Cheers,
> Martin
>

---

From: "Kroeselberg, Dirk (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 24 Mar 2010 16:46:10 +0100

> facility for supporting emergency connectivity, there's also 
> the question (which I may be unfairly be attributing to 
> Richard) as to what value it is to the access to know that 
> this connectivity has been granted in an "emergency context". 
> What's it going to do with this alleged context?

Considering this in authorization decisions, QoS, setting IP filters
(limited access), priority. Just to give a few examples. 

> No - you wouldn't. But, then, the concept of "hotlining the 
> entrant to a PSAP" refers to a procedure that isn't described 
> by ECRIT. There's no "hotlining". The device knows it wants 

Right, but I was saying it is important for the access network to
recognize that the 'special' entry the MS wants to do is for emergency,
not let the access network roll dices.
Of course hotlining procedures are not in scope of ECRIT, there is
nothing emergency-specific besides installing the right filters (which
by the way we also discuss in the draft - should we also drop this?).

Dirk

> Sent: Wednesday, March 24, 2010 5:42 AM
> SDOs set their own agendas; that's fair enough. They don't 
> always want to consider how their architectures interwork 
> with specifications defined by, say, the IETF. So perhaps, as 
> you say, it's pointless. While ECRIT procedures are at the IP 
> level and are intended to support clients that are connecting 
> on IP via a routing device at the access, a "link technology 
> SDO" may still persist with the assumption that it's the 
> connecting device that negotiates procedures in an emergency 
> scenario. Alternatively, they may consider the ECRIT model 
> and decide to do something different. It is, as you say, up to them.
> 
> Which, if I understand it, is about negotiating an IP context 
> in what is also an "emergency context". Leaving aside my 
> point above as to whether that's a generally effective 
> facility for supporting emergency connectivity, there's also 
> the question (which I may be unfairly be attributing to 
> Richard) as to what value it is to the access to know that 
> this connectivity has been granted in an "emergency context". 
> What's it going to do with this alleged context?
> 
> No - you wouldn't. But, then, the concept of "hotlining the 
> entrant to a PSAP" refers to a procedure that isn't described 
> by ECRIT. There's no "hotlining". The device knows it wants 
> to initiate an emergency call; it gets location from the LIS, 
> gets the PSAP URI from LoST, and initiates a SIP session to 
> the PSAP. The proposition of "hotlining" based on a layer 2 
> technology specific procedure is the sort of thing I refer to 
> above. An access technology specific SDO may, for their own 
> reasons, decide to define this sort of thing. I think they're 
> talking about use cases that are orthogonal to what ECRIT is 
> describing. ECRIT describes emergency procedures for the 
> Internet, on IP, and independent of access technology.
> 
> I guess the extent to which an SDO thinks these things are 
> worth developing depends on the extent to which they think a) 
> ECRIT is not a significant model or to which b) they think 
> there are "emergency" use cases that are outside the Internet 
> domain or to which c) there is some complementary subset of 
> use cases for their link technology (e.g. WiFi phones in an 
> enterprise environment with an "emergency" button that set up 
> an emergency IP context and are hotlined to the enterprise 
> softswitch that then does ECRIT procedures to the outside 
> world). The SDO just needs to decide whether there is a 
> benefit consistent with the effort in defining/implementing 
> such functionality. I think it's good if their delegates are 
> aware of ECRIT in making that decision.
> 
> Cheers,
> Martin
> 
> > > >> unauthenticated access.  Their position is that they 
> have lots of
> > > >> relevant

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 25 Mar 2010 10:15:59 +0800

I'll describe a potential real world scenario before I try to answer your question.

* Public WiFi hotspots generally provide a "free unauthenticated and anonymous" IP context.

* Once connected to the access, users are generally "portal locked" to a single web page that requires further authentication/payment to proceed. The access may provide some additional "filters" that allow routes to some subset of news/commercial websites as a "bonus".

* In order to support unauthenticated/anonymous emergency calling at this point, the hotspot would need to add the location service, access to LoST, and a route to the relevant PSAP URI(s) to the filter list.

The question I raise is what would be done differently if the connecting device *could* have provided an indication that it wanted the connection for the purpose an emergency call? I don't think anything needs to be done differently. I don't, for example, think there's any prioritization benefit. An "emergency" type query to the LCP (HELD option), an emergency service lookup to LoST, and a SIP session directed toward a PSAP URI are all things that could be explicitly detected and given priority. Priority isn't an end-goal in itself in any case. The end goal is reliability and response time for these emergency related services. The access provider may need to ensure some service level there. They can do that without needing to roll dice. And, given they can neither rely on devices to provide an emergency indication nor trust that indication if they do, they are likely better off providing the necessary service level for emergency procedures independently of the device's broadc
 asted intentions.

Let me say that I think the draft is great; it crystallizes a lot of issues. I just think the section on EAP isn't necessary; it doesn't describe a generally applicable solution and its presence is likely to cause confusion as to its significance. In answer to your question; no, I don't suggest dropping the discussion on filters. I think that's a fundamental aspect; I think it's orthogonal to the concept of an "emergency intent indicator".

Cheers,
Martin

-----Original Message-----
From: Kroeselberg, Dirk (NSN - DE/Munich) [mailto:[email-masked]]
Sent: Thursday, 25 March 2010 2:46 AM
To: Dawson, Martin; Brian Rosen; Thomson, Martin; Richard Barnes; Bernard Aboba
Cc: [email-masked]; [email-masked]
Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain)

Dirk

---

From: "Kroeselberg, Dirk (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 25 Mar 2010 05:01:37 +0100

there is no EAP in your scenario as this is open WiFi, so of course any
EAP-based emergency indicator would not apply to it. However, there are
other scenarios.

So what you are basically saying with your example is that network
access authentication is only based on EAP for certain scenarios. Sure,
this is correct (not sure whether this is clear in the draft, I will
check). For open WiFi access we can only provide high-level guidance
like the one you describe below. 
For EAP this can be more specific, if something is agreeable. If not,
fine. However, looking at this whole thread, it makes much sense to me
to adjust and keep the section instead of not capturing the whole
discussion. 
What is probably missing at the moment are figures that clarify the
relation between access/ISP and VSP/ASP for unauthenticated and
unauthorized cases. We are planning to add such figures.

Dirk 

> Sent: Thursday, March 25, 2010 3:16 AM
> To: Kroeselberg, Dirk (NSN - DE/Munich)
> * Public WiFi hotspots generally provide a "free 
> unauthenticated and anonymous" IP context.
> 
> * Once connected to the access, users are generally "portal 
> locked" to a single web page that requires further 
> authentication/payment to proceed. The access may provide 
> some additional "filters" that allow routes to some subset of 
> news/commercial websites as a "bonus".
> 
> * In order to support unauthenticated/anonymous emergency 
> calling at this point, the hotspot would need to add the 
> location service, access to LoST, and a route to the relevant 
> PSAP URI(s) to the filter list.
> 
> The question I raise is what would be done differently if the 
> connecting device *could* have provided an indication that it 
> wanted the connection for the purpose an emergency call? I 
> don't think anything needs to be done differently. I don't, 
> for example, think there's any prioritization benefit. An 
> "emergency" type query to the LCP (HELD option), an emergency 
> service lookup to LoST, and a SIP session directed toward a 
> PSAP URI are all things that could be explicitly detected and 
> given priority. Priority isn't an end-goal in itself in any 
> case. The end goal is reliability and response time for these 
> emergency related services. The access provider may need to 
> ensure some service level there. They can do that without 
> needing to roll dice. And, given they can neither rely on 
> devices to provide an emergency indication nor trust that 
> indication if they do, they are likely better off providing 
> the necessary service level for emergency procedures 
> independently of the device's broadcasted intentions.
> 
> Let me say that I think the draft is great; it crystallizes a 
> lot of issues. I just think the section on EAP isn't 
> necessary; it doesn't describe a generally applicable 
> solution and its presence is likely to cause confusion as to 
> its significance. In answer to your question; no, I don't 
> suggest dropping the discussion on filters. I think that's a 
> fundamental aspect; I think it's orthogonal to the concept of 
> an "emergency intent indicator".
> 
> Cheers,
> Martin
> 
> 
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 24 Mar 2010 22:40:34 -0400

With non-web devices, it's becoming more common to have 802.1x as a second authentication option, beyond the splash page. (indeed, just yesterday I got word that my employer is transitioning to this, and this is how many, if not most, European universities work). The motivation is that entering authentication data on some WiFi devices, such as digital cameras or even smart phones, is painful. Thus, having a mode to bypass normal 802.1x processes for emergency purposes can be quite useful.

I don't think that this will be all that common immediately or even in the next year or two, but there's no reason not to encourage such new architectures if we believe they are useful for public safety. After all, I thought our goal is to enable (legitimate) emergency calls, not to prevent them.

As proposed, the system would allow unrestricted access for emergency purposes. I realize some have some difficulty fathoming why a provider would do this, but the cost to the ISP (or campus, or hotel) is minimal, so consider it the equivalent of providing pull boxes for fire alarms. I consider it the equivalent of a "emergency exit only" sign - they are abused rarely and there are processes in place to deal with abusers. You don't fix the problem by putting a stronger lock in front of the emergency exit. I guess you can consider it the "picket fence" theory of security. The "sos" user ID is essentially a picket fence that will allow socially useful behavior. 

Henning

---

From: Andres Kütt <[email-masked]>
Date: Fri, 26 Mar 2010 13:11:57 +0200

Hi,

    Certainly. Let's assume the following:
- existing UI implementation is used (i.e. the software provider will not
build a separate SIP client with distinct UI just for emergency calling)
- the client is multifunctional i.e. it is used for more things than calling
- the client has been authenticated already, this kind of software tends to
run in the background continuously
- there is no network connection

Given these assumptions EC  would work like this:
- user attempts to place an EC
- the client, being offline, attempts to re-establish it's session with the
network/server (i.e. get online)
- at this point, the access provider needs to know that the session being
established is for the purposes of an EC and needs to allow the connection
- session gets established with the server/network
- user attempts an emergency call
- the call reaches servers/network and is connected
- the call ends
- at this point there needs to be a way to drop the connection as the access
provider has no way of knowing whether the call has ended or not.

Please note that
- session establishment happens before the call and access provider has no
idea whether this is because of ordinary client use or EC. Remember, the
protocol used is opaque
- it is impossible for the client to know whether EC is even
allowed/implemented for a particular location before the session is
established
- because the protocol used is opaque, the access provider has no way to
distinguish between session establishment, an actual EC, ordinary IM traffic
or common web browsing (one could envision a VoIP application that uses HTTP
bindings for signaling purposes)

Thus, regardless of the methods used, the access provider needs to trust the
service provider to only use the connection for emergency calling and
nothing else.   

As for the session establishment, one way to do this is the way Skype Access
(you buy WIFI time using your Skype credit) works:
- the client wraps a session request in a DNS query against skype.com name
server. DNS is usually quite unrestricted but there are, of course,
exceptions
- single-use credentials are issued
- WISPr authentication is attempted using the credentials acquired
- the access provider attempts authentication against Skype
- session is established
- when the authentication session ends, the access provider attempts a
re-authenticate and terminates the connection should it fail

Yours,
Andres

On 3/24/10 12:55 PM, "Dawson, Martin" <[email-masked]> wrote:

> Hi Andres,
> 
> Could you take us step by step through the establishment of the anonymous
> connection and the initiation of the emergency call and highlight where/how
> this notification mechanism would be invoked and what it would do?
> 
> I would find that helpful. I'm interested in how people see the access network
> being able to limit the use of an arbitrary third party VoIP application to
> emergency calling, if that's the intent, in the context of
> unauthenticated/anonymous access.
> 
> BTW, I haven't said that access is completely out of scope. Actually, it
> obviously is in scope both in terms of what facilities it provides and what
> its policies are with respect to emergency calling procedures in the context
> of unaurthenticated/anonymous connections. It's the concept of gating the
> establishment of unauthenticated/anonymous connections on some kind of a
> priori knowledge or indication that its for the purpose of an emergency call
> that I question.
> 
> Regards,
> Martin
>

---

From: "Dawson, Martin" <[email-masked]>
Date: Sat, 27 Mar 2010 08:51:05 +0800

> bindings for signaling purposes)

I agree with this point. Effectively it says that the access has no way of knowing whether the third party application actually is just supporting an emergency call. Not only is it opaque but it has no control signalling relationship with the access either - so the access has no independent way to inform the application that the client is only supposed to be doing an emergency call.

I do not see how the "it's understood to be an emergency IP context" knowledge facilitates any of this policy control. Out of control is out of control.

On you first point about the UI implementation. I have... hang on... five applications on my Android device menu that do voice in one form or another. Frankly, it would be most convenient to have one there that just said "Emergency" and whose sole purpose was to do the ECRIT procedures (as described in this draft). That would be an ECRIT direct calling client. Access networks can most readily support policies that allow for this mode of use - without the third party trust issues that you raise.

Cheers,
Martin

-----Original Message-----
From: Andres Kütt [mailto:[email-masked]] 
Sent: Friday, 26 March 2010 10:12 PM
To: Dawson, Martin
Cc: [email-masked]; [email-masked]
Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain)

Hi,

Please note that

Yours,
Andres

---

From: <[email-masked]>
Date: Tue, 30 Mar 2010 02:17:16 +0200

In an RSNA enabled wifi network you are not redirected to a portal page, but rather authenticated (if you have the key) before getting associated. If you do not know the key, you can't associate, and can't send any 802.11 data packets to the AP. If there was an indication included in the EAP Request, then the AP would know that this STA is requesting association for emergency call purposes, and may be able to give access to it even if the STA is not in posession of the proper credentials (installing filters would still be necessary).

For open access wifi networks, the 802.11 specification has a slightly different solution than the one suggested below: the AP may be configured with multiple SSIDs, with one of them being dedicated for emergency call purposes. This is then signalled in the beacon frame. STAs willing to place an emergency call would first perform an active scan, identify the proper SSID and associate (RSNA is not supposed to be enabled).

-- Gabor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Dawson, Martin
Sent: Wednesday, March 24, 2010 7:16 PM
To: Kroeselberg, Dirk (NSN - DE/Munich)
Cc: [email-masked]; [email-masked]
Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain)

The question I raise is what would be done differently if the connecting device *could* have provided an indication that it wanted the connection for the purpose an emergency call? I don't think anything needs to be done differently. I don't, for example, think there's any prioritization benefit. An "emergency" type query to the LCP (HELD option), an emergency service lookup to LoST, and a SIP session directed toward a PSAP URI are all things that could be explicitly detected and given priority. Priority isn't an end-goal in itself in any case. The end goal is reliability and response time for these emergency related services. The access provider may need to ensure some service level there. They can do that without needing to roll dice. And, given they can neither rely on devices to provide an emergency indication nor trust that indication if they do, they are likely better off providing the necessary service level for emergency procedures independently of the device's broadc  asted intentions.

Cheers,
Martin

-----Original Message-----
From: Kroeselberg, Dirk (NSN - DE/Munich) [mailto:[email-masked]]
Sent: Thursday, 25 March 2010 2:46 AM
To: Dawson, Martin; Brian Rosen; Thomson, Martin; Richard Barnes; Bernard Aboba
Cc: [email-masked]; [email-masked]
Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain)

> facility for supporting emergency connectivity, there's also the
> question (which I may be unfairly be attributing to
> Richard) as to what value it is to the access to know that this
> connectivity has been granted in an "emergency context".

Considering this in authorization decisions, QoS, setting IP filters (limited access), priority. Just to give a few examples.

> No - you wouldn't. But, then, the concept of "hotlining the entrant to
> a PSAP" refers to a procedure that isn't described by ECRIT. There's
> no "hotlining". The device knows it wants

Right, but I was saying it is important for the access network to recognize that the 'special' entry the MS wants to do is for emergency, not let the access network roll dices.
Of course hotlining procedures are not in scope of ECRIT, there is nothing emergency-specific besides installing the right filters (which by the way we also discuss in the draft - should we also drop this?).

Dirk

> To: Kroeselberg, Dirk (NSN - DE/Munich); Brian Rosen; Thomson, Martin;
> Richard Barnes; Bernard Aboba
> SDOs set their own agendas; that's fair enough. They don't always want
> to consider how their architectures interwork with specifications
> defined by, say, the IETF. So perhaps, as you say, it's pointless.
> While ECRIT procedures are at the IP level and are intended to support
> clients that are connecting on IP via a routing device at the access,
> a "link technology SDO" may still persist with the assumption that
> it's the connecting device that negotiates procedures in an emergency
> scenario. Alternatively, they may consider the ECRIT model and decide
> to do something different. It is, as you say, up to them.
>
> Which, if I understand it, is about negotiating an IP context in what
> is also an "emergency context". Leaving aside my point above as to
> whether that's a generally effective facility for supporting emergency
> connectivity, there's also the question (which I may be unfairly be
> attributing to
> Richard) as to what value it is to the access to know that this
> connectivity has been granted in an "emergency context".
> No - you wouldn't. But, then, the concept of "hotlining the entrant to
> a PSAP" refers to a procedure that isn't described by ECRIT. There's
> no "hotlining". The device knows it wants to initiate an emergency
> call; it gets location from the LIS, gets the PSAP URI from LoST, and
> initiates a SIP session to the PSAP. The proposition of "hotlining"
> based on a layer 2 technology specific procedure is the sort of thing
> I refer to above. An access technology specific SDO may, for their own
> reasons, decide to define this sort of thing. I think they're talking
> about use cases that are orthogonal to what ECRIT is describing. ECRIT
> describes emergency procedures for the Internet, on IP, and
> independent of access technology.
>
> I guess the extent to which an SDO thinks these things are worth
> developing depends on the extent to which they think a) ECRIT is not a
> significant model or to which b) they think there are "emergency" use
> cases that are outside the Internet domain or to which c) there is
> some complementary subset of use cases for their link technology (e.g.
> WiFi phones in an enterprise environment with an "emergency" button
> that set up an emergency IP context and are hotlined to the enterprise
> softswitch that then does ECRIT procedures to the outside world). The
> SDO just needs to decide whether there is a benefit consistent with
> the effort in defining/implementing such functionality. I think it's
> good if their delegates are aware of ECRIT in making that decision.
>
> Cheers,
> Martin
>
> > To: Kroeselberg, Dirk (NSN - DE/Munich); Brian Rosen; Thomson,
> > Martin; Richard Barnes; Bernard Aboba
> > access-specific forums that they shouldn't *assume* the connecting
> > device is actually the device making the emergency call (e.g. a WiFi
> > device on a portable 3G router) so there's no reliable assumption
> > the connecting device can provide an emergency flag.
>
> > Then it's whatever ECRIT might recommend as appropriate on top of
> > IP. I think Richard's questions are along the line of what the value
> > of this specific "emergency flag" is at the IP level.
> What flag are you refering to? Up to now we were only discussing
> options to indicate emergency in EAP, which rather on top of layer-2
> than IP.
>
> > It's a valid question; access policy may just be to bar or allow
> > (depending on whether it's a prohibitive or a permissive policy)
> > access to emergency specific things - such as routes to PSAPs. A
> > flag is not necessarily required to apply that sort of policy.
> > > So - it's more the domain of the IEEE, 3GPP, WiFi Alliance, the
> > > DSL forum, etc. as to how a device is able to get an
> > > is on others. I doubt that there's a reasonable assumption that
> > > the connecting device can necessarily provide an explicit
> > > "emergency intent" flag.
> > > Behalf Of ext Dawson, Martin
> > > To elaborate on Brian's "counter point" - some jurisdictions may
> > > prefer to *forbid* access to the emergency service from
> > > unauthenticated/anonymous access as opposed to *require* it to be
> > > supported. Noting this is the equivalent of saying emergency calls
> > > for circuit service cannot be made from public phone booths; this
> > > is still a possible policy within a given jurisdiction.
> > >
> > > I'd also posit that not only is it not a priority for IETF but
> > > that the question actually needs to be dealt with in more specific
> > > forums first. The ECRIT emergency procedures occur at or above the
> > > IP layer. Before anything that ECRIT describes becomes relevant,
> > > there needs to be an IP context.
> > >
> > > So - it's more the domain of the IEEE, 3GPP, WiFi Alliance, the
> > > DSL forum, etc. as to how a device is able to get an
> > > procedures or anything else that can be done on IP can be applied.
> > > This is easier on some access technologies than it is on others. I
> > > doubt that there's a reasonable assumption that the connecting
> > > device can necessarily provide an explicit "emergency intent"
> > > flag.
> > >
> > > Cheers,
> > > Martin
> > >
> > > Behalf Of Brian Rosen
> > > I think the relevant part of this is 'it's not a high priority'.
> > > That is policy of the work group, which we do have control over.
> > >
> > > If we have nothing else more important to do, then by all means,
> > > let's waste a ton of time on unauthenticated access.  If we have
> > > other
> > work to do,
> > > I am not the chair, but in general, anyone can discuss anything,
> > > regardless of "priority" on the list.  However, when it comes to
> > > adopting work group items, I think this should be way down our
> > > list.
> > >
> > > I might also suggest that unauthenticated access really isn't
> > > within the charter of the work group.  It may be that the reason
> > > unauthenticated access may be needed is for emergency calling, but
> > > that means we may
> > > (eventually)
> > > It would seem that dealing with EAP is not within the domain of
> > > this work group.
> > >
> > > Brian
> > >
> > >
> > > >> 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.
> > > >

---

From: Richard Barnes <[email-masked]>
Date: Mon, 29 Mar 2010 20:23:01 -0400

Why is this an issue for open APs?  Priority?
--Richard

On Mar 29, 2010, at 8:17 PM, <[email-masked]> wrote:

> In an RSNA enabled wifi network you are not redirected to a portal  
> page, but rather authenticated (if you have the key) before getting  
> associated. If you do not know the key, you can't associate, and  
> can't send any 802.11 data packets to the AP. If there was an  
> indication included in the EAP Request, then the AP would know that  
> this STA is requesting association for emergency call purposes, and  
> may be able to give access to it even if the STA is not in posession  
> of the proper credentials (installing filters would still be  
> necessary).
>
> For open access wifi networks, the 802.11 specification has a  
> slightly different solution than the one suggested below: the AP may  
> be configured with multiple SSIDs, with one of them being dedicated  
> for emergency call purposes. This is then signalled in the beacon  
> frame. STAs willing to place an emergency call would first perform  
> an active scan, identify the proper SSID and associate (RSNA is not  
> supposed to be enabled).
>
> -- Gabor
>
>
> * Once connected to the access, users are generally "portal locked"  
> to a single web page that requires further authentication/payment to  
> proceed. The access may provide some additional "filters" that allow  
> routes to some subset of news/commercial websites as a "bonus".
>
> * In order to support unauthenticated/anonymous emergency calling at  
> this point, the hotspot would need to add the location service,  
> access to LoST, and a route to the relevant PSAP URI(s) to the  
> filter list.
>
> connecting device *could* have provided an indication that it wanted  
> the connection for the purpose an emergency call? I don't think  
> anything needs to be done differently. I don't, for example, think  
> there's any prioritization benefit. An "emergency" type query to the  
> LCP (HELD option), an emergency service lookup to LoST, and a SIP  
> session directed toward a PSAP URI are all things that could be  
> explicitly detected and given priority. Priority isn't an end-goal  
> in itself in any case. The end goal is reliability and response time  
> for these emergency related services. The access provider may need  
> to ensure some service level there. They can do that without needing  
> to roll dice. And, given they can neither rely on devices to provide  
> an emergency indication nor trust that indication if they do, they  
> are likely better off providing the necessary service level for  
> emergency procedures independently of the device's broadc
>   asted intentions.
>
> Let me say that I think the draft is great; it crystallizes a lot of  
> issues. I just think the section on EAP isn't necessary; it doesn't  
> describe a generally applicable solution and its presence is likely  
> to cause confusion as to its significance. In answer to your  
> question; no, I don't suggest dropping the discussion on filters. I  
> think that's a fundamental aspect; I think it's orthogonal to the  
> concept of an "emergency intent indicator".
>
> Cheers,
> Martin
>
>
>
> recognize that the 'special' entry the MS wants to do is for  
> emergency, not let the access network roll dices.
> nothing emergency-specific besides installing the right filters  
> (which by the way we also discuss in the draft - should we also drop  
> this?).
>
> Dirk
>

---

From: <[email-masked]>
Date: Tue, 30 Mar 2010 02:32:46 +0200

"open AP" does not always mean access to Internet. It may, but in many cases you end up being redirected to a portal page and required to pay. With the dedicated SSID, you know in advance that you'll get access to ES and not redirected to a portal page.

-- gabor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Richard Barnes
Sent: Monday, March 29, 2010 5:23 PM
To: Bajko Gabor (Nokia-CIC/MtView)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain)

On Mar 29, 2010, at 8:17 PM, <[email-masked]> wrote:

> associated. If you do not know the key, you can't associate, and can't
> send any 802.11 data packets to the AP. If there was an indication
> included in the EAP Request, then the AP would know that this STA is
> requesting association for emergency call purposes, and may be able to
> give access to it even if the STA is not in posession of the proper
> credentials (installing filters would still be necessary).
>
> For open access wifi networks, the 802.11 specification has a slightly
> different solution than the one suggested below: the AP may be
> configured with multiple SSIDs, with one of them being dedicated for
> emergency call purposes. This is then signalled in the beacon frame.
> STAs willing to place an emergency call would first perform an active
> scan, identify the proper SSID and associate (RSNA is not supposed to
> be enabled).
>
> -- Gabor
>
>
> Of ext Dawson, Martin
> this point, the hotspot would need to add the location service, access
> to LoST, and a route to the relevant PSAP URI(s) to the filter list.
>
> explicitly detected and given priority. Priority isn't an end-goal in
> itself in any case. The end goal is reliability and response time for
> these emergency related services. The access provider may need to
> ensure some service level there. They can do that without needing to
> roll dice. And, given they can neither rely on devices to provide an
> emergency indication nor trust that indication if they do, they are
> likely better off providing the necessary service level for emergency
> procedures independently of the device's broadc
>   asted intentions.
>
> describe a generally applicable solution and its presence is likely to
> cause confusion as to its significance. In answer to your question;
> no, I don't suggest dropping the discussion on filters. I think that's
> a fundamental aspect; I think it's orthogonal to the concept of an
> "emergency intent indicator".
>
> Cheers,
> Martin
>
>
>
> From: Kroeselberg, Dirk (NSN - DE/Munich)
> [mailto:[email-masked] ]
>> No - you wouldn't. But, then, the concept of "hotlining the entrant
>> to a PSAP" refers to a procedure that isn't described by ECRIT.
>> There's no "hotlining". The device knows it wants
>