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 protected] [mailto:[email protected]] On Behalf Of Richard Barnes Sent: Tuesday, 23 March 2010 4:24 PM To: Bernard Aboba Cc: [email protected]; [email protected] Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of serviceattacks on the emergency.com domain) In particular, providing unauthenticated *network* access is a prerequisite for providing unauthenticated *VoIP* access. Also, Bernard: Does your below mention of "anonymous" NAI indicate that there is actually a reserved NAI "anonymous"? If so, then I don't really see the use for a separate "sos" NAI -- you can just provide ECRIT access to "anonymous". --Richard On Mar 22, 2010, at 6:28 PM, Bernard Aboba wrote: > Part of the confusion here may be that we're talking about > "unauthenticated" at multiple layers. There is unauthenticated > network access, and then there is unauthenticated VOIP signaling. > > These are two orthogonal things. The VOIP signaling should not > change regardless of whether the network access is authenticated or > unauthenticated. > > Similarly, it's possible to use authenticated or unauthenticated > VOIP signaling over authenticated or unauthenticated access. > > Focusing solely on how to obtain "unauthenticated" access, the > question is how the client signals that it is interested in > "unauthenticated" access. This is important, because otherwise the > server might request client authentication (e.g. a client > certificate request). Essentially the "sos" NAI is functioning > similar to the "anonymous" NAI in that this results in special > processing on the AAA server side. > > > > Subject: RE: [Ecrit] emergency access and EAP-TLS (and denial of > serviceattacks on the emergency.com domain) > Date: Mon, 22 Mar 2010 18:14:59 -0700 > From: [email protected] > To: [email protected]; [email protected]; [email protected] > CC: [email protected] > > 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 protected] [mailto:[email protected]] On > Behalf Of Kroeselberg, Dirk (NSN - DE/Munich) > Sent: Monday, March 22, 2010 5:26 PM > To: ext Henning Schulzrinne; Bernard Aboba > Cc: [email protected] > 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 protected]] > Sent: Tuesday, March 23, 2010 1:02 AM > To: Bernard Aboba > Cc: Kroeselberg, Dirk (NSN - DE/Munich); [email protected] > Subject: Re: [Ecrit] emergency access and EAP-TLS (and denial of > service attacks on the emergency.com domain) > > The "sos" name seems to be a reasonable approach that's simple and > easy. > > Longer term, I think a better option is to have a semi-authenticated > mode: Imagine a setup where VSPs or other trustable bodies hand out > tokens (e.g., using the OAuth-WARP work) that the ISP recognizes. > The ISP is given the right to monitor the usage of 'sos' sessions > and can hand the token to the appropriate authorities for > prosecution in case of abuse. That way, you get emergency access, > but make it unlikely that the system will be abused on a large > scale. In some countries, you might get such a token from your local > public authority when you're registering your residence. > > Henning > > On Mar 22, 2010, at 7:50 PM, Bernard Aboba wrote: > > > If all you want to do is to gain emergency access to the local > network, you don't need to discover the domain. You can just use an > NAI of "sos". That will be more convenient in situations where the > local access mechanism (e.g. 802.1X) doesn't permit IP packets > (including DHCP) to pass prior to completing authentication, so that > "domain discovery" couldn't occur until afterwards. > > > _______________________________________________ > Ecrit mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list [email protected] https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
