[xmppwg] Review of draft-meyer-xmpp-sasl-cert-management-01

Eric Rescorla ekr at rtfm.com
Sat Mar 21 14:13:57 CDT 2009

On Sat, Mar 21, 2009 at 11:32 AM, Dirk Meyer <dmeyer at tzi.de> wrote:
> Eric Rescorla wrote:
>> On Sat, Mar 21, 2009 at 2:39 AM, Dirk Meyer <dmeyer at tzi.de> wrote:
>>> Eric Rescorla wrote:
>>>> S 5.
>>>> There needs to be a requirement that this happen over TLS, no?
>>> I don't understand. In 5.6 TLS is started. The stuff before happens over
>>> the raw stream, everything from 5.8 is TLS secured. I don't know what
>>> you want to add here.
>> I'm talking about the certificate management operations *before*
>> the client certificate has been uploaded.
> Section 9.2:
>   Therefore the server MUST reject any communication described in this
>   document if the link between client and server is not secured with
>   both STARTTLS and SASL.

OK. I think this might benefit by being more upfront.

>>>> You probably need to specify what goes in the CertificateRequest,
>>>> since that's intended to include CAs but there won't be any
>>>> here. Probably empty...
>>> Request what you want,
>> It's more complicated than that. SOMETHING needs to go in that
>> field, and if you don't provide guidance, people will screw it up.
> With "Request what you want" I wanted to say that I don't care which
> one. But I agree, we should write that a client is allowed to get the
> list or not. I only don't care which one we should use. Maybe someone
> else has a reason for or against it.

I think we're talking past each other. For TLS Client Auth to work, the
server sends a CertificateRequest message which contains the list
of CAs the server trusts. If you don't care what the client does,
you send an empty list. So, that's the thing I think needs some

>> There's a distinction between "remove from the list" and "terminate
>> any existing connections." I'm talking about the second. And given
>> that the user of the stolen mobile phone could potentially change
>> the certificate list, locking you out entirely, I'm not convinced this
>> is that important a feature, especially given the implementation
>> burden.
> A stolen device can not lock me out because I still have the password as
> fallback.
> Section 9.4:
>   [XEP-0077] defines a mechanism to change the password without knowing
>   the current one.  If the server supports password change it MUST
>   return not-authorized for clients logged in using SASL EXTERNAL and
>   MAY include a password change form requiring the old password.  If
>   the client has logged in with the current password, the server MAY
>   change the password without a form as specified in XEP-0077.
>   If a client is allowed to change the password without knowing the
>   current password, the additional security provided by this document
>   is compromised.

1. Devices often cache passwords.
2. It's actually very natural once a certificate is established to
deny password
    login entirely (cf. common SSH practice).


More information about the xmppwg mailing list