[osis-general] OSIS PAPE call results
David Recordon
drecordon at sixapart.com
Wed Nov 7 17:53:31 UTC 2007
I don't think I disagree with Mike on a single point here. I'll
forward Mike's proposed change to the definition of phishing resistant
to Ben Laurie as he too was involved in the original definition.
Another extension looking at either enrollment properties or the
actual authentication mechanism used would not be hard to draft. For
the time being, we should not include this functionality in PAPE.
Remember the UNIX philosophy, do one thing and do it really well!
CC'ing this message to the specs at openid.net list to catch everyone up
on the discussion.
Thanks,
--David
On Nov 6, 2007, at 9:25 PM, Mike Jones wrote:
> Let me react to what I believe is your core point around phishing-
> resistance and then respond to particulars. You wrote:
>
> Again - the root cause of the differing opinions is that the policy
> is very subjective and its going to be very hard for us to nail down
> what it exactly signifies.
>
> To the extent that people believe the definition of phishing-
> resistant is subjective, we've either failed to be sufficiently
> precise or people have failed to understand the definition. The
> definition in draft 2 reads:
>
> · Phishing-Resistant Authentication
> An authentication mechanism where the End User does not provide a
> shared secret to a party potentially under the control of the
> Relying Party. (Note that the potentially malicious Relying Party
> controls where the User-Agent is redirected to and thus may not send
> it to the End User's actual OpenID Provider).
>
> The consensus both among the spec authors and those on the call was
> that this definition is already sufficiently clear to be able to
> make objective determinations about whether particular methods meet
> this criterion or not. Based on the recent discussion, I'd actually
> reword it slightly to be even more clear so that it reads as follows
> (while leaving the intended meaning and the determinations that
> result the same):
>
> · Phishing-Resistant Authentication
> An authentication mechanism where the End User does not provide
> shared secrets to a party potentially under the control of the
> Relying Party that could enable that party to then authenticate
> elsewhere as if it were the End User. (Note that the potentially
> malicious Relying Party controls where the User-Agent is redirected
> to and thus may not send it to the End User's actual OpenID Provider).
>
> I agree with you that a subjective definition serves no one well.
> If you believe that this definition is not already sufficiently
> clear the best thing to do would be to suggest precise wording to
> tighten it up until you believe that it can be objectively applied.
>
> Next, let me respond to some of your other points:
>
> [Siddharth] This is actually an area where we had the different
> opinions on the mailing list. Per Kim's email we would like to see
> the group take a realistic approach of treating security more as a
> continuum.
> I agree that it's a continuum. I also agree that subjective,
> squishy definitions will do more harm than good. By example,
> passwords are neither phishing-resistant nor multi-factor. Self-
> issued InfoCards are phishing-resistant but not multi-factor (unless
> you count having the card on your machine as a factor). OTPs are
> multi-factor but not phishing-resistant. Client-side certificates
> backed by a PIN are both phishing-resistant and multi-factor. Etc.
> It is a continuum, but we still need to be precise about applying
> the meanings of the different terms or they become valueless.
>
> We should also discuss scenarios where the OP is using phishing
> resistant server authentication technologies such as EV SSL
> certificates as well.
> I agree that EV certificates help but the problem is that you're
> counting on the user to notice that the phishing site didn't have an
> EV cert. Your password and/or OTP value could still be phished if
> the user didn't notice the difference and then used at the real site
> by the attacker. EV certs will reduce phishing (which is good!) but
> can't prevent it.
>
> On a related note, I saw a blog post about CardSpace not requiring
> SSL in the future. We should discuss how that would affect the
> security properties as well.
> Agreed, this is a good discussion to have. Because no shared secret
> is being released that can be used by the attacker to impersonate
> you at other sites, this is still phishing-resistant with respect to
> the PPID released for authentication purposes. I highly recommend
> that those who are interested in this topic read Vittorio Bertocci's
> treatment of the subject.
>
> Again - the root cause of the differing opinions is that the policy
> is very subjective and its going to be very hard for us to nail down
> what it exactly signifies.
> The English phrase "phishing-resistant", I agree is subjective. The
> definition included in the specification is not. Using the
> definition rather than the possible subjective meanings of the
> phrase will remove this ambiguity.
>
> [Siddharth] That's good feedback. However if I'm not releasing any
> PII, I don't see why this could be a privacy issue. And of course
> its well understood in the security space that 'security by
> obscurity' doesn't work.
> No one was suggesting security by obscurity. However I know that
> I've heard from more than one person, including Kim, that they'd
> rather not give attackers any information that they could use to
> refine their attacks that's not absolutely necessary to convey.
> This goes back to Law 2: "Minimal Disclosure for a Defined Use".
>
> It could certainly be valuable to some RPs this information about
> authentication credential itself, while other RPs could care less. I
> think we should explore what is the best way for the OP to
> optionally convey this information.
> No argument there. It should be left up to the market to decide
> whether to do this or not. That's why, if demand arises for it, a
> separate parallel specification should be developed for
> communicating this information. Then RPs and OPs can decide for
> themselves.
>
> One thought is that we can include an extension point in the PAPE
> spec.
> That actually violates the compromise that was made to get the PAPE
> spec out at all. Some felt that both authentication policies and
> authentication methods could be covered by the same spec. Others
> were strongly opposed to this, for some of the reasons stated above,
> as well as others. In the end we decided that the two were
> different and should be covered by different specifications.
>
> I suspect that any authentication methods specification would be
> similar in form to the PAPE spec. But lacking any demonstrated
> demand for it, no one wanted to take on the additional effort to
> write this second specification on a speculative basis, even though
> doing it would be simple. If demand for this materializes I'm sure
> that it could be written quickly. If so, it should try to borrow
> from other's work on this topic, including that done by the SAML
> committee.
>
> Best wishes,
> -- Mike
>
> From: Bajaj, Siddharth [mailto:SBajaj at verisign.com]
> Sent: Tuesday, November 06, 2007 10:14 AM
> To: Mike Jones
> Cc: Bradescu, Roxana; david at sixapart.com; Johnny Bufu; osis-general at netmesh.org
> Subject: RE: [osis-general] OSIS PAPE call results
>
>
> That resolves one. Others that I haven't heard back from folks on
> the couple of other points
>
> - The table in Appendix A.1.1 of http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-02.html
> needs to be updated to be consistent with the definition in Section
> 4.
> Specifically:
>
> PIN and soft OTP token should not be marked as
> phishing-resistant.
>
> PIN and hard OTP token should not be marked as
> phishing-resistant.
>
> Information Cards should be added and listed as
> phishing-resistant.
>
> Active password managers that only release the
> password to the correct site should be listed as phishing-resistant.
>
> [Siddharth] This is actually an area where we had the different
> opinions on the mailing list. Per Kim's email we would like to see
> the group take a realistic approach of treating security more as a
> continuum . We should also discuss scenarios where the OP is using
> phishing resistant server authentication technologies such as EV SSL
> certificates as well. On a related note, I saw a blog
> post about CardSpace not requiring SSL in the future. We should
> discuss how that would affect the security properties as well. Again
> - the root cause of the differing opinions is that the policy is
> very subjective and its going to be very hard for us to nail down
> what it exactly signifies.
>
> - If relying parties and OPs want to communicate actual
> authentication methods used, that should happen via a different spec
> than PAPE. Then the market can decide whether to use PAPE,
> this spec, both, or neither. (However some in the group have both
> privacy concerns about this and concerns about enabling attackers by
> giving them additional information to use in their
> attacks.)
>
> [Siddharth] That's good feedback. However if I'm not releasing any
> PII, I don't see why this could be a privacy issue. And of course
> its well understood in the security space that 'security by
> obscurity' doesn't work. . It could certainly be valuable to some
> RPs this information about authentication credential itself, while
> other RPs could care less. I think we should explore what is the
> best way for the OP to optionally convey this information. One
> thought is that we can include an extension point in the PAPE spec.
> Thanks,
>
> Siddharth
>
> From: Mike Jones [mailto:Michael.Jones at microsoft.com]
> Sent: Tuesday, November 06, 2007 10:11 AM
> To: Bajaj, Siddharth
> Cc: Bradescu, Roxana; david at sixapart.com; Johnny Bufu; osis-general at netmesh.org
> Subject: RE: [osis-general] OSIS PAPE call results
> Very good. It's this second phase that didn't know enough about.
> So guess I can count one of my accomplishments today as learning
> more about the crypto behind client-side certs. :-)
>
> Definitely phishing-resistant…
>
> Thanks Siddharth,
> -- Mike
>
> From: Bajaj, Siddharth [mailto:sbajaj at verisign.com]
> Sent: Tuesday, November 06, 2007 10:06 AM
> To: Mike Jones
> Cc: Bradescu, Roxana; david at sixapart.com; Johnny Bufu; osis-general at netmesh.org
> Subject: Re: [osis-general] OSIS PAPE call results
>
>
> A good reference of SSL works is at RSA Labs Crypto FAQ - http://www.rsa.com/rsalabs/node.asp?id=2293
> The SSL Handshake Protocol consists of two phases: server
> authentication and an optional client authentication. In the first
> phase, the server, in response to a client's request, sends its
> certificate and its cipher preferences. The client then generates a
> master key, which it encrypts with the server's public key, and
> transmits the encrypted master key to the server. The server
> recovers the master key and authenticates itself to the client by
> returning a message authenticated with the master key. Subsequent
> data is encrypted and authenticated with keys derived from this
> master key. In the optional second phase, the server sends a
> challenge to the client. The client authenticates itself to the
> server by returning the client's digital signature on the challenge,
> as well as its public-key certificate.
>
> Siddharth
>
> Mike Jones wrote:
>
>> Sorry for the confusion. I apparently failed to successfully ask a
>> question about this point to those of you who are experts out
>> there, so let me try again…
>> The table in Appendix A.1.1 at http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-02.html#anchor13
>> contains the method description "PIN and digital certificate via
>> HTTPS". The question I tried to ask was: does this method release
>> different information to every relying party or does it release the
>> same information to each relying party?
>> Maybe even more to the point: does using the certificate at one
>> relying party release enough information for that relying party to
>> then be able to authenticate to another one as you? That's the
>> crux of the issue that decides the phishability question.
>> Thanks,
>> -- Mike
>> From: Bradescu, Roxana [mailto:rbradescu at verisign.com]
>>
>> Sent: Tuesday, November 06, 2007 7:58 AM
>> To: Bajaj, Siddharth; Mike Jones; david at sixapart.com; Johnny Bufu; osis-general at netmesh.org
>> Subject: RE: [osis-general] OSIS PAPE call results
>> Any responses to Sidd’s feedback?? The last point particularly
>> about SSL client auth (user to IDP) being considered phishable and
>> requiring different certs per RP doesn’t really make sense.
>> Roxana Bradescu | VeriSign Innovation | office: 650-426-4489 |
>> mobile: 650-576-9262 | rbradescu at verisign.com
>> From: osis-general-bounces at netmesh.org [mailto:osis-general-bounces at netmesh.org
>> ] On Behalf Of Bajaj, Siddharth
>>
>> Sent: Thursday, November 01, 2007 4:03 PM
>> To:Mike Jones; david at sixapart.com; Johnny Bufu; osis-general at netmesh.org
>> Subject: Re: [osis-general] OSIS PAPE call results
>> Hi Mike and others,
>> There was some confusion over the timing of the call. Mary and I
>> called in at noon. I think part of the reason was that because we
>> have deferred daylight savings by a week this year, not all
>> systems have been updated. My treo showed the meeting to be at
>> noon. And when you sent out the other email, I had unfortunately
>> stepped out and was away from my email. So apologies.
>> Thanks for sending out the minutes of the call. Can you also send
>> out the list of participants to today's call.
>> Please see inline for more specific comments -
>> Today we held the call discussing OSIS feedback on the PAPE spec.
>> Topics covered and recommendations made on the call were:
>> - Authorization decisions should be made solely by the relying
>> party. The identity provider should accurately report the status
>> of all policies requested by the relying party that the
>> authentication complies with and may also choose to report the
>> status of any policies that apply that were not explicitly
>> requested. The policies are not mutually exclusive and no
>> relationship between the different policies should be implied. A
>> clarification to this effect should be added to the draft.
>> [Siddharth] agreed. As long as the spec removes all ambiguities in
>> the policies - e.g. multi-factor, and physical multi-factor.
>> - There was a request for a definition of Active Authentication as
>> used in the auth_time element description. Intuitively, this
>> involves at least having the user being at the machine as a
>> participant in the authentication interaction in some manner. We
>> agreed that we should look for an existing definition of active
>> authentication that appears to apply.
>> - The table in Appendix A.1.1 of http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-02.html
>> needs to be updated to be consistent with the definition in
>> Section 4. Specifically:
>> PIN and soft OTP token should not be marked as phishing-
>> resistant.
>> PIN and hard OTP token should not be marked as phishing-
>> resistant.
>> Information Cards should be added and listed as
>> phishing-resistant.
>> Active password managers that only release the password
>> to the correct site should be listed as phishing-resistant.
>> [Siddharth] This is actually an area where we had the different
>> opinions on the mailing list. Per Kim's email we would like to see
>> the group take a realistic approach of treating security more as a
>> continuum . We should also discuss scenarios where the OP is using
>> phishing resistant server authentication technologies such as EV
>> SSL certificates as well. On a related note, I saw a blog post
>> about CardSpace not requiring SSL in the future. We should discuss
>> how that would affect the security properties as well. Again - the
>> root cause of the differing opinions is that the policy is very
>> subjective and its going to be very hard for us to nail down what
>> it exactly signifies.
>> - If relying parties and OPs want to communicate actual
>> authentication methods used, that should happen via a different
>> spec than PAPE. Then the market can decide whether to use PAPE,
>> this spec, both, or neither. (However some in the group have both
>> privacy concerns about this and concerns about enabling attackers
>> by giving them additional information to use in their attacks.)
>> [Siddharth] That's good feedback. However if I'm not releasing any
>> PII, I don't see why this could be a privacy issue. And of course
>> its well understood in the security space that 'security by
>> obscurity' doesn't work. . It could certainly be valuable to some
>> RPs this information about authentication credential itself, while
>> other RPs could care less. I think we should explore what is the
>> best way for the OP to optionally convey this information. One
>> thought is that we can include an extension point in the PAPE spec.
>> Finally, while we failed to discuss this on the call, I also
>> believe that:
>> PIN and digital certificate via HTTPS is phishable if
>> the same certificate value is released to every site.
>> PIN and digital certificate via HTTPS is not phishable
>> if a different certificate value is released to every site.
>> and that the table should be updated accordingly in this case as
>> well. Someone who's an expert in this method should pipe in and
>> provide guidance.
>> [Siddharth] Certificate is public information. The client/browser
>> signs a challenge using the private key which is never released to
>> the server. The challenge is negotiated as part of the SSL
>> handshake so that it cannot be replayed by another (rogue) site.
>> You could have session hijacking type attacks, but these are
>> typically a result of poor SSL implementations, not the protocol or
>> the method.
>> Siddharth
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20071107/a6b4f8ba/attachment-0002.htm>
More information about the specs
mailing list