Re: Evaluation: draft-ietf-pkix-wlan-extns-04.txt

[Russ Housley <housley@vigilsec.com>]

Ted:

How about this:

   SSID values are unmanaged; therefore SSIDs may not be unique.  Hence,
   it is possible for client certificates that are intended to be used
   with different WLANs to contain the same SSID.  In this case,
   automatic selection of the certificate will fail, and the
   implementation SHOULD obtain help from the user to choose the correct
   certificate.  In cases where a human user is unavailable, each
   potential certificate MAY be tried until one succeeds, disclosing the
   list of SSIDs associated with each certificate, which might otherwise
   not be disclosed.  Therefore, it is RECOMMENDED that sequentially
   trying each certificate only be employed when user selection is
   unavailable or impractical.

   In practice, disclosure of the SSID is of little concern.  Some WLAN
   security experts recommend that the SSID be masked in the beacon sent
   out by Access Points (APs).  The intent is to make it harder for an
   attacker to find the correct AP to target.  However, other WLAN
   management messages include the SSID, so this practice only forces
   the attacker to eavesdrop on the WLAN management messages instead of
   the beacon.  Therefore, placing the SSID in the certificate does not
   make matters worse.

I think it addresses your concern, and it keeps the SHOULD.

I also want to add the sentence about the MAC address caching in section 3.

Russ

At 07:09 PM 8/19/2003 -0700, hardie@qualcomm.com wrote:
> At 10:26 AM -0400 08/19/2003, Russ Housley wrote:
> > Ted:
> >
> > The Security Considerations section does address this concern.  It says:
> >
> >    SSID values are unmanaged; therefore SSIDs may not be unique.  Hence,
> >    multiple client certificates may contain the same SSID.  In this
> >    case, automatic selection of the certificate SHOULD fail, and the
> >    implementation will require help from the user to choose the correct
> >    certificate.  If the implementation chooses to automatically select
> >    the client certificate and choose the incorrect one, then information
> >    such as the list of SSIDs may be disclosed.
> >
> > If your concern is implementations that do not have human operators, then 
> > sequentially trying the certificates may be necessary.
> >
> > Whether the implementation has a human user associated with it or not, 
> > the sequential attempt with each certificate only needs to be done once 
> > if a cache of AP MAC addresses with which the certificate has 
> > successfully authenticated.  I think this is a good addition to the 
> > document.  I propose the following text:
> >
> >    The Wireless LAN (WLAN) System Service identifiers (SSIDs) public key
> >    certificate extension is always non-critical.  It contains a list of
> >    SSIDs.  When more than one certificate includes an extended key usage
> >    extension indicating that the certified public key is appropriate for
> >    use with the EAP in the LAN environment, the list of SSIDs MAY be
> >    used to select the correct certificate for authentication in a
> >    particular WLAN.
> >
> >    Since SSID values are unmanaged, the same SSID can appear in
> >    different certificates that are intended to be used with different
> >    WLANs.  When this occurs, automatic selection of the certificate
> >    SHOULD fail, and the implementation will require help from the user
> >    to choose the correct certificate.  However, by maintaining a cache
> >    of Access Point (AP) MAC addresses with which the certificate has
> >    successfully authenticated, user involvement can be minimized.
>
> I believe that the text on maintaining a cache of AP MAC addresses with
> which the certificate has successfully authenticated is useful.  I'm 
> concerned,
> though, about saying that the automatic selection SHOULD fail and that the
> implementation will require user intervention.  First, there will be cases in
> which there is no human user, the user is not attending this process, or the
> user interface is not available at the time this error would be 
> raised.  Second,
> I'm not sure what the implementation would present to the user to allow
> them to distinguish among certificates which contain the same SSIDs; is
> there a particular set of certificate attributes which feel would be valuable
> to present to the user in this case?
>
> I'd suggest having some default method of dealing with it, but warning
> of the consequences of using it.  How does this look as a re-write:
>
>    Since SSID values are unmanaged, the same SSID can appear in
>    different certificates that are intended to be used with different
>    WLANs.  When this occurs, automatic selection of the certificate
>    will fail, and the implementation will either require help from a user
>    in selecting the correct certificate or MAY choose to present multiple
>    certificates.  The second option discloses information, such as the
>     list of SSIDs, which would otherwise remain confidential, and it is
>     therefore recommended that it be used only when user selection is
>     unavailable or impractical.
>
> Thanks for your consideration of these points,
>                                 regards,
>                                         Ted Hardie