[xmppwg] Review of draft-meyer-xmpp-sasl-cert-management-01
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
> A stolen device can not lock me out because I still have the password as
> 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
login entirely (cf. common SSH practice).
More information about the xmppwg