Re: [OpenID] OpenID Assertion Quality Extension - Draft
This information is usually listed on the registartion page anyway. 8-16 characters. Letters and numbers only. No spaces. Case sensitive. - password change screen from Comcast.net Must be at least 6 characters long. - registration page from digg.com Choose a secure password, which: is at least six characters long. contains at least four different characters. contains at least one number or symbol. cannot be based upon your username, display name or email address. - registration page from livejournal.com Generally, someone could find this information by taking only a few seconds of searching. (or having their own valid account in the Comcast case) Daniel E. Renfer http://kronkltd.net/ On 12/7/06, Granqvist, Hans [EMAIL PROTECTED] wrote: It might be useful to some RP's to know of any complexity schemes put on users' passwords. ... What do you think? I think this is excellent information . . . for someone trying to figure out your password! -Hans ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Re: [OpenID] OpenID Assertion Quality Extension - Draft
Yeah, we looked at this a bit when drafting the extension originally. There are just so many factors that go into password choice/enforcement that describing them becomes quite difficult. It also is possible to describe features which actually are just red herrings. I wish it was simpler so something could be included. :-\ Also pulling general@ off this thread. --David -Original Message- From: Avery Glasser [mailto:[EMAIL PROTECTED] Sent: Saturday, December 02, 2006 8:35 PM To: [EMAIL PROTECTED] Cc: Recordon, David; specs@openid.net; [EMAIL PROTECTED] Subject: RE: Re: [OpenID] OpenID Assertion Quality Extension - Draft Daniel, It's not a bad idea, but it doesn't actually drive any more knowledge about the security of the authentication. There are so many factors when calculating the entropy and overall security of a password that I don't think it should be included in the AQE. Listing the password length, the criteria for the password, how long since last password change and other factors should probably be either part of the Attribute Exchange or the eventual convergence/alignment with SAML AC. - Avery It might be useful to some RP's to know of any complexity schemes put on users' passwords. How about: password.min_length=8 password.max_length=16 the number of characters that the password is between. password.max_length would probably be more useful as I don't see many RP's complaining if the OP allows for long passwords. I can see the RP wanting my password to be at least for characters though. password.complexity=alphanumeric,mixed-case a comma separated list of common restrictions to the password's format. Some possible values: none, numeric, alpha, alphanumeric, lower-case, upper-case, mixed-case, non-dictionary, case-insensitive none or omitting one of the facets would have the effect of allowing alphanumeric characters of any case + possible some special characters. case sensitive. What do you think? Daniel E. Renfer http://kronkltd.net/ On 12/1/06, Avery Glasser [EMAIL PROTECTED] wrote: All, Attached is the new XML for draft 2 of the AQE spec. It has been checked into SVN as release 140. David, Can you convert it to HTML and repost it to the list? -- Avery == Avery Glasser CTO VxV Solutions, Inc. + 1.415.992.7264 - office + 1.415.290.1400 - mobile + 1.415.651.9218 - fax 329 Bryant Street, Suite 2D San Francisco, CA 94107 email: [EMAIL PROTECTED] i-name: =avery == This e-mail (including any attachments), is confidential and intended only for the use of the addressee(s). It may contain information covered by legal, professional or other privilege. If you are not an addressee, please inform the sender immediately and destroy this e-mail. Do not copy, forward, use or disclose this e-mail. Thank you. -- == Avery Glasser VxV Solutions, Inc. + 1.415.992.7264 - office + 1.415.290.1400 - mobile + 1.415.651.9218 - fax 329 Bryant Street, Suite 2D San Francisco, CA 94107 == This e-mail (including any attachments), is confidential and intended only for the use of the addressee(s). It may contain information covered by legal, professional or other privilege. If you are not an addressee, please inform the sender immediately and destroy this e-mail. Do not copy, forward, use or disclose this e-mail. Thank you. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [OpenID] OpenID Assertion Quality Extension - Draft
It might be useful to some RP's to know of any complexity schemes put on users' passwords. How about: password.min_length=8 password.max_length=16 the number of characters that the password is between. password.max_length would probably be more useful as I don't see many RP's complaining if the OP allows for long passwords. I can see the RP wanting my password to be at least for characters though. password.complexity=alphanumeric,mixed-case a comma separated list of common restrictions to the password's format. Some possible values: none, numeric, alpha, alphanumeric, lower-case, upper-case, mixed-case, non-dictionary, case-insensitive none or omitting one of the facets would have the effect of allowing alphanumeric characters of any case + possible some special characters. case sensitive. What do you think? Daniel E. Renfer http://kronkltd.net/ On 12/1/06, Avery Glasser [EMAIL PROTECTED] wrote: All, Attached is the new XML for draft 2 of the AQE spec. It has been checked into SVN as release 140. David, Can you convert it to HTML and repost it to the list? -- Avery == Avery Glasser CTO VxV Solutions, Inc. + 1.415.992.7264 - office + 1.415.290.1400 - mobile + 1.415.651.9218 - fax 329 Bryant Street, Suite 2D San Francisco, CA 94107 email: [EMAIL PROTECTED] i-name: =avery == This e-mail (including any attachments), is confidential and intended only for the use of the addressee(s). It may contain information covered by legal, professional or other privilege. If you are not an addressee, please inform the sender immediately and destroy this e-mail. Do not copy, forward, use or disclose this e-mail. Thank you. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [OpenID] OpenID Assertion Quality Extension - Draft
Hi Avery, some minor tweaks/comments 1) the line 'the first method that the RP would like the OP to perform' could be interpreted as constraining the O/IDP to performing whatever authentication mechanism is listed as the first in a temporal sequence, i.e. must do X then Y This could be overly restrictive 2) the line 'If the two modes are considered equally strong, then it is the choice of the OP regarding which one or ones to authenticate against' could confuse, as the 'or ones' would seem to allow the OP to choose multiple modes from within the openid.aqe.auth_factor2 3) Suggest openid.aqe.auth_factor2 MUST NOT be present unless openid.aqe.auth_factor1 is present 4) The line 'If this is not specified, it is assumed that the RP is requesting only a single factor for authentication' in the context of openid.aqe.auth_factor2 should probably read If this is not specified, it is assumed that the RP is requesting only a single factor for authentication (if openid.aqe.auth_factor2 is specified ) or not requesting a particular authentication method paul Avery Glasser wrote: Just to weigh in here... Paul Madsen wrote: Hi George, for your use case below, why would not the RP just ask for the user to be up-authenticated at the desired higher level when necessary? So in the draft... how does the RP ask for the user to be up-authenticated? The authentication request parameters do not in any way indicate a previous authentication, and the extension parameters also don't include any way to indicate a previous authentication. That is what I really meant by the authentications being standalone. The RP may relate the two authentications in some way because it requested both. Maybe that's good enough. Basically, you would require the second method with a max_age of 0 - which, assuming the RP honors the request, would tell the RP to re-authenticate the user with the requested method. Are you asking whether the RP should be allowed to ask the user to re-present their URI in order for this to happen? And thereby effectively treating each event as disconnected/standalone? Ideally, the user would not be able to change their URI when being re-challenged based on max_auth_age but I guess the RP should make sure to code for that edge case. Agreed - it's the RPs choice. Wrt combinations, I know from experience that the alternative to allowing for RPs to specify combinations is a combinatorial explosion in the number of mechanism identifiers. I agree that the combinations can explode... but they are also useful. For example to hack my account you need both my password and my hardotp. That's two secrets that need to be determined for my account to be compromised. (Not that this doesn't stop phishers). Actually, this could be pretty simple to implement: Replace openid.aqe.preferred_auth_mode with the following: openid.aqe.auth_factor1 Optional: The method of authentication the RP would like the OP to perform, or in the case of a multi-factor authentication, the first method that the RP would like the OP to perform. The mode should match one of the advertised values in the XRDS. If this is not specified, then any authentication method is acceptable. Value: Comma-delimited list of none, password, pin, fingerbio, handbio, hardotp, irisbio, otherbio, smartcard, softotp, voicebio Note: The OP should attempt to authenticate the user with the most secure mode requested. For example, if the OP has determined that their voicebio method is stronger than their password method and the RP requests either voicebio or password, the OP should strive to authenticate the user by voicebio when possible. If the two modes are considered equally strong, then it is the choice of the OP regarding which one or ones to authenticate against. OPs should note that authenticating a user by a non-preferred method may result in an RP denying access. openid.aqe.auth_factor2 Optional: In the case of a multi-factor authentication, the second method that the RP would like the OP to perform. The mode should match one of the advertised values in the XRDS. If this is not specified, then any authentication method is acceptable. If this is not specified, it is assumed that the RP is requesting only a single factor for authentication. The OP will not use the same method for this factor as was used in any previous factors. For example, if the first factor is a password, the second factor cannot also be a password. Value: Comma-delimited list of none, password, pin, fingerbio, handbio, hardotp, irisbio, otherbio, smartcard, softotp, voicebio Note: The OP should attempt to authenticate the user with the most secure mode requested. For example, if the OP has determined that their voicebio method is stronger than their password method and the RP requests either voicebio or password, the OP should strive to authenticate the
Re: [OpenID] OpenID Assertion Quality Extension - Draft
Avery, below Avery Glasser wrote: Paul, My feedback to your feedback... Hi Avery, some minor tweaks/comments 1) the line 'the first method that the RP would like the OP to perform' could be interpreted as constraining the O/IDP to performing whatever authentication mechanism is listed as the first in a temporal sequence, i.e. must do X then Y This could be overly restrictive Actually, that is the specific intent - the RP is requesting a specific order. If the OP can honor the order, that is fine. If not, then the OP reports back to the RP what the order was in the response. As long as the two methods are honored, then the RP should accept the authentication. If the RP specified a particular order and didn't see it come back in the IDP response, it has a choice, accept the assertion regardless, or not. If the latter, how can it indicate to the IDP in a second authentication request 'This time I mean it?' I think you either say order isn't important in the request, or, if it is, give the IDP a mechanism to say it couldn't satisfy the order. paul 2) the line 'If the two modes are considered equally strong, then it is the choice of the OP regarding which one or ones to authenticate against' could confuse, as the 'or ones' would seem to allow the OP to choose multiple modes from within the openid.aqe.auth_factor2 Agreed. I would change that to the one - since each factor now refers to a specific authentication method. 3) Suggest openid.aqe.auth_factor2 MUST NOT be present unless openid.aqe.auth_factor1 is present Agreed. 4) The line 'If this is not specified, it is assumed that the RP is requesting only a single factor for authentication' in the context of openid.aqe.auth_factor2 should probably read If this is not specified, it is assumed that the RP is requesting only a single factor for authentication (if openid.aqe.auth_factor2 is specified ) or not requesting a particular authentication method Agreed. paul Based on this, is there any other feedback, or shall we revise the specification? - Avery Avery Glasser wrote: Just to weigh in here... Paul Madsen wrote: Hi George, for your use case below, why would not the RP just ask for the user to be up-authenticated at the desired higher level when necessary? So in the draft... how does the RP ask for the user to be up-authenticated? The authentication request parameters do not in any way indicate a previous authentication, and the extension parameters also don't include any way to indicate a previous authentication. That is what I really meant by the authentications being standalone. The RP may relate the two authentications in some way because it requested both. Maybe that's good enough. Basically, you would require the second method with a max_age of 0 - which, assuming the RP honors the request, would tell the RP to re-authenticate the user with the requested method. Are you asking whether the RP should be allowed to ask the user to re-present their URI in order for this to happen? And thereby effectively treating each event as disconnected/standalone? Ideally, the user would not be able to change their URI when being re-challenged based on max_auth_age but I guess the RP should make sure to code for that edge case. Agreed - it's the RPs choice. Wrt combinations, I know from experience that the alternative to allowing for RPs to specify combinations is a combinatorial explosion in the number of mechanism identifiers. I agree that the combinations can explode... but they are also useful. For example to hack my account you need both my password and my hardotp. That's two secrets that need to be determined for my account to be compromised. (Not that this doesn't stop phishers). Actually, this could be pretty simple to implement: Replace openid.aqe.preferred_auth_mode with the following: openid.aqe.auth_factor1 Optional: The method of authentication the RP would like the OP to perform, or in the case of a multi-factor authentication, the first method that the RP would like the OP to perform. The mode should match one of the advertised values in the XRDS. If this is not specified, then any authentication method is acceptable. Value: Comma-delimited list of none, password, pin, fingerbio, handbio, hardotp, irisbio, otherbio, smartcard, softotp, voicebio Note: The OP should attempt to authenticate the user with the most secure mode requested. For example, if the OP has determined that their voicebio method is stronger than their password method and the RP requests either voicebio or password, the OP should strive to authenticate the user by voicebio when possible. If the two modes are considered equally strong, then it is the choice of the OP regarding which one or ones to authenticate against. OPs should note that authenticating a user by a non-preferred method may result in an RP
Re: [OpenID] OpenID Assertion Quality Extension - Draft
Hi George, for your use case below, why would not the RP just ask for the user to be up-authenticated at the desired higher level when necessary? Are you asking whether the RP should be allowed to ask the user to re-present their URI in order for this to happen? And thereby effectively treating each event as disconnected/standalone? Wrt combinations, I know from experience that the alternative to allowing for RPs to specify combinations is a combinatorial explosion in the number of mechanism identifiers. Paul George Fletcher wrote: +1 simple and straight forward Just curious about uses cases where the required authentication level changes over time. For instance, a use case where to view my stock portfolio just requires password, but doing a trade requires voicebio. Is the expectation that authentication events can be treated as standalone? or that it's the RP's responsibility to manage the combinations based on the identifier? One final question... Is it valuable to provide a way to request two or more authentication methods be employed in the authentication event? For example, administrators of a site must use both password and hardotp. Everyone else just needs password. Thanks, George ___ general mailing list [EMAIL PROTECTED] http://openid.net/mailman/listinfo/general -- Paul Madsen e:paulmadsen @ ntt-at.com NTT p:613-482-0432 m:613-302-1428 aim:PaulMdsn5 web:connectid.blogspot.com ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [OpenID] OpenID Assertion Quality Extension - Draft
Paul Madsen wrote: Hi George, for your use case below, why would not the RP just ask for the user to be up-authenticated at the desired higher level when necessary? So in the draft... how does the RP ask for the user to be "up-authenticated"? The authentication request parameters do not in any way indicate a previous authentication, and the extension parameters also don't include any way to indicate a previous authentication. That is what I really meant by the authentications being "standalone". The RP may relate the two authentications in some way because it requested both. Maybe that's good enough. Are you asking whether the RP should be allowed to ask the user to re-present their URI in order for this to happen? And thereby effectively treating each event as disconnected/standalone? Ideally, the user would not be able to change their URI when being re-challenged based on max_auth_age but I guess the RP should make sure to code for that edge case. Wrt combinations, I know from experience that the alternative to allowing for RPs to specify combinations is a combinatorial explosion in the number of mechanism identifiers. I agree that the combinations can explode... but they are also useful. For example to hack my account you need both my "password" and my "hardotp". That's two "secrets" that need to be determined for my account to be compromised. (Not that this doesn't stop phishers). Thanks, George Paul George Fletcher wrote: +1 simple and straight forward Just curious about uses cases where the required authentication level changes over time. For instance, a use case where to view my stock portfolio just requires "password", but doing a trade requires "voicebio". Is the expectation that authentication events can be treated as "standalone"? or that it's the RP's responsibility to manage the combinations based on the identifier? One final question... Is it valuable to provide a way to request two or more authentication methods be employed in the authentication event? For example, administrators of a site must use both "password" and "hardotp". Everyone else just needs "password". Thanks, George ___ general mailing list [EMAIL PROTECTED] http://openid.net/mailman/listinfo/general ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [OpenID] OpenID Assertion Quality Extension - Draft
Avery, Paul's the one to weigh in on this option - he wrote (and lived) the book on SAML AuthN Context. But I do like the looks of what you proposed - seems very elegant. =Drummond _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Avery Glasser Sent: Thursday, November 30, 2006 2:22 PM To: George Fletcher Cc: specs@openid.net; [EMAIL PROTECTED] Subject: Re: [OpenID] OpenID Assertion Quality Extension - Draft Just to weigh in here... Paul Madsen wrote: Hi George, for your use case below, why would not the RP just ask for the user to be up-authenticated at the desired higher level when necessary? So in the draft... how does the RP ask for the user to be up-authenticated? The authentication request parameters do not in any way indicate a previous authentication, and the extension parameters also don't include any way to indicate a previous authentication. That is what I really meant by the authentications being standalone. The RP may relate the two authentications in some way because it requested both. Maybe that's good enough. Basically, you would require the second method with a max_age of 0 - which, assuming the RP honors the request, would tell the RP to re-authenticate the user with the requested method. Are you asking whether the RP should be allowed to ask the user to re-present their URI in order for this to happen? And thereby effectively treating each event as disconnected/standalone? Ideally, the user would not be able to change their URI when being re-challenged based on max_auth_age but I guess the RP should make sure to code for that edge case. Agreed - it's the RPs choice. Wrt combinations, I know from experience that the alternative to allowing for RPs to specify combinations is a combinatorial explosion in the number of mechanism identifiers. I agree that the combinations can explode... but they are also useful. For example to hack my account you need both my password and my hardotp. That's two secrets that need to be determined for my account to be compromised. (Not that this doesn't stop phishers). Actually, this could be pretty simple to implement: Replace openid.aqe.preferred_auth_mode with the following: openid.aqe.auth_factor1 Optional: The method of authentication the RP would like the OP to perform, or in the case of a multi-factor authentication, the first method that the RP would like the OP to perform. The mode should match one of the advertised values in the XRDS. If this is not specified, then any authentication method is acceptable. Value: Comma-delimited list of none, password, pin, fingerbio, handbio, hardotp, irisbio, otherbio, smartcard, softotp, voicebio Note: The OP should attempt to authenticate the user with the most secure mode requested. For example, if the OP has determined that their voicebio method is stronger than their password method and the RP requests either voicebio or password, the OP should strive to authenticate the user by voicebio when possible. If the two modes are considered equally strong, then it is the choice of the OP regarding which one or ones to authenticate against. OPs should note that authenticating a user by a non-preferred method may result in an RP denying access. openid.aqe.auth_factor2 Optional: In the case of a multi-factor authentication, the second method that the RP would like the OP to perform. The mode should match one of the advertised values in the XRDS. If this is not specified, then any authentication method is acceptable. If this is not specified, it is assumed that the RP is requesting only a single factor for authentication. The OP will not use the same method for this factor as was used in any previous factors. For example, if the first factor is a password, the second factor cannot also be a password. Value: Comma-delimited list of none, password, pin, fingerbio, handbio, hardotp, irisbio, otherbio, smartcard, softotp, voicebio Note: The OP should attempt to authenticate the user with the most secure mode requested. For example, if the OP has determined that their voicebio method is stronger than their password method and the RP requests either voicebio or password, the OP should strive to authenticate the user by voicebio when possible. If the two modes are considered equally strong, then it is the choice of the OP regarding which one or ones to authenticate against. OPs should note that authenticating a user by a non-preferred method may result in an RP denying access. openid.aqe.auth_factor3 ... you can figure how it would continue. There are very few use cases that would use more than two factors. So, in this case, if you want the user to authenticate with two factors, first with a password and second with a securID or voice biometric print... openid.aqe.auth_factor1 = password openid.aqe.auth_factor2 = hardotp, voicebio conversely, if you want two factors, which could
Re: [OpenID] OpenID Assertion Quality Extension - Draft
+1 Avery Glasser wrote: Actually, this could be pretty simple to implement: Replace openid.aqe.preferred_auth_mode with the following: openid.aqe.auth_factor1 Optional: The method of authentication the RP would like the OP to perform, or in the case of a multi-factor authentication, the first method that the RP would like the OP to perform. The mode should match one of the advertised values in the XRDS. If this is not specified, then any authentication method is acceptable. Value: Comma-delimited list of "none", "password", "pin", "fingerbio", "handbio", "hardotp", "irisbio", "otherbio", "smartcard", "softotp", "voicebio" Note: The OP should attempt to authenticate the user with the most secure mode requested. For example, if the OP has determined that their voicebio method is stronger than their password method and the RP requests either "voicebio or password", the OP should strive to authenticate the user by "voicebio" when possible. If the two modes are considered equally strong, then it is the choice of the OP regarding which one or ones to authenticate against. OPs should note that authenticating a user by a non-preferred method may result in an RP denying access. openid.aqe.auth_factor2 Optional: In the case of a multi-factor authentication, the second method that the RP would like the OP to perform. The mode should match one of the advertised values in the XRDS. If this is not specified, then any authentication method is acceptable. If this is not specified, it is assumed that the RP is requesting only a single factor for authentication. The OP will not use the same method for this factor as was used in any previous factors. For example, if the first factor is a password, the second factor cannot also be a password. Value: Comma-delimited list of "none", "password", "pin", "fingerbio", "handbio", "hardotp", "irisbio", "otherbio", "smartcard", "softotp", "voicebio" Note: The OP should attempt to authenticate the user with the most secure mode requested. For example, if the OP has determined that their voicebio method is stronger than their password method and the RP requests either "voicebio or password", the OP should strive to authenticate the user by "voicebio" when possible. If the two modes are considered equally strong, then it is the choice of the OP regarding which one or ones to authenticate against. OPs should note that authenticating a user by a non-preferred method may result in an RP denying access. openid.aqe.auth_factor3 ... you can figure how it would continue. There are very few use cases that would use more than two factors. So, in this case, if you want the user to authenticate with two factors, first with a password and second with a securID or voice biometric print... openid.aqe.auth_factor1 = "password" openid.aqe.auth_factor2 = "hardotp", "voicebio" conversely, if you want two factors, which could be any combination of password, hardotp or voicebio in any combination: openid.aqe.auth_factor1 = "hardotp", "voicebio", "password" openid.aqe.auth_factor2 = "hardotp", "voicebio", "password" the response from the OP, assuming that it followed the request from the RP would look like openid.aqe.auth_factor1 = "password" openid.aqe.auth_factor2 = "hardotp" I would think that this is clear enough that we could make the small change to the spec to allow for this type of methodology. Thoughts? - Avery ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
