Re: [Standards] Proposed XMPP Extension: Client Certificate Management for SASL EXTERNAL
On Dec 5, 2008, at 8:18 AM, Dirk Meyer wrote: Some XMPP server implementations already support multiple passwords per user. Of course, the server has no clue how such passwords are shared amongst a user's clients, likewise for user certificates. They do? What XEP handles that? Yes. No XEP needed (if it's not specifically precluded, it's allowed). SASL mechanisms do not restrict users to single passwords. For instance, a server checking passwords against a directory using LDAP Bind or Compare will naturally have multiple passwords per user, as password attributes in the directory have traditionally been multi- valued. -- Kurt
Re: [Standards] Proposed XMPP Extension: Client Certificate Management for SASL EXTERNAL
Kurt Zeilenga wrote: > If there are some hidden assumptions/use cases, I think they should be > more clearly called out and discussed in the proposal. I will do that in the next version > Some XMPP server implementations already support multiple passwords > per user. Of course, the server has no clue how such passwords are > shared amongst a user's clients, likewise for user certificates. They do? What XEP handles that? > I think what your proposal needs to focus on activation/deactivation > of user certificates, leaving revocation handling to other documents > (but noting that leave revocation handling to other documents). Thanks for the input. I see now that I need to write much more doc about the use case behind this. And I will not use revoke. Dirk -- Right now I'm having amnesia and deja vu at the same time. I think I've forgotten this before.
Re: [Standards] Proposed XMPP Extension: Client Certificate Management for SASL EXTERNAL
On Dec 5, 2008, at 2:57 AM, Dirk Meyer wrote: Kurt Zeilenga wrote: On Dec 4, 2008, at 10:18 AM, Dirk Meyer wrote: Kurt Zeilenga wrote: On Dec 4, 2008, at 2:04 AM, Dirk Meyer wrote: It is part of urn:xmpp:tmp:saslcert (or will be once I write the schema). The problem is that there are two reason to revoke a certificate: 1. A certificate is about to expire. The client uploads a new one and revokes the old. The client should stay connected. More interestingly, is what about other sesssions using the old certificate. There is only one. Each client has its own certificate, I don't see why a user would not use a single certificate in multiple clients, especially for certificates issued by a non-user-operated CA. The idea behind this proposal ist to make it possible to remove one client from the system later. I know little of what's behind the proposal, I'm just reading the proposal. The proposal talks about: This specification defines a method to manage client certificates that can be used with SASL External to allow clients to log in without a password. It's a very general certificate management protocol. If there are some hidden assumptions/use cases, I think they should be more clearly called out and discussed in the proposal. If all clients share the same certificate, there isn't much difference to the password based login or the current SASL EXTERNAL XEP. Right, this is no better than sharing a password amongst multiple clients. The whole idea is that each client has its own certificate so every client uses something different to log in which can be revoked on a per-client-bases. Some XMPP server implementations already support multiple passwords per user. Of course, the server has no clue how such passwords are shared amongst a user's clients, likewise for user certificates. I think this proposal needs to be written from a perspective that users will share certificates, to some degree, between their clients. What this proposal offers is a mechanism to manage multiple user certificates, such that if one (or more) is comprised, that certificate can be deactivated and hence disallowing continued use of those clients that rely on that particular certificate. While a user may choose to have per-client certificates, and thereby having per- client deactivation control, a user may choose to share client certificates. Deactivation, to me, means that it has been removed from a list of acceptable user certificates. A deactivated certificate can certainly be used in the future. For instance, by adding back to the list of acceptable user certificates. Deactivation does not imply revocation. I have to think about what I want here. I guess deactivation is easier because it does not require a list of certificates that can not be added again later. The revoke/deactivate has nothing to do with the mechanism defined by X.509. Then don't use the term "revoke" as this term has quite a different meaning than disable or deactivate. There is no URL were you can check if a certificate is valid or not. Information about how to check for revocation may be in the certificate itself, the CA certificate (if known), or otherwise known. (but see my comment below about avoiding discussion of revocation in this proposal). They may be self-signed and the list handled by my proposal ist the list of certificates that are allowed to be used for login. A user can request its CA revoke the certificate, but a user can deactivate the certificate (remove it from the list of acceptable certificates). With self-signed certificates this is not possible. Yes, but your proposal covers cases where it is possible. I think what your proposal needs to focus on activation/deactivation of user certificates, leaving revocation handling to other documents (but noting that leave revocation handling to other documents). Dirk -- Freedom of speech is wonderful - right up there with the freedom not to listen.
Re: [Standards] Proposed XMPP Extension: Client Certificate Management for SASL EXTERNAL
Kurt Zeilenga wrote: > On Dec 4, 2008, at 10:18 AM, Dirk Meyer wrote: > >> Kurt Zeilenga wrote: >>> On Dec 4, 2008, at 2:04 AM, Dirk Meyer wrote: >>> It is part of urn:xmpp:tmp:saslcert (or will be once I write the schema). The problem is that there are two reason to revoke a certificate: 1. A certificate is about to expire. The client uploads a new one and revokes the old. The client should stay connected. >>> >>> More interestingly, is what about other sesssions using the old >>> certificate. >> >> There is only one. Each client has its own certificate, > > I don't see why a user would not use a single certificate in multiple > clients, especially for certificates issued by a non-user-operated CA. The idea behind this proposal ist to make it possible to remove one client from the system later. If all clients share the same certificate, there isn't much difference to the password based login or the current SASL EXTERNAL XEP. The whole idea is that each client has its own certificate so every client uses something different to log in which can be revoked on a per-client-bases. > Deactivation, to me, means that it has been removed from a list of > acceptable user certificates. A deactivated certificate can certainly > be used in the future. For instance, by adding back to the list of > acceptable user certificates. Deactivation does not imply revocation. I have to think about what I want here. I guess deactivation is easier because it does not require a list of certificates that can not be added again later. The revoke/deactivate has nothing to do with the mechanism defined by X.509. There is no URL were you can check if a certificate is valid or not. They may be self-signed and the list handled by my proposal ist the list of certificates that are allowed to be used for login. > A user can request its CA revoke the certificate, but a user can > deactivate the certificate (remove it from the list of acceptable > certificates). With self-signed certificates this is not possible. Dirk -- Freedom of speech is wonderful - right up there with the freedom not to listen.
Re: [Standards] Proposed XMPP Extension: Client Certificate Management for SASL EXTERNAL
On Dec 4, 2008, at 10:18 AM, Dirk Meyer wrote: Kurt Zeilenga wrote: On Dec 4, 2008, at 2:04 AM, Dirk Meyer wrote: It is part of urn:xmpp:tmp:saslcert (or will be once I write the schema). The problem is that there are two reason to revoke a certificate: 1. A certificate is about to expire. The client uploads a new one and revokes the old. The client should stay connected. More interestingly, is what about other sesssions using the old certificate. There is only one. Each client has its own certificate, I don't see why a user would not use a single certificate in multiple clients, especially for certificates issued by a non-user-operated CA. otherwise it is not possible to remove one bad client from the network without affecting others. The same certificate can also be used for XEP-0250. 2. A device should be removed (e.g. stolen). In that case the certificate is compromised and if the device is logged in right now, it should be disconnected by the server. First, it's not clear to me what you mean be 'revoke' a certificate. In particular, whether you mean to 'revoke' in the X.509 sense of the word, or whether you simply mean to no longer consider a certificate as suitable for gaining access (that is, removing it from a list of acceptable user certificates, or deactivated). Second, I'm not sure it matters all that much. Yes, I mean revoke it exactly that way. It will not be possible to log in with that certificate anymore. Sorry, but your response here doesn't clarify to me what you mean by 'revoke'. Anyways, there are many reasons why a certificate could be 'revoked' or 'deactivated'. Agreed. Maybe revoke and deactivate mean something different: revoke means it is a compromised certificate, To me, 'revoke' means the the certificate has been revoked in the X. 509 sense. A certificate can be revoked for many different reasons, including a possible compromise. deactivate means it can not be used in the future. Deactivation, to me, means that it has been removed from a list of acceptable user certificates. A deactivated certificate can certainly be used in the future. For instance, by adding back to the list of acceptable user certificates. Deactivation does not imply revocation. While some might argue that existing sessions should not be impacted by either a 'revocation' or 'deactiviation', some might also argue that all sessions (including those used to 'revocate' or 'deactivate') should be immediately disconnected or at least quarantined in some manner (for instance, all subsequent messages generate 'please reconnect' errors). And there is some who are somewhere in the middle. Now back to your cases... If a user 'revokes' or 'deactivates' a clearance, he might be doing so as he thinks it is compromised, regardless of the proximity to the expiration time of the old certificate. Right. My mobile phone gets stolen or I simply loose it, I revoke the certificate A user can request its CA revoke the certificate, but a user can deactivate the certificate (remove it from the list of acceptable certificates). and my maybe currently connected phone should disconnect at once. Well, in the revocation case, the CA has to publish the revocation and the server has to learn of it. Now, what would be nice is for the user to advise the server that certificate is not longer acceptable. If an implementation is going to disconnect (or fail requests) existing session on revocation and/or deactivation, I would argue this should occur either on all sessions, or to all but the session which issued the revocation/deactivation order. And for this session, it should discontinued (or fail requests) very soon after the order. That problem should not exist if each client has its own certificate. In that case there is only one session. I think there are use cases where clients share user certificates (they might even share device certificates, depending on how the certificate are bound to the device). I will write some more doc about this. Looking forward to this... And I will add some text about each client having its own certificate :) Dirk -- We live in a society where pizza gets to your house before the police.
Re: [Standards] Proposed XMPP Extension: Client Certificate Management for SASL EXTERNAL
Kurt Zeilenga wrote: > On Dec 4, 2008, at 2:04 AM, Dirk Meyer wrote: > >> It is part of urn:xmpp:tmp:saslcert (or will be once I write the >> schema). The problem is that there are two reason to revoke a >> certificate: >> >> 1. A certificate is about to expire. The client uploads a new one and >> revokes the old. The client should stay connected. > > More interestingly, is what about other sesssions using the old > certificate. There is only one. Each client has its own certificate, otherwise it is not possible to remove one bad client from the network without affecting others. The same certificate can also be used for XEP-0250. >> 2. A device should be removed (e.g. stolen). In that case the >> certificate is compromised and if the device is logged in right now, >> it should be disconnected by the server. > > First, it's not clear to me what you mean be 'revoke' a certificate. > In particular, whether you mean to 'revoke' in the X.509 sense of the > word, or whether you simply mean to no longer consider a certificate > as suitable for gaining access (that is, removing it from a list of > acceptable user certificates, or deactivated). Second, I'm not sure > it matters all that much. Yes, I mean revoke it exactly that way. It will not be possible to log in with that certificate anymore. > Anyways, there are many reasons why a certificate could be 'revoked' > or 'deactivated'. Agreed. Maybe revoke and deactivate mean something different: revoke means it is a compromised certificate, deactivate means it can not be used in the future. > While some might argue that existing sessions should not be impacted > by either a 'revocation' or 'deactiviation', some might also argue > that all sessions (including those used to 'revocate' or 'deactivate') > should be immediately disconnected or at least quarantined in some > manner (for instance, all subsequent messages generate 'please > reconnect' errors). And there is some who are somewhere in the > middle. > > Now back to your cases... > > If a user 'revokes' or 'deactivates' a clearance, he might be doing so > as he thinks it is compromised, regardless of the proximity to the > expiration time of the old certificate. Right. My mobile phone gets stolen or I simply loose it, I revoke the certificate and my maybe currently connected phone should disconnect at once. > If an implementation is going to disconnect (or fail requests) > existing session on revocation and/or deactivation, I would argue this > should occur either on all sessions, or to all but the session which > issued the revocation/deactivation order. And for this session, it > should discontinued (or fail requests) very soon after the order. That problem should not exist if each client has its own certificate. In that case there is only one session. >> I will write some more doc about this. > > Looking forward to this... And I will add some text about each client having its own certificate :) Dirk -- We live in a society where pizza gets to your house before the police.
Re: [Standards] Proposed XMPP Extension: Client Certificate Management for SASL EXTERNAL
Dirk Meyer wrote: Philipp Hancke wrote: And it results in a certificate signed by an entity that the server trusts. Well, the server can trust the client with its own certificate. But you raise an interessting point: what do others think? CSR or the other way. Alexey already wrote that he prevers not to deal with CSR. I don't mind doing CSR and turning XMPP server into a full CA ;-), but I think your idea is simpler, so it would be easier to deploy.
Re: [Standards] Proposed XMPP Extension: Client Certificate Management for SASL EXTERNAL
Philipp Hancke wrote: > why does the client generate the certificate? Sending a CSR to the > server and signing it there (which may take a long time) seems > easier from the certificate managment point of view. IMHO it is more complicated. Why doing a complex CSR (which as you wrote may take a long time) when a client can upload a certificate. The client is trusted when doing so and the certificate only has to work between these two. > And it results in a certificate signed by an entity that the server > trusts. Well, the server can trust the client with its own certificate. But you raise an interessting point: what do others think? CSR or the other way. Alexey already wrote that he prevers not to deal with CSR. Dirk -- A mathematician is a machine for converting coffee into theorems.
Re: [Standards] Proposed XMPP Extension: Client Certificate Management for SASL EXTERNAL
On Dec 4, 2008, at 2:04 AM, Dirk Meyer wrote: It is part of urn:xmpp:tmp:saslcert (or will be once I write the schema). The problem is that there are two reason to revoke a certificate: 1. A certificate is about to expire. The client uploads a new one and revokes the old. The client should stay connected. More interestingly, is what about other sesssions using the old certificate. 2. A device should be removed (e.g. stolen). In that case the certificate is compromised and if the device is logged in right now, it should be disconnected by the server. First, it's not clear to me what you mean be 'revoke' a certificate. In particular, whether you mean to 'revoke' in the X.509 sense of the word, or whether you simply mean to no longer consider a certificate as suitable for gaining access (that is, removing it from a list of acceptable user certificates, or deactivated). Second, I'm not sure it matters all that much. Anyways, there are many reasons why a certificate could be 'revoked' or 'deactivated'. While some might argue that existing sessions should not be impacted by either a 'revocation' or 'deactiviation', some might also argue that all sessions (including those used to 'revocate' or 'deactivate') should be immediately disconnected or at least quarantined in some manner (for instance, all subsequent messages generate 'please reconnect' errors). And there is some who are somewhere in the middle. Now back to your cases... If a user 'revokes' or 'deactivates' a clearance, he might be doing so as he thinks it is compromised, regardless of the proximity to the expiration time of the old certificate. If an implementation is going to disconnect (or fail requests) existing session on revocation and/or deactivation, I would argue this should occur either on all sessions, or to all but the session which issued the revocation/deactivation order. And for this session, it should discontinued (or fail requests) very soon after the order. I will write some more doc about this. Looking forward to this... - Kurt
Re: [Standards] Proposed XMPP Extension: Client Certificate Management for SASL EXTERNAL
Dirk Meyer wrote: I have an additional question: do you think this is a useful? I can see value in using password to authenticate once and then creating a stronger credential (certificate). And your proposal is simpler than possible alternatives because it doesn't require dealing with CSR, etc.
Re: [Standards] Proposed XMPP Extension: Client Certificate Management for SASL EXTERNAL
Dirk Meyer wrote: Alexey Melnikov wrote: This is quite sensible reminds me of an older IETF effort called SACRED (see RFC 3767 and friends). Hello BEEP :) Indeed :-). Thanks for the pointer, I will take a look at it to see if something useful for us is in it. Good. I've scanned the document and have some quick comments/questions: Example 4. Client revokes an X.509 Certificate Where is defined? It is part of urn:xmpp:tmp:saslcert (or will be once I write the schema). Ok. Please also describe purpose of various revocation reasons in prose. The problem is that there are two reason to revoke a certificate: Yes, I understand that having different revocation reasons is important. 1. A certificate is about to expire. The client uploads a new one and revokes the old. The client should stay connected. 2. A device should be removed (e.g. stolen). In that case the certificate is compromised and if the device is logged in right now, it should be disconnected by the server. I will write some more doc about this. Thanks.
Re: [Standards] Proposed XMPP Extension: Client Certificate Management for SASL EXTERNAL
XMPP Extensions Editor schrieb: The XMPP Extensions Editor has received a proposal for a new XEP. Title: Client Certificate Management for SASL EXTERNAL Abstract: This specification defines a method to manage client certificates that can be used with SASL External to allow clients to log in without a password. URL: http://www.xmpp.org/extensions/inbox/sasl-external-cert-handling.html The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP. why does the client generate the certificate? Sending a CSR to the server and signing it there (which may take a long time) seems easier from the certificate managment point of view. And it results in a certificate signed by an entity that the server trusts. Philipp
Re: [Standards] Proposed XMPP Extension: Client Certificate Management for SASL EXTERNAL
Alexey Melnikov wrote: > This is quite sensible reminds me of an older IETF effort called > SACRED (see RFC 3767 and friends). Hello BEEP :) Thanks for the pointer, I will take a look at it to see if something useful for us is in it. > I've scanned the document and have some quick comments/questions: > >> Example 4. Client revokes an X.509 Certificate >> >>>from='[EMAIL PROTECTED]/denmark' >>id='revoke'> >> >> >> >> >> > Where is defined? It is part of urn:xmpp:tmp:saslcert (or will be once I write the schema). The problem is that there are two reason to revoke a certificate: 1. A certificate is about to expire. The client uploads a new one and revokes the old. The client should stay connected. 2. A device should be removed (e.g. stolen). In that case the certificate is compromised and if the device is logged in right now, it should be disconnected by the server. I will write some more doc about this. > I assume this proposal doesn't prevent use of properly certificates > signed by a CA, which were not uploaded? No, it is an addition. I will add that note to the doc. > I think this XEP-to-be should REQUIRE at least use of TLS integrity > protection and/or SASL security layer with integrity protection. > Without that any man-in-the-middle that can inject data into a TCP > stream can upload arbitrary certificates (for which he/she has the > private key), so effectively giving himself/herself full access to the > account. Oops, yes. I sometimes forget that it is an optional feature. IMHO we need TLS and SASL as requirement to be sure. I have an additional question: do you think this is a useful? Thanks for the feedback, Dirk -- Having trouble in Windows? Reboot! Having trouble in Linux? Be root!
Re: [Standards] Proposed XMPP Extension: Client Certificate Management for SASL EXTERNAL
XMPP Extensions Editor wrote: The XMPP Extensions Editor has received a proposal for a new XEP. Title: Client Certificate Management for SASL EXTERNAL Abstract: This specification defines a method to manage client certificates that can be used with SASL External to allow clients to log in without a password. URL: http://www.xmpp.org/extensions/inbox/sasl-external-cert-handling.html The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP. This is quite sensible reminds me of an older IETF effort called SACRED (see RFC 3767 and friends). I've scanned the document and have some quick comments/questions: Example 4. Client revokes an X.509 Certificate Where is defined? [...] 3. SASL EXTERNAL The protocol flow is similar to the one described in XEP-0178. Only step 9 is different: the certificate does not need to be signed by a trusted entity if the certificate was uploaded by the user. The server still MUST reject the certificate if it is expired. The client certificate SHOULD include a JID as defined in sections 15.2.1.2. and 15.2.1.3. in rfc3920bis: a JID MUST be represented as an XmppAddr, i.e., as a UTF8String within an otherName entity inside the subjectAltName. I assume this proposal doesn't prevent use of properly certificates signed by a CA, which were not uploaded? 4. Security Considerations I think this XEP-to-be should REQUIRE at least use of TLS integrity protection and/or SASL security layer with integrity protection. Without that any man-in-the-middle that can inject data into a TCP stream can upload arbitrary certificates (for which he/she has the private key), so effectively giving himself/herself full access to the account.
[Standards] Proposed XMPP Extension: Client Certificate Management for SASL EXTERNAL
The XMPP Extensions Editor has received a proposal for a new XEP. Title: Client Certificate Management for SASL EXTERNAL Abstract: This specification defines a method to manage client certificates that can be used with SASL External to allow clients to log in without a password. URL: http://www.xmpp.org/extensions/inbox/sasl-external-cert-handling.html The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP.
