Re: Service Key Discovery 1.0
In essence, OpenID is a reaction to (perceived?) complexity, so it's an uphill battle to reference SAML, XRI, or anything that touches on any W3 or OASIS standard effort relating to XML and security, really. So for OpenID, there has to be a simpler, key/value-pair, way of doing what's desired, it seems. Hans On 1/21/08, Drummond Reed [EMAIL PROTECTED] wrote: Masaki, Peter has a good point -- the XRDS keyinfo discovery mechanism, specified in section 10.2 (SAML Trusted Resolution) of XRI Resolution 2.0 Committee Draft 02 (http://docs.oasis-open.org/xri/2.0/specs/cd02/xri-resolution-V2.0-cd-02.pdf ), deals with DNS poisoning by using signed SAML assertions (including the ds:keyInfo element) for each authority in the resolution chain. So presuming HTTPS is used for the first root authority call, you should be good all the way down the chain as long as signatures verify. (Peter's also right that libraries have not implemented it yet, but that may be changing soon as demand for secure key discovery rises...) =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Davis Sent: Monday, January 21, 2008 6:33 AM To: NISHITANI Masaki Cc: specs@openid.net Subject: Re: Service Key Discovery 1.0 FWIW, the XRI form of openID's provides just such a mechanism, where- by the publisher of the XRD signs all (or a part of) the XRDS, tho i know of few libraries today which support trusted resolution[1]. =peterd [1] http://docs.oasis-open.org/xri/2.0/specs/cd02/xri-resolution-V2.0- cd-02.pdf On Jan 21, 2008, at 5:38 AM, NISHITANI Masaki wrote: Hi all. What concerns me these days is about secure data exchange over OpenID for serious services and about this theme, I came upon an specification, secure key discovery 1.0 For my understanding, this spec is about implementing security framework on OpenID world and is still very draft. Now I'd like to figure out some point I found. - In this, the url of the public key is defined to be in the XRD document and entities will make another request for the url to retrieve the public key itself. This gives bad people a chance to pass off a fake key with poisoning the end-user's DNS. How about to put public key itself in the XRD or someone else the entity trusts (a key server)? The entity only has to manage SSL certificate fingerprints of XRD authorities or trusting key servers. - With secure key discovery, we do have to use association or verification message no longer. I think we can optimize OpenID protocol using digital signature with public keys. This can be done with following procedure. 1. End-user enter its OpenID in RP site. 2. RP resolve the id and select the user's OP. 3. In the same time, RP retrieve the OP's public key. 4. RP generate a challenge (maybe the user's http session id) 5. RP send the id to the OP via http redirection. 6. OP authenticate the user and sign to the challenge with OP's secret key. 7. OP send the assertion including the signed challenge back to the RP via redirection. 8. Now RP can verify the assertion with the signature using OP's public key. The good thing about this sequence is not only reducing network traffic, but this can be a solution against man-in-the-middle attacks, to which OpenID has principle vulnerability. I think this spec can be quite useful for the next version of OpenID protocol. Does someone know the status of it? =masaki ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Service Key Discovery 1.0
At some point, we have to draw a line between the simple and enhanced solutions. There is baggage around XRI-related technologies, but it doesn't make sense to keep inventing new things just because people refuse to give it a chance. OpenID provides a simple way using HTTP requests. But once your needs are more complex than what 2.0 offers, looking at existing technologies is a better idea than keep inventing new ways of conducting business over HTTP parameters. Eventually, we are going to reach insanely long URIs with all those extensions. I question whether PKI information belongs in OpenID redirections. The focus should be on XRDS as a discovery document. No matter how you feel about XRI, XRDS is part of OpenID 2.0, and not just the few elements mentioned by the spec, but the whole thing. OpenID points to XRI Resolution 2.0 as the sole authority on parsing an XRDS document. So you already have all this in OpenID. While many developers may choose to ignore the full XRDS format, their code will not be compliance with OpenID 2.0 is they do that. EHL -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Davis Sent: Tuesday, January 22, 2008 10:38 AM To: Hans Granqvist Cc: specs@openid.net Subject: Re: Service Key Discovery 1.0 true enough. However, there are design patterns (at least) from which one can apply to alternate representations (which is at the heart of, as you put it, 'key/value-pair way of doing what's desired' ). =peterd On Jan 22, 2008, at 10:27 AM, Hans Granqvist wrote: In essence, OpenID is a reaction to (perceived?) complexity, so it's an uphill battle to reference SAML, XRI, or anything that touches on any W3 or OASIS standard effort relating to XML and security, really. So for OpenID, there has to be a simpler, key/value-pair, way of doing what's desired, it seems. Hans On 1/21/08, Drummond Reed [EMAIL PROTECTED] wrote: Masaki, Peter has a good point -- the XRDS keyinfo discovery mechanism, specified in section 10.2 (SAML Trusted Resolution) of XRI Resolution 2.0 Committee Draft 02 (http://docs.oasis-open.org/xri/2.0/specs/cd02/xri-resolution-V2.0- cd-02.pdf ), deals with DNS poisoning by using signed SAML assertions (including the ds:keyInfo element) for each authority in the resolution chain. So presuming HTTPS is used for the first root authority call, you should be good all the way down the chain as long as signatures verify. (Peter's also right that libraries have not implemented it yet, but that may be changing soon as demand for secure key discovery rises...) =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Davis Sent: Monday, January 21, 2008 6:33 AM To: NISHITANI Masaki Cc: specs@openid.net Subject: Re: Service Key Discovery 1.0 FWIW, the XRI form of openID's provides just such a mechanism, where- by the publisher of the XRD signs all (or a part of) the XRDS, tho i know of few libraries today which support trusted resolution[1]. =peterd [1] http://docs.oasis-open.org/xri/2.0/specs/cd02/xri-resolution- V2.0- cd-02.pdf On Jan 21, 2008, at 5:38 AM, NISHITANI Masaki wrote: Hi all. What concerns me these days is about secure data exchange over OpenID for serious services and about this theme, I came upon an specification, secure key discovery 1.0 For my understanding, this spec is about implementing security framework on OpenID world and is still very draft. Now I'd like to figure out some point I found. - In this, the url of the public key is defined to be in the XRD document and entities will make another request for the url to retrieve the public key itself. This gives bad people a chance to pass off a fake key with poisoning the end-user's DNS. How about to put public key itself in the XRD or someone else the entity trusts (a key server)? The entity only has to manage SSL certificate fingerprints of XRD authorities or trusting key servers. - With secure key discovery, we do have to use association or verification message no longer. I think we can optimize OpenID protocol using digital signature with public keys. This can be done with following procedure. 1. End-user enter its OpenID in RP site. 2. RP resolve the id and select the user's OP. 3. In the same time, RP retrieve the OP's public key. 4. RP generate a challenge (maybe the user's http session id) 5. RP send the id to the OP via http redirection. 6. OP authenticate the user and sign to the challenge with OP's secret key. 7. OP send the assertion including the signed challenge back to the RP via redirection. 8. Now RP can verify the assertion with the signature using OP's public key. The good thing about this sequence is not only reducing network traffic, but this can be a solution against man-in-the-middle attacks, to which OpenID has principle
Re: Service Key Discovery 1.0
Interesting idea. Is there a way to do this via an RP- OP SSL handshake? Web apps typically don't have access to SSL private keys, at least in larger deployments. I wonder how your idea reduces network traffic, though. Don't you still have to retrieve the public key, which is likely larger than the associate message payload? I think hurdles against your idea are: 1. availability of public key cryptography in the RP libraries, and 2. fear that it's hard to correctly implement public key cryptography Hans On 1/21/08, NISHITANI Masaki [EMAIL PROTECTED] wrote: Hi all. What concerns me these days is about secure data exchange over OpenID for serious services and about this theme, I came upon an specification, secure key discovery 1.0 For my understanding, this spec is about implementing security framework on OpenID world and is still very draft. Now I'd like to figure out some point I found. - In this, the url of the public key is defined to be in the XRD document and entities will make another request for the url to retrieve the public key itself. This gives bad people a chance to pass off a fake key with poisoning the end-user's DNS. How about to put public key itself in the XRD or someone else the entity trusts (a key server)? The entity only has to manage SSL certificate fingerprints of XRD authorities or trusting key servers. - With secure key discovery, we do have to use association or verification message no longer. I think we can optimize OpenID protocol using digital signature with public keys. This can be done with following procedure. 1. End-user enter its OpenID in RP site. 2. RP resolve the id and select the user's OP. 3. In the same time, RP retrieve the OP's public key. 4. RP generate a challenge (maybe the user's http session id) 5. RP send the id to the OP via http redirection. 6. OP authenticate the user and sign to the challenge with OP's secret key. 7. OP send the assertion including the signed challenge back to the RP via redirection. 8. Now RP can verify the assertion with the signature using OP's public key. The good thing about this sequence is not only reducing network traffic, but this can be a solution against man-in-the-middle attacks, to which OpenID has principle vulnerability. I think this spec can be quite useful for the next version of OpenID protocol. Does someone know the status of it? =masaki ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Service Key Discovery 1.0
Thank you Hans. About RP-OP SSL connection, major web languages like Java, PHP, Rubt etc. has APIs or libraries about HTTP/HTTPS. I believe in most case it is possible to configure web applications to trust only seceral certificates explicitly just modify certificate store those languages uses. Interesting idea. Is there a way to do this via an RP- OP SSL handshake? Web apps typically don't have access to SSL private keys, at least in larger deployments. I wonder how your idea reduces network traffic, though. Don't you still have to retrieve the public key, which is likely larger than the associate message payload? About traffic, I was wrong. As you pointed out, number of http request is basically same to assotiation mode of OpenID 2.0. I think hurdles against your idea are: 1. availability of public key cryptography in the RP libraries, and 2. fear that it's hard to correctly implement public key cryptography Hans On 1/21/08, NISHITANI Masaki [EMAIL PROTECTED] wrote: Hi all. What concerns me these days is about secure data exchange over OpenID for serious services and about this theme, I came upon an specification, secure key discovery 1.0 For my understanding, this spec is about implementing security framework on OpenID world and is still very draft. Now I'd like to figure out some point I found. - In this, the url of the public key is defined to be in the XRD document and entities will make another request for the url to retrieve the public key itself. This gives bad people a chance to pass off a fake key with poisoning the end-user's DNS. How about to put public key itself in the XRD or someone else the entity trusts (a key server)? The entity only has to manage SSL certificate fingerprints of XRD authorities or trusting key servers. - With secure key discovery, we do have to use association or verification message no longer. I think we can optimize OpenID protocol using digital signature with public keys. This can be done with following procedure. 1. End-user enter its OpenID in RP site. 2. RP resolve the id and select the user's OP. 3. In the same time, RP retrieve the OP's public key. 4. RP generate a challenge (maybe the user's http session id) 5. RP send the id to the OP via http redirection. 6. OP authenticate the user and sign to the challenge with OP's secret key. 7. OP send the assertion including the signed challenge back to the RP via redirection. 8. Now RP can verify the assertion with the signature using OP's public key. The good thing about this sequence is not only reducing network traffic, but this can be a solution against man-in-the-middle attacks, to which OpenID has principle vulnerability. I think this spec can be quite useful for the next version of OpenID protocol. Does someone know the status of it? =masaki ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Service Key Discovery 1.0
FWIW, the XRI form of openID's provides just such a mechanism, where- by the publisher of the XRD signs all (or a part of) the XRDS, tho i know of few libraries today which support trusted resolution[1]. =peterd [1] http://docs.oasis-open.org/xri/2.0/specs/cd02/xri-resolution-V2.0- cd-02.pdf On Jan 21, 2008, at 5:38 AM, NISHITANI Masaki wrote: Hi all. What concerns me these days is about secure data exchange over OpenID for serious services and about this theme, I came upon an specification, secure key discovery 1.0 For my understanding, this spec is about implementing security framework on OpenID world and is still very draft. Now I'd like to figure out some point I found. - In this, the url of the public key is defined to be in the XRD document and entities will make another request for the url to retrieve the public key itself. This gives bad people a chance to pass off a fake key with poisoning the end-user's DNS. How about to put public key itself in the XRD or someone else the entity trusts (a key server)? The entity only has to manage SSL certificate fingerprints of XRD authorities or trusting key servers. - With secure key discovery, we do have to use association or verification message no longer. I think we can optimize OpenID protocol using digital signature with public keys. This can be done with following procedure. 1. End-user enter its OpenID in RP site. 2. RP resolve the id and select the user's OP. 3. In the same time, RP retrieve the OP's public key. 4. RP generate a challenge (maybe the user's http session id) 5. RP send the id to the OP via http redirection. 6. OP authenticate the user and sign to the challenge with OP's secret key. 7. OP send the assertion including the signed challenge back to the RP via redirection. 8. Now RP can verify the assertion with the signature using OP's public key. The good thing about this sequence is not only reducing network traffic, but this can be a solution against man-in-the-middle attacks, to which OpenID has principle vulnerability. I think this spec can be quite useful for the next version of OpenID protocol. Does someone know the status of it? =masaki ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Service Key Discovery 1.0
Masaki, Peter has a good point -- the XRDS keyinfo discovery mechanism, specified in section 10.2 (SAML Trusted Resolution) of XRI Resolution 2.0 Committee Draft 02 (http://docs.oasis-open.org/xri/2.0/specs/cd02/xri-resolution-V2.0-cd-02.pdf ), deals with DNS poisoning by using signed SAML assertions (including the ds:keyInfo element) for each authority in the resolution chain. So presuming HTTPS is used for the first root authority call, you should be good all the way down the chain as long as signatures verify. (Peter's also right that libraries have not implemented it yet, but that may be changing soon as demand for secure key discovery rises...) =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Davis Sent: Monday, January 21, 2008 6:33 AM To: NISHITANI Masaki Cc: specs@openid.net Subject: Re: Service Key Discovery 1.0 FWIW, the XRI form of openID's provides just such a mechanism, where- by the publisher of the XRD signs all (or a part of) the XRDS, tho i know of few libraries today which support trusted resolution[1]. =peterd [1] http://docs.oasis-open.org/xri/2.0/specs/cd02/xri-resolution-V2.0- cd-02.pdf On Jan 21, 2008, at 5:38 AM, NISHITANI Masaki wrote: Hi all. What concerns me these days is about secure data exchange over OpenID for serious services and about this theme, I came upon an specification, secure key discovery 1.0 For my understanding, this spec is about implementing security framework on OpenID world and is still very draft. Now I'd like to figure out some point I found. - In this, the url of the public key is defined to be in the XRD document and entities will make another request for the url to retrieve the public key itself. This gives bad people a chance to pass off a fake key with poisoning the end-user's DNS. How about to put public key itself in the XRD or someone else the entity trusts (a key server)? The entity only has to manage SSL certificate fingerprints of XRD authorities or trusting key servers. - With secure key discovery, we do have to use association or verification message no longer. I think we can optimize OpenID protocol using digital signature with public keys. This can be done with following procedure. 1. End-user enter its OpenID in RP site. 2. RP resolve the id and select the user's OP. 3. In the same time, RP retrieve the OP's public key. 4. RP generate a challenge (maybe the user's http session id) 5. RP send the id to the OP via http redirection. 6. OP authenticate the user and sign to the challenge with OP's secret key. 7. OP send the assertion including the signed challenge back to the RP via redirection. 8. Now RP can verify the assertion with the signature using OP's public key. The good thing about this sequence is not only reducing network traffic, but this can be a solution against man-in-the-middle attacks, to which OpenID has principle vulnerability. I think this spec can be quite useful for the next version of OpenID protocol. Does someone know the status of it? =masaki ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
