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

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 16 Feb 2010 09:04:15 -0800

I agree with Barnard'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: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Bernard Aboba
> Sent: Tuesday, November 10, 2009 5:41 PM
> To: 'ECRIT'
> Subject: [Ecrit] Comments on Section 6 ofdraft-schulzrinne-ecrit-
> unauthenticated-access
> 
> 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.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 16 Feb 2010 09:04:28 -0800

Of
is
integration
be
QoS,
WMM).
residing
if
to
advantage
define
an
problem
is
username,
unauthenticated
method
WG
allow
side
providing
applied to
of
be
as
indication
network
a
If an
is
Most
air
for
use
the
don't
that
EAP-
the