Subject: [Ecrit] Unauthenticated access review

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 29 Jun 2011 14:37:27 +0800

-02 is a considerable improvement over earlier iterations of this work.

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.

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

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

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.

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.

Cheers,
Martin