RE: [Emu] WGLC comments for draft-simon-emu-rfc2716bis

[<Pasi.Eronen at nokia.com>]

Bernard Aboba wrote:

> >4) Section 2.4, "SHOULD NOT use the identity presented in the
> >Identity Response for access control or accounting purposes": is
> >using unauthenticated information for access control or accounting
> >purposes really something where we think "there may exist valid
> >reasons in particular circumstances when the particular behavior is
> >acceptable or even useful"? (quoting from RFC2119)
> 
> Some EAP-TLS implementations do match the identity in the Response
> with the identity included in the certificate, though this is not a
> good idea.  The SHOULD was left here so as to be compatible with RFC
> 3748 Section 5.1:
> 
>       It is RECOMMENDED that the Identity Response be used 
>       primarily for routing purposes and selecting which EAP method 
>       to use.  EAP Methods SHOULD include a method-specific mechanism 
>       for obtaining the identity, so that they do not have to rely on 
>       the Identity Response.

It's not a big problem if some implementations require that the
Identity Response matches the certificate, but it *is *a big problem
if they don't match, and unauthenticated information from Identity
Response is used for access control purposes. But I don't think this
is what RFC3748's SHOULD is about...

How about rephrasing the text to something like this?

   Since the identity presented in the Identity Response need not be
   related to the identity presented in the peer certificate, EAP-TLS
   implementations SHOULD NOT require that they be identical.
   However, if they are not identical, the identity presented in the
   Identity Response is unauthenticated information, and SHOULD NOT be
   used for access control or accounting purposes.

> >5) Section 2.4, "SHOULD also examine the Server-id in order to
> >determine whether the EAP server can be trusted": if this is really
> >an appropriate SHOULD, it definitely needs more discussion.  If you
> >don't check the name (the most important piece of information!) in
> >the certificate, why bother checking the certificate at all, or
> >details such as revocation?
> 
> Some implementations may not have expectations relating to the
> server name and may just verify the server certificate chain.
> Verifying the certificate chain and checking revocation provide
> benefits independent of checking the server name against a
> pre-configured template.

I'm aware that some implementations do this, but the document should
explain the security implications better. If you compare the name in
the certificate with the expected server name, an attacker fool you if
he breaks into that server and steals its private key. If you don't
check the name, the attacker can steal a private key corresponding to
any certificate issued by your trusted CA (which in case of large CA
could be millions of potential points of failure).

Best regards,
Pasi

_______________________________________________
Emu mailing list
Emu at ietf.org
https://www1.ietf.org/mailman/listinfo/emu