Subject: [Ecrit] Unauthenticated Network Access

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 14 Apr 2007 23:01:40 +0200

Hi all,

at the SDO Emergency Services workshop we had a chat about 
unauthenticated network access. We concluded that we don't have good 
terminology and some of us did not like the concept. Nevertheless, I 
believe we need to provide a story for it.

Here are some thoughts. I believe that there are at least two flavors of 
"unauthenticated" that need to be considered here:

a) The end host does not have credentials for network access.
b) The end host does not have credentials for VoIP access.

In case of (a) you need to differentiate between public hotspots and 
networks that are access controlled (for whatever  reason, including 
monetary). With public hotspots that offer free-for-all service there 
are no problems since you don't perform an authentication procedure 
anyway. In case the network is access controlled the network 
administrator/network operator needs to ensure that an entity that 
claims to do an emergency call indeed does so (since otherwise there is 
a big security hole that opens doors for fraud). Hence, the access 
network (or an associated entity) needs some application layer knowledge.

In case of (b) the access network provider (or an  associated entity) 
needs to offer SIP proxy functionality since the end host per-definition 
does not have a "home" network.

In a summary there are the following cases:

Case A: No credentials for network access authentication BUT credentials 
for VoIP access

Case B: Credentials for network access authentication BUT NO credentials 
for VoIP access

In these two cases it is necessary to deploy a SIP proxy in the access 
network (or to make use of a SIP proxy that has a relationship to the 
access network; one could call it outsourcing model).

So, the important question now is:

How do we discover this proxy in the access / proxy related to the 
access network?

1) Can we make use of RFC3319 / RFC3361 (Dynamic Host Configuration 
Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers"?

OR

2) Do we need a new document that describes this functionality?

I believe that we could go for (1), i.e., no new functionality needed.

Ciao
Hannes

PS: Note that Case A potentially requires additional treatment described 
in a separate mail.

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 14 Apr 2007 19:15:55 -0400

Hannes,

see my other note on location-less PSAP discovery. Finding an  
'emergency proxy' is just another item of UA configuration, again  
based on the local access network. Doing configuration in half a  
dozen different ways, with unclear precedence and relationships, is  
just a recipe for complexity and interoperability problems. Either we  
believe that the SIP configuration work addresses our configuration  
needs, or we should stop that work and do something that does.

Henning

On Apr 14, 2007, at 5:01 PM, Hannes Tschofenig wrote:

> unauthenticated network access. We concluded that we don't have  
> good terminology and some of us did not like the concept.  
> Nevertheless, I believe we need to provide a story for it.
>
> Here are some thoughts. I believe that there are at least two  
> flavors of "unauthenticated" that need to be considered here:
>
> In case of (a) you need to differentiate between public hotspots  
> and networks that are access controlled (for whatever  reason,  
> including monetary). With public hotspots that offer free-for-all  
> service there are no problems since you don't perform an  
> authentication procedure anyway. In case the network is access  
> controlled the network administrator/network operator needs to  
> ensure that an entity that claims to do an emergency call indeed  
> does so (since otherwise there is a big security hole that opens  
> doors for fraud). Hence, the access network (or an associated  
> entity) needs some application layer knowledge.
>
> In case of (b) the access network provider (or an  associated  
> entity) needs to offer SIP proxy functionality since the end host  
> per-definition does not have a "home" network.
>
> Case A: No credentials for network access authentication BUT  
> credentials for VoIP access
>
> Case B: Credentials for network access authentication BUT NO  
> credentials for VoIP access
>
> In these two cases it is necessary to deploy a SIP proxy in the  
> access network (or to make use of a SIP proxy that has a  
> relationship to the access network; one could call it outsourcing  
> model).
>
> PS: Note that Case A potentially requires additional treatment  
> described in a separate mail.
>
>