[specs-pape] Release candidate 3

Tue Sep 30 16:37:02 PDT 2008

I remember it being AOL making the argument last year that the OP  
might report back to the RP lower than what happened but equal to what  
they requested.  George Fletcher might remember the exact argument  
(assuming I'm not making this all up.)

--David

On Sep 28, 2008, at 10:28 PM, Mike Jones wrote:

> I agree with you about this, Ben.  Do other agree as well?
>
>                                -- Mike
>
> -----Original Message-----
> From: specs-pape-bounces at openid.net [mailto:specs-pape-bounces at openid.net 
> ] On Behalf Of Ben Laurie
> Sent: Sunday, September 28, 2008 10:22 PM
> To: Mike Jones
> Cc: specs-pape at openid.net
> Subject: Re: [specs-pape] Release candidate 3
>
> On Sun, Sep 28, 2008 at 9:30 AM, Mike Jones <Michael.Jones at microsoft.com 
> > wrote:
>> Thanks Ben.  I'll try to think through a way to tighten this up in  
>> the next
>> couple of days.  John will be here in England with me so maybe we  
>> can put
>> our heads together on it.  Suggestions on specific wording are  
>> welcome from
>> anyone in the working group too.
>>
>>
>>
>> Ben, you wrote:
>>
>> On that note, I think the security considerations are just plain
>> wrong: the IdP should use the strongest method available always - the
>> RP should just ignore that it was stronger than asked for if that  
>> is a
>> problem for the RP.
>>
>> That wasn't my interpretation of what the security considerations  
>> section
>> was saying.  It doesn't say that the IdP shouldn't USE the  
>> strongest method
>> available.  It suggests that sometimes it could choose to REPORT  
>> only the
>> strength of authentication requested, rather than reporting the full
>> strength used if they differ.   But I agree that the analogy then  
>> about not
>> logging in as root all the time is misleading.  I'll think about  
>> how to
>> clarify that aspect as well.
>
> I still think the onus is on the RP to not upgrade if it doesn't want
> to. I would be happier if the security considerations were done that
> way - it seems wrong for the OP to not tell the truth about what
> happened.
>
>>
>>
>>
>>                                                                 
>> Thanks,
>>
>>                                                                --  
>> Mike
>>
>>
>>
>> From: John Bradley [mailto:john.bradley at wingaa.com]
>> Sent: Saturday, September 27, 2008 8:54 PM
>> To: Ben Laurie
>> Cc: Mike Jones; specs-pape at openid.net
>> Subject: Re: [specs-pape] Release candidate 3
>>
>>
>>
>> Ben,o
>>
>>
>>
>> You have a good point on the phishing resistance question.
>>
>>
>>
>> Nat and I were discussing that issue last week.
>>
>>
>>
>> It is unclear that phishing resistance on the current login is of  
>> any value.
>>  As you correctly point out if the OP uses passwords where they  
>> some times
>> are taken in a phishing resistant way and sometimes not they should  
>> always
>> be considered non-phishing resistant.
>>
>>
>>
>> I think Nat and I could go along with some wording to that effect.
>>
>>
>>
>> As it is now the authentication methods are just that and need to
>> be interpreted correctly for each OP.
>>
>>
>>
>> However consider the case of a OP like Verisign or Linksafe that  
>> allows
>> passwords (not phishing resistant) and m-card (phishing resistant
>> authentication)
>>
>>
>>
>> In principle you could signal Verisign to only let someone use the  
>> m-card
>> for the particular login.
>>
>>
>>
>> On the face of it you cant phish the m-card.  However a malicious RP
>> could Phish the password and then log in and issue a  new m-card to  
>> itself.,
>> and qualify for a phishing resistant login.
>>
>>
>>
>> Vidoop would argue that there login is always phishing resistant.   
>> Though
>> they may be vulnerable to password reset interception.
>>
>>
>>
>> The weakest link in most OPs is email password resets that can gain  
>> an
>> attacker access to the users openID account.
>>
>>
>>
>> In principle the holistic security level can also be asserted via  
>> the NIST
>> level.
>>
>>
>>
>> I don't think much of this is going to be useful without
>> some relationship between the OP and RP.
>>
>>
>>
>> Unless it is the Yahoo use case of NIST level 0 that works well.
>>
>>
>>
>> Regards
>>
>> =jbradley
>>
>>
>>
>> On 27-Sep-08, at 6:50 PM, Ben Laurie wrote:
>>
>> On Fri, Sep 26, 2008 at 12:24 AM, Mike Jones
>> <Michael.Jones at microsoft.com> wrote:
>>
>> The attached draft is the 23-Sep-08 draft plus the changes  
>> requested by
>>
>> Yahoo and an correction to a name suggested by Johnny, plus a manual
>>
>> consistency pass to ensure that the Word and generated HTML  
>> versions contain
>>
>> exactly the same content.
>>
>>
>>
>>
>>
>>
>>
>> I also managed to successfully check the .xml version of this draft  
>> into the
>>
>> OpenID SubVersion tree.  Once I can log into the openid.net wiki  
>> again (a
>>
>> different problem I'll work on tomorrow) I'll also post the HTML  
>> version as
>>
>> http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-03.html
>>
>> so others can easily view it.
>>
>> OK, I'm late to the party, but...
>>
>> It seems to me there's a problem with phishing-resistant auth,
>> particular when the rather weak security considerations section is
>> taken into account. As an RP I want to know that the user is using
>> auth that can't be phished ever, not that the auth mode used on this
>> particular occasion was phishing resistant. As written, the doc does
>> not stipulate that when the RP requests phishing resistance, the user
>> is required to use credentials that could not have been discovered by
>> an attacker that did not ask for phishing resistance. This is
>> exacerbated by the security considerations, which actively encourage
>> the IdP to use the weakest auth method it can.
>>
>> On that note, I think the security considerations are just plain
>> wrong: the IdP should use the strongest method available always - the
>> RP should just ignore that it was stronger than asked for if that  
>> is a
>> problem for the RP.
>>
>>
>>
>>
>>
>>
>>
>>
>>                                                                
>> Thanks all!
>>
>>
>>
>>                                                               -- Mike
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>>
>> specs-pape mailing list
>>
>> specs-pape at openid.net
>>
>> http://openid.net/mailman/listinfo/specs-pape
>>
>>
>>
>>
>>
>> _______________________________________________
>> specs-pape mailing list
>> specs-pape at openid.net
>> http://openid.net/mailman/listinfo/specs-pape
>>
>>
> _______________________________________________
> specs-pape mailing list
> specs-pape at openid.net
> http://openid.net/mailman/listinfo/specs-pape
>
> _______________________________________________
> specs-pape mailing list
> specs-pape at openid.net
> http://openid.net/mailman/listinfo/specs-pape