Subject: Re: [Ecrit] Unauthenticated access review

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 5 Jul 2011 23:15:51 +0300

Hi Martin, 

thank you for your review comments. 

On Jun 29, 2011, at 9:37 AM, Thomson, Martin wrote:

> -02 is a considerable improvement over earlier iterations of this work.
> 
Glad to hear that. 

> I'm a little concerned about the suggested flow for NAA, specifically the potential for abuse and what options are available for an operator.  The security considerations discusses this issue reasonably well, but it takes a fairly weak position, preferring to shunt the problem than deal with it outright.

The No Access Authentication (NAA) case is indeed interesting and the current definition covers the case where the emergency caller does not possess valid credential for network access when those are needed for getting access to the Internet. 
In many cases today a host is able to use the Internet without having to go through a network access authentication procedure. These free hotspots are not really discussed in that section and wouldn't really present a problem as such. 

Having said that the security consideration section, as you state indeed discusses the issue and proposed one possible solution approach. The main issue I believe is that the LoST server can be provisioned to return any ESRP URI back. Quite naturally that URI  may not be the URI of the PSAP but it may just get the call closer to the PSAP. Hence, if the LoST server contains a ESRP URI that points to a VSP/ASP someone then the ISP would configure the firewall setting in such a way that it would essentially allow communication with that arbitrary VSP/ASP. 

You phrase it in another way but I believe we are essentially saying the same: 

> 
> From the perspective of an operator, the potential for abuse is increased when they have to permit signaling to an arbitrary ASP.  Permitting the path to anything other than NASP from NAA reduces an operator's ability to constrain network access.  In NASP, the ISP need only provide access to a LIS, a LoST server and the emergency services network.  Normal call procedures are great, but it is a lot harder to constrain access when you can't predict what ASP a device is going to use.  
> 

So, there is nothing wrong with the currently presented solution but it maybe we need to highlight a bit more that an ISP may want to make sure that the entries in the LoST server actually point to ESRPs belonging to the ESINet for that specific region if the described threat is a concern. 

Since we demand LoST server discovery using DHCP I don't see a problem with the ISP ensuring that the presented information is indeed what is desired (unless there is no way to configure the end host with a DHCP server; a discussion we also had in the past ....). 

> Of course, constraints might not be Boolean condition - an operator might limit bandwidth on emergency-only access.  But in a world where IP over DNS is/was a reality, I'd want to be able to do better than that.
> 
> 
> Does this work better for Section 4?
> 
>>>> 
>   ZBP includes all cases where a subscriber is known to an ASP, but lacks the necessary authorization to access regular ASP services.  Example ZBP cases include empty prepaid accounts, barred accounts, roaming and mobility restrictions, or any other conditions set by ASP policy.
> 	
>   Local regulation might demand that emergency calls are always authorized.  An ASP can identify emergency sessions by identifying the service URN [50xx] used in call setup.  Emergency calls can then be authorized accordingly.  The ZBP case therefore only affects the ASP.
> 
>   Permitting a call with limited authorization could present an opportunity for abuse.  The ASP MAY choose to validate session initiation messages for valid destinations, see Section 7.
> 
>   An ASP without a regulatory requirement to authorize emergency calls can deny emergency call setup.  Where an ASP does not authorize an emergency call, the caller can fall back to NASP procedures.
> <<<
> 

I am not sure I understand this comment. Is this a text proposal? Would it replace the text in Section 4 or is it additional text? 

> 
> Section 5
> 
> Section 5 duplicates a lot of the recommendations from phone-bcp.  In fact, it's difficult to identify how this draft differs from phone-bcp.  It should only be necessary to call out the points of divergence here (which are few).  For instance, the ESRP section could just say "follow [phone-bcp]".  Even the ISP/IAP section could say the same, with a possible reference to the NAA section regarding constrained access.
> 
> What is missing from 5.1.2 is the SIP-based discovery of the ESRP - if the End Host is sending signaling straight to the ESRP, it will probably have to use RFC 3263.
> 
> 

This is indeed a matter of taste. Referencing Phone BCP and to tell what is different is one option. Another one is presented in this document - we spell out what needs to be done for the presented case. I believe that this is shorter and easier to understand. 
I don't think that a reference to RFC 3263 is needed. The URI scheme of the ESRP URI will determine what discovery mechanisms is to be used. We aren't going to reference XMPP specs here either although one could image that a LoST response may contain such a URI. 

> Section 6
> 
> In spite of considerable improvements over prior iterations, I still think that Section 6 is too specific in parts and too vague in others.  
> 
> - (Section 6.1) The reasons for NOT doing something do not need to be so exhaustively enumerated.  In particular, I found the last two points (EAP and NAI) a little baffling and non-sequitur.
> 
> - Section 6.2 makes some non-specific recommendations about securing layer 2 communications, but doesn't really elucidate why.  One good reason for securing layer 2, with strong mutual authentication is that most of the configuration (LIS, LoST, SIP) use a DHCP bootstrap, and DHCP has no authentication framework.  Again, for the reasons cited in Section 6.1, anything more concrete is going to be hard to justify.
> 
> Oh, and...
> 
> Expand Acronyms Prior to using them.  They are Not Always Intuitive.
> 

I will have to ask Dirk for feedback since he wrote this section. I only want to say that this section is informative since the procedures for link layer emergency service indications are, as the name indications, link layer specific and therefore outside the IETF. We will have to follow whatever the link layer procedures are, I believe.  

Ciao
Hannes

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 11 Jul 2011 14:28:42 +0800

Hi Hannes,

On 2011-07-06 at 06:15:51, Hannes Tschofenig wrote:
> > I'm a little concerned about the suggested flow for NAA, 
> > specifically
> the potential for abuse and what options are available for an operator.
> The security considerations discusses this issue reasonably well, but 
> it takes a fairly weak position, preferring to shunt the problem than 
> deal with it outright.
> 
> The No Access Authentication (NAA) case is indeed interesting and the 
> current definition covers the case where the emergency caller does not 
> possess valid credential for network access when those are needed for 
> getting access to the Internet.
> In many cases today a host is able to use the Internet without having 
> to go through a network access authentication procedure. These free 
> hotspots are not really discussed in that section and wouldn't really 
> present a problem as such.
> 
> Having said that the security consideration section, as you state 
> indeed discusses the issue and proposed one possible solution approach.
> The main issue I believe is that the LoST server can be provisioned to 
> return any ESRP URI back. Quite naturally that URI  may not be the URI 
> of the PSAP but it may just get the call closer to the PSAP. Hence, if 
> the LoST server contains a ESRP URI that points to a VSP/ASP someone 
> then the ISP would configure the firewall setting in such a way that 
> it would essentially allow communication with that arbitrary VSP/ASP.

I actually don't think that you are saying the same thing.  But I could just be a little confused.

When a LoST server identifies something, that thing becomes an ESRP, regardless of who operates it.  Talking about a VSP/ASP being identified by a LoST server is very confusing.

When a LoST server identifies an ESRP, then it's not arbitrary.

> >
> > From the perspective of an operator, the potential for abuse is
> increased when they have to permit signaling to an arbitrary ASP.
> Permitting the path to anything other than NASP from NAA reduces an 
> operator's ability to constrain network access.  In NASP, the ISP need 
> only provide access to a LIS, a LoST server and the emergency services 
> network.  Normal call procedures are great, but it is a lot harder to 
> constrain access when you can't predict what ASP a device is going to 
> use.
> >
> 
> So, there is nothing wrong with the currently presented solution but 
> it maybe we need to highlight a bit more that an ISP may want to make 
> sure that the entries in the LoST server actually point to ESRPs 
> belonging to the ESINet for that specific region if the described 
> threat is a concern.

There is something wrong with the currently presented solution.  It requires that the ISP permit access to arbitrary ASPs.

For NAA, the caller gains limited access to the network, then they follow -phone-bcp, which uses their normal ASP.  The ISP cannot possibly identify communications directed at this (arbitrary) ASP as being permitted.

> Since we demand LoST server discovery using DHCP I don't see a problem 
> with the ISP ensuring that the presented information is indeed what is 
> desired (unless there is no way to configure the end host with a DHCP 
> server; a discussion we also had in the past ....).

Requiring LoST discovery is a necessary condition.  That bit is good.  (and let's pretend that the discussion was fruitfully concluded...)

> > Does this work better for Section 4?
[...]
> > <<<
> >
> 
> I am not sure I understand this comment. Is this a text proposal? 
> Would it replace the text in Section 4 or is it additional text?

Text proposal for replacement.  

I was struggling with the definition and it was the last paragraph that made it possible to understand it.  I tried shuffling contents, and the above is what came out.
 
> >
> > Section 5
> >
> > Section 5 duplicates a lot of the recommendations from phone-bcp.  
> > In
> fact, it's difficult to identify how this draft differs from phone-bcp.
> It should only be necessary to call out the points of divergence here 
> (which are few).  For instance, the ESRP section could just say 
> "follow [phone-bcp]".  Even the ISP/IAP section could say the same, 
> with a possible reference to the NAA section regarding constrained access.
> >
> > What is missing from 5.1.2 is the SIP-based discovery of the ESRP -
> if the End Host is sending signaling straight to the ESRP, it will 
> probably have to use RFC 3263.
> >
> >
> 
> This is indeed a matter of taste. Referencing Phone BCP and to tell 
> what is different is one option. Another one is presented in this 
> document - we spell out what needs to be done for the presented case. 
> I believe that this is shorter and easier to understand.

I found it more confusing.  While it is easier to follow than -phone-bcp, it's hard to identify what is different.  Can I request that you at least summarize the differences.

> I don't think that a reference to RFC 3263 is needed. The URI scheme 
> of the ESRP URI will determine what discovery mechanisms is to be 
> used. We aren't going to reference XMPP specs here either although one 
> could image that a LoST response may contain such a URI.

Good point.  You don't need to reference 3263 specifically, but note that server discovery is going to be involved.  Such a thing can be missed in setting up a network.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 11 Jul 2011 00:28:53 -0700

> For NAA, the caller gains limited access to the network, then they follow -phone-bcp, which uses their normal ASP.  The ISP cannot possibly identify communications directed at this (arbitrary) ASP…

[BA] I agree.  The currently presented solution isn't deployable even when the signaling traffic is sent in the clear. 

When it is encrypted, it is totally unworkable.

> Good point.  You don't need to reference 3263 specifically, but note that server discovery is going to be involved.  Such a thing can be missed in setting up a network.

The problem is that Web Portals aren't compatible with RFC 3263 (due to DNS spoofing).

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 12 Jul 2011 08:31:26 +0800

On 2011-07-11 at 17:28:53, Bernard Aboba wrote:
> ...DNS spoofing...

DNS spoofing is a real pain, but maybe it's not a problem we need to concern ourselves with.  There's plenty of other big problems with unauthenticated access.

I propose that we add text that describes the potential problems.  Then, we say that those who employ DNS spoofing are not capable of providing unauthenticated access for emergency purposes for those reasons.

If they aren't required to provide unauthenticated access, then hotspot operators can continue to spoof DNS.

--Martin

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 11 Jul 2011 20:46:12 -0400

In that spirit: I don't think we're trying to backport unauthenticated access onto unchanged networks. At best, we're trying to tell operators who want to (or whose local regulator makes them) provide such a service what they would have to do to make it work.

There's a set of problems that makes VoIP access in networks difficult, emergency or not, but Skype has shown that this is surmountable. (They seem to have worked out an arrangement with many WiFi operators in public hot spots that you can pay through them by the minute, and make phone calls, without a browser interaction.) That's not quite unauthenticated access, but it's another model that could work where the caller does not have a direct customer relationship with the WiFi provider.

While they are not as ubiquitous as Boingo, there are a number of wireless networks that may not care as much about revenue issues. For example, many hotels and public park hot spots provide a splash page mainly to get visitors to agree to various appropriate usage policies. They may well be willing to run the risk that somebody "fakes" an emergency call to bypass the splash page - from their perspective, it would be really hard to argue that they didn't see the warning against file sharing because they faked an emergency call. Not something you are going to tell a judge. Allowing a connection to an outbound SIP proxy would do the trick in that case.

Henning

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 11 Jul 2011 18:46:23 -0700

Agree on describing the issues and recommending non-spoofing (e.g open, WPA2) approaches to unauthn/unauthz access.  

> From: [email-masked]
> To: [email-masked]; [email-masked]
> CC: [email-masked]
> Date: Tue, 12 Jul 2011 08:31:26 +0800
> Subject: RE: [Ecrit] Unauthenticated access review
>