Re: [Emu] Review ofdraft-schulzrinne-ecrit-unauthenticated-access-07.txt

["Kroeselberg, Dirk (NSN - DE/Munich)" <[e-mail]>]

the next update will incorporate the review comments, also those copied
below. -07 does not incorporate feedback or proposals yet (e.g. 'use
decoration'. Instead we took out some sections for now) because
discussion is ongoing. Maybe the slides this morning were misleading,
but the -07 version does not propose any specific way to indicate
unauthenticated emergency to the access/ISP. So we are still in the
phase of figuring out whether one of the methods is be agreable.
 
We can include the proposal to use a NAI "emergency" of course. For
this, there is the question of how to indicate emergency in a
non-'unauthenticated' case that uses a regular NAI. It would be good to
use the same mechansims for unauthenticated and authenticated access.
 
> focus on enabling unauthenticated emergency access with as few changes
to existing standards as possible.
Agreed. But also my understanding from discussion up to now is that
there is support for providing guidance from IETF instead of continuing
to leverage proprietary methods with not providing such guidance.
 
Thanks,
Dirk


________________________________

	From: [e-mail] [mailto:[e-mail]] On
Behalf Of ext Bernard Aboba
	Sent: Monday, March 22, 2010 6:29 PM
	To: [e-mail]; [e-mail]
	Subject: [Emu] Review
ofdraft-schulzrinne-ecrit-unauthenticated-access-07.txt
	
	

	Looking over -07, it does not appear that the review comments on
-06 were addressed. 

	 

	In addition, the presentation to ECRIT today referred to "no
objections" to use of a decorated NAI to signal emergency usage. 

	 

	It's not clear to me why this is necessary (e.g. why use of an
"emergency" user name wouldn't work), or whether the implications for
deployment are understood, given that decoration may require specialized
proxy handling and potential changes to AAA servers. 

	 

	By referring to use of non-existent domains (e.g. emergency.com)
and a requirement for new EAP methods, and now adding a decorated NAI
requirement, this draft is creating unnecessary barriers to gaining
network access for the purposes of making an emergency call.  I'd
suggest that the document rethink the approach, and focus on enabling
unauthenticated emergency access with as few changes to existing
standards as possible. 

	 

	-----Original Message-----

	 Joe Salowey said:

	 

	"I agree with Bernard's comments on section 6 of this draft.  
	 
	I would like to emphasize the following:
	 
	- I'm a bit concerned about using an EAP method type to indicate
	emergency authentication.  The EAP method type should be
orthogonal to
	whether emergency access is requested or not.  Combining the two
will
	cause and artificial linkages between the two and likely cause
problems
	down the road.  For this reason I am strongly against options
2.a and
	2.c in section 6.2.
	 
	- In section 6.3, I don't think that anonymous cipher suites or
	publically known shared keys are a good idea.  In general, a
server
	authenticated method using public key certificates can be used.
If the
	client is in an emergency it can forgo certificate validation to
get
	access.  If it knows the trust root then it can validate it."
	 
	-----Original Message-----
	From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at
ietf.org] On Behalf Of Bernard Aboba
	Sent: Tuesday, November 10, 2009 5:41 PM
	To: 'ECRIT'
	Subject: [Ecrit] Comments on Section 6 of
draft-schulzrinne-ecrit-unauthenticated-access
	 
	Section 6
	 
	"  signaling allows an IEEE 802.1X to occur without exchanging
	   cryptogrpahic keys"
	 
	[BA] Not sure what this is saying.  In IEEE 802.1X-2004, there
is no
	encryption supported.  However, EAP is still run.  This can
include
	methods that don't generate keys (e.g. EAP-MD5).  But the issue
here is
	client unauthenticated access, not key generation, right?
	 
	Section 6.1
	 
	"  In general, link layer emergency indications provide good
integration
	   into the actual network access procedure regarding the
enabling of
	   means to recognize and prioritize an emergency service
request from
	   an end host at a very early stage of the network attachment
	   procedure.  However, support in end hosts for such methods
cannot be
	   considered to be commonly available."
	 
	[BA] I'm not sure what this is referring to.  If it's referring
to QoS,
	those mechanisms are independent of emergency indications (e.g.
WFA WMM).
	If it's talking about higher layer emergency service
prioritization,
	that's also independent of the lower layer.  So what exactly is
a host
	expected to do at the lower layer to distinguish an emergency
call?
	 
	Section 6.2
	 
	"In normal operation, EAP related information will only be
recognized 
	in the NAS.  Any entity residing between end host and NAS should
not 
	be expected to understand/parse EAP messages."
	 
	[BA] The EAP architecture requires the NAS to be EAP-method
agnostic if
	it's acting as a pass-through.  So even the NAS can't be
depended upon to
	understand/parse EAP methods.  But why would it need to?
	 
	"   1.b) Emergency NAI: The NAI comes with a realm or username
part
	   indicating emergency (e.g. 'emergency at emergency.com').  An
advantage
	   of this method for NAA cases is that no new requirements are
put on
	   the involved signaling procedures.  Only the identity used
for
	   network entry is impacted.  Potential disadvantages include
that
	   different methods to indicate emergency for NAA cases and
standard
	   emergency network attachments may be required.  Also,
modifying the
	   NAI itself (the username at realm part) may conflict with
network
	   selection and network entry procedures, depending on the
actual
	   access network."
	 
	[BA] There are two distinct ideas being presented here.  One is
to define
	an emergency user name (e.g. "emergency"); another is to define
an
	emergency domain (e.g. "emergency.com").  The former concept may
make
	sense, but the latter one is dangerous since existing systems
not
	including the emergency realm in their routing tables may just
return an
	error.  So the question is what realm should be used, if any.
The problem
	with including any realm is that it assumes realm reachability.
If
	reachability doesn't exist, then the host will get an error.  If
there is
	no realm, then the local realm needs to recognize the emergency
username,
	and utilize an appropriate EAP method that allows client
unauthenticated
	access.
	> 
	"   2) Emergency EAP method 
	   An emergency indication can be given by using a dedicated EAP
method
	   that is reserved for emergency network attachment only."
	 
	[BA] Why is a dedicated EAP method needed for emergency access?
EMU WG
	has already discussed this and come up with mechanisms that
would allow
	client unauthenticated access from any TLS-based method (e.g.
server side
	either doesn't ask for a client cert, or accepts the client not
providing
	one).  That mechanism is supported in RFC 5216, and can also be
applied to
	existing methods such as EAP FAST, EAP TTLSv0, PEAP, etc.
	 
	In effect, the only real constraint here is that a local network
	advertising support for emergency calling needs to support one
or more
	of these methods.
	 
	"   2.a) Existing EAP method with new type: An existing EAP
method may be
	   used.  EAP methods themselves typically do not support
emergency
	   indication.  One option would be to pick a common EAP method
like
	   EAP-TLS and allocate a new method type for the same method
that is
	   exclusively reserved to emergency use.  Such EAP method
should be
	   chosen in a way that the same method can support NAA cases as
well as
	   standard emergency network attachment."
	> 
	Given that RFC 5216 already supports client-unauthenticated
anonymous
	access (see Sections 2.1.4 and 2.2), why is it necessary to
request
	allocation of a new method type?
	 
	"   2.b) Existing EAP method: Same as 2a), but without assigning
a new
	   EAP method type for emergency.  In this case some implicit
indication
	   must be used.  For example, in cases where EAP-TLS is used in
network
	   attachment in combination with client certificates, the
absence of a
	   client certificate could be interpreted by the network as a
request
	   for emergency network attachment."
	> 
	[BA] The combination of an emergency NAI *and* the absence of a
client
	certificate would be considered a request for emergency
attachment. If an
	NAI corresponding to an existing account is used, then normal
policies
	will apply (which would probably require authenticated access).
	 
	"   2.c) Emergency EAP method: A new EAP method could be defined
that is
	   specifically designed for emergency network entry in NAA
cases. Most
	   likely, such EAP method would not be usable for standard
emergency
	   network attachment with an existing subscription.  Such
dedicated
	   emergency EAP method should be key-generating in compliance
with
	   RFC3748 <http://tools.ietf.org/html/rfc3748 to enable the
regular air
	interface security methods even in unauthenticated operation."
	 
	[BA] Since any TLS-based method can potentially support client-
	unauthenticated access, it's not clear to me that there is a
good case for
	creating yet another method.
	 
	Section 6.3
	 
	"   Therefore, for network attachment that is by default based
on EAP
	   authentication it is desirable also for NAA network
attachment to use
	   a key-generating EAP method (that provides an MSK key to the
	   authenticator to bootstrap further key derivation for
protecting the
	   wireless link)."
	 
	[BA] Where key generation is required (e.g. WPA/WPA2 enterprise)
you don't
	really have a choice.
	 
	"   2) Null authentication: an EAP method is performed.
However, no
	   credentials specific to either the server or the device or
	   subscription are used as part of the authentication exchange.
An
	   example for this would be an EAP-TLS exchange with using the
	   TLS_DH_anon (anonymous) ciphersuite.  Alternatively, a
publicly
	   available static key for emergency access could be used.  In
the
	   latter case, the device would need to be provisioned with the
	   appropriate emergency key for the IAP/ISP in advance."
	 
	[BA] WPA/WPA2 enterprise mode and PSK mode are distinct; PSK
mode only
	uses the 4-way handshake, not EAP.
	 
	"   3) Device authentication: This case extends the server-only
	   authentication case.  If the device is configured with a
device
	   certificate and the IAP/ISP EAP server can rely on a trusted
root
	   allowing the EAP server to verify the device certificate, at
least
	   the device identity (e.g. the MAC address) can be
authenticated by
	   the IAP/ISP in NAA cases.  An example for this are WiMAX
devices that
	   are shipped with device certificates issued under the global
WiMAX
	   device public-key infrastructure.  To perform unauthenticated
	   emergency calls, if allowed by the IAP/ISP, such devices
perform EAP-
	   TLS based network attachment with client authentication based
on the
	   device certificate."
	> 
	IEEE 802.1ar might also be an example of this.