Subject: [Emu] Comments on Section 6 of draft-schulzrinne-ecrit-unauthenticated-access

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 10 Nov 2009 19:17:15 -0800

Section 6
 
"   signalling 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. [email-masked]').  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@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.