Subject: RE: [Ietf-http-auth] Re: [dix] BOF plans
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Sam Hartman" <[email-masked]>, "Digital Identity Exchange" <[email-masked]>
Cc: [email-masked]
Date: Thu, 29 Jun 2006 06:54:08 -0700
List-Id: ietf-http-auth.osafoundation.org

> [mailto:[email-masked]] On Behalf 

> I agree that it is important and achievable to share 
> authentication against all of these protocols.
> 
> My proposal definitely works that wy.  There are things you 
> need to do in the binding to http--and one of those is state 
> management.  However it is quite clear that anything that 
> will work with http negotiate authentication also works with 
> xmpp, smtp, ldap, imap, and friends.
> 
> In the specific case of Kerberos, we have a lot of running code.

Cookies should have been Kerberos tokens from the start. 

Whatever scheme we come up with is going to have two distinct phases.

1) In the authentication phase the user will on success receive some form of ticket.

2) In the ticket phase the ticket will be presented for multiple transactions until it expires.

We have to have a balance here between simplicity and generality. We do need to support multiple application protocols. We do not need to support multiple authentication protocols for the same authentication mechanism.

We must not redo ISAKMP.

From: Sam Hartman <[email-masked]>
To: Digital Identity Exchange <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: [dix] BOF plans
Date: Thu, 29 Jun 2006 08:54:21 -0400
Cc: [email-masked]

>>>>> "Eliot" = Eliot Lear <[email-masked]> writes:

    Eliot> Hi,
    >> I doubt it will be possible to use exactly the same methods for HTTP,
    >> XMPP, SMTP and IMAP.  The latter three (XMPP, SMTP and IMAP) are
    >> session based, and might require authentication/authorization only
    >> once during a session.   HTTP is stateless (at least in general), so
    >> some thought needs to be given to extending the auth across multiple
    >> requests.
    Eliot> While I agree there may be some differences between application
    Eliot> protocols, it is the primary authentication method that must be shared. 
    Eliot> Consider the case where some sort of authentication subsystem sits
    Eliot> outside each application.  So long as the API for that can be shared,
    Eliot> we're probably good.  If HTTP requires a method to retain state across
    Eliot> connections that is HTTP's business.  I would not link the two together.

I agree that it is important and achievable to share authentication
against all of these protocols.

My proposal definitely works that wy.  There are things you need to do
in the binding to http--and one of those is state management.  However
it is quite clear that anything that will work with http negotiate
authentication also works with xmpp, smtp, ldap, imap, and friends.

In the specific case of Kerberos, we have a lot of running code.

From: Dick Hardt <[email-masked]>
Date: Wed, 28 Jun 2006 23:00:30 -0700
To: IETF HTTP Auth <[email-masked]>, Digital Identity Exchange <[email-masked]>
Subject: [Ietf-http-auth] Google Account Authorization - slightly off topic

Google rolled out some some APIs[1] to make it easier for rich clients 
[2] and websites[3] to act on behalf of a Google user. Of course this  
deepens the identity silo that is building at Google. [3] looks like  
some concepts that ekr has been talking about.

Ben: hate to put you on the spot, but is Google looking to  
participate in WAE?

[1] http://code.google.com/apis/accounts/Authentication.html
[2] http://code.google.com/apis/accounts/AuthForInstalledApps.html
[3] http://code.google.com/apis/accounts/AuthForWebApps.html

From: Sam Hartman <[email-masked]>
To: Digital Identity Exchange <[email-masked]>
Date: Wed, 28 Jun 2006 23:48:56 -0400
Cc: [email-masked]
Subject: [Ietf-http-auth] Re: [dix] BOF plans

>>>>> "Pete" = Pete Resnick <[email-masked]> writes:

    Pete> EKR's note seems to have sparked discussions in the right
    Pete> - What problem does this address that isn't addressed by a local
    Pete> "keychain" or information database on the client? (For example,
    Pete> possible answers include: "The problem of not having to change the
    Pete> local user agent" and "The problem of portability".) What's the
    Pete> downside if we don't solve those problems?

First, I think there is IETF work to do even if all we are doing is
working with W3c to recommend best client practices.

However I think that providing portable identities that meet ekr's COC
critera and that do not increase risk of phishing requires IETF work.
I believe that the same mechanisms that give us COC can give us CRC
and HRA.

    Pete> - Does the mechanism use or extend currently deployed web
    Pete> authentication mechanisms (client side and server side)? If not, why
    Pete> not?

My proposal at least does.

    Pete> - Is the client able to decide which identifying information goes to
    Pete> the server?

In my proposal, yes in a limited form.  This can be expanded over
time.  I wanted to bite off a small chunk to start from.  While this
is supported, I hope future work increases the granularity of client
control.

    Pete> - Does the mechanism involve 3rd parties for authentication or
    Pete> identifying info? Does the 3rd party need to be trusted by the relying
    Pete> party?

My mechanism does.  The third party is delegated a portion of a
namespace.  The third party can produce credentials for any identifier
in that namespace.  The third party needs to be trusted as much as the
most trusted identity that the RP currently accepts in its namespace.

    Pete> - Does the mechanism use a format for the information that has widely
    Pete> available implementations?

Yes.

    Pete> - Are you using a mechanism to authenticate the information that has
    Pete> widely available implementations?
I do not understand this question.

From: Sam Hartman <[email-masked]>
To: Digital Identity Exchange <[email-masked]>
Date: Wed, 28 Jun 2006 23:39:55 -0400
Cc: [email-masked]
Subject: [Ietf-http-auth] Re: [dix] Notes on Web authentication enhancements

Hi.

First, I'd like to thank you for this excellent starting point for the
discussion.  I do have a few comments, but this is a great taxonomy.

                             Requirements

  2. Hijack-Resistant Authentication (HRA)
  An authentication system in which credentials which are bound to
  protocol messages in such a way that attacker who observes the
  credentials can't use them to authenticate messages of their
  choice. The rationale for this feature is to make cut-and-paste
  attacks difficult.

I think this description and the subsequent discussion in
transporting/binding credentials has some concepts I'd like to
distinguish muddled together.

Some schemes will provide integrity: a man in the middle can observe
the conversation but cannot modify the content of the request or
response.

Some schemes will provide confidentiality even given the practical
difficulties with server certificate validation.

I argue in section 4.5 and 5 of version 01 of my phishing requirements
draft that providing confidentiality of the resulting page is
important even given these practical server certificate issues.  So,
I'd like to ask you to add that as a potential requirement I might want so I can ask for it.
Also, let's be careful to distinguish  this from HRA.

You don't seem to have a requirement that corresponds to section 4.6
of 01 of my phishing requirements draft.  This was one of the issues
muddled into the confusing mutual authentication section in 00 of my
draft.  I contend that if there are a small number of RPs that by
policy should be allowed to accept a given identity,there is a
security benefit in restricting the identity to only those RPs.  In
particular, if a user successfully authenticates the user knows that
because their identity was successfully accepted, they have
authenticated to one of the valid RPs.  I'd be happy to discuss
specific customer deployments where this will be useful with you
off-list.  I understand based on your review of my 00 draft that you
don't like this requirement.  I still think it reasonable to discuss.

                      TLS Client AUthentication

Your taxonomy assumes that TLS is a valid approach to client
authentication.  As I understand HTTP, that is only true assuming
there are no proxies between the user and the RP.

We could extend HTTP to allow a proxy to assert authentication
information it received via TLS to the next hop.  It might be possible
but would be more challenging to extend HTTP so that a client could
give a proxy credentials to use for TLS client authentication outbound
from that proxy.  I think these issues are important to consider when
comparing how credentials and authentication are transported.
(Personally, I wish we could just ignore the whole issue of proxies.
I don't think that will be acceptable to the market though.)

                 Transporting and Binding Credentials

  An additional issue is hijacking: without cryptographic 
  binding, an attacker who observes a request can make future
  requests in the name of the user via a cut-and-paste attack
  (remember, the token is bearer). If you take the threat of
  this type of attack seriously, you need to run the traffic
  over SSL/TLS. [1] 

  [1] Note that if you're worried about this class of attack, you need
  *every* PDU to be cryptographically bound to the credential with
  all designs. If, for instance, you use cert-based auth but then
  transition to cookies over HTTP for state management, there's a 
  cut-and-paste attack there.

I think the primary paragraph is misleading.  We've started from an
assumption that there are practical problems that prevent server certificates from being validated.  Given this assumption I don't understand how TLS actually gives us protection against the hijacking.

I also think the footnote ignores an important deployment model.  I
 may be concerned about whether I have reached the right RP while not
 concerned about network level hijacking.  So I'm not at all convinced
 that you always need to protect every exchange if you are concerned
 about hijacking in some situations.

Thanks again for your excellent work and for your consideration of my
comments.

--Sam

From: John Merrells <[email-masked]>
Date: Wed, 28 Jun 2006 15:59:38 -0700
To: Digital Identity Exchange <[email-masked]>
Cc: [email-masked]
Subject: [Ietf-http-auth] Re: [dix] BOF plans (Was: Notes on Web authentication enhancements)

On 26-Jun-06, at 10:42 PM, Pete Resnick wrote:

> I expect anyone who wants to propose a problem and/or solution to  
> be able to say how their proposal answers these questions:

I'm willing to answer these questions from the DIX perspective... for  
both the problem as documented in draft-merrells-use-cases-xx and the  
proposed solution in the protocol and assertion drafts.

I'd hope that others attending the BOF with a view to presenting  
their ideas would surface them on this (these) lists, answer these  
questions, and enter into any resulting conversations.

> - What problem does this address that isn't addressed by a local  
> "keychain" or information database on the client? (For example,  
> possible answers include: "The problem of not having to change the  
> local user agent" and "The problem of portability".) What's the  
> downside if we don't solve those problems?

 From the DIX use-cases:

We have as a goal 'ease of adoption'... from this flows a solution  
architecture that mandates no changes to the User Agent, and minimal  
changes to both the Relying Party and to the User's behaviour. All  
complexity is pushed back to onto the Identity Agent, which could be  
an IdP. The downside we believe is lower rates of adoption at a  
slower pace.

Portability is covered by use-cases B12 and B15. Portability is  
important to a large class of users as they have multiple devices for  
accessing internet services.  The downside of not addressing  
portability is that it's a barrier to adoption... if a solution has  
only one thing a potential user doesn't like they won't use it. Joel  
Spolsky makes the point aptly in his book 'Joel on Software' where he  
writes that the killer feature in Excel 4 that tipped the market in  
the favour was the the ability to _write_ lotus 123 files. The last  
objection to adoption has been removed.

DIX use-cases A1 through A14 document scenarios for the acquisition  
and presentation of third-party attested assertions. From this flows  
requirements upon the solution for a protocol between the Identity  
Issuer (the authoritative source) and the Identity Agent. Maybe this  
goes beyond the scope of your question... but it's our opinion that  
that this is a problem and a solution would provide benefits to  
internet users. The downside... a missed opportunity to enable many  
useful services on the internet that exist in the real world today.  
But, this could be layered on top of an existing architecture at a  
later data. This was the approach we took when I published draft- 
merrells-dix-00, but without 'claims' the solution proposal appears  
to not offer enough value to some. By explicitly documenting the  
claims use-cases we aimed to sketch out a roadmap  of functionality  
that could be built upon this digital-identity-exchange architecture.

> - Does the mechanism use or extend currently deployed web  
> authentication mechanisms (client side and server side)? If not,  
> why not?

For User Authentication the DIX drafts explicitly state that it as  
out of scope. It's not a problem that appears in the DIX use-cases.  
The DIX use-cases motivate requirements for moving around the result  
of an authentication event, rather than performing the authentication  
process itself.
However, I'm glad that others are willing to document and address  
that issue though.

For Server Authentication the DIX use-cases don't call that out as an  
issue, but draft-merrells-dix-xx drafts do include some functionality  
for providing the user with some assurance that they are dealing with  
whom they think they are. We allow the request and response messages  
to include references to signed logos.

> - Is the client able to decide which identifying information goes  
> to the server?

By 'client' I take it to mean 'user'. This is a fundamental  
requirement, as document in Kim's laws of identity. It's part of the  
problem and every solution to be adoptable must meet this  
requirement. DIX does.

> - Does the mechanism involve 3rd parties for authentication or  
> identifying info? Does the 3rd party need to be trusted by the  
> relying party?

For authentication - No not really, as the user is self asserting  
that they own an identifier and there's a verification mechanism to  
check that they do. The identifier, a URL, may be hosted, but I don't  
count that as a third party. The user's identity agent may be a  
website, or an enhanced browser, but I don't count that as a third  
party either.

For 'identifying info', which I think means third-party attested  
attribute value assertions, then yes there is a third-party that is  
the authoritative source of that attribute and yes the relying-party  
has to trust that third-party to accept the assertion to be valid.

> - Does the mechanism use a format for the information that has  
> widely available implementations?

'the information' is a bit ambiguous there, as in the question above  
it's 'identifying information', which to me means an 'identifier'. In  
DIX (dmd2) we state the identifier as being a URI and define a  
PersonaURL property that describes how to use a URL as an identifier.

But I think you mean authentication and attribute assertions.

Authentication Assertions in DIX are response messages containing an  
identifier property where the whole message has been signed using a  
'lightweight' signing mechanism (HMAC). In dmd1 the message format  
was name-value pairs, in dmd2 it is a SAML message. The SAML message  
however mostly reuses the syntax of SAML and not much of the  
semantics... work would have to be done there to make the SAML  
message both look and behave as a SAML message in existing SAML  
profiles. Jeff/Scott have kicked out a draft that takes an existing  
SAML profile and extra-profiles it to use a 'lightweight' signing  
mechanism. (I haven't read it - but i think that's the gist of it).

Attribute Assertions in DIX may be self-asserted or third-party- 
asserted. Self-asserted are name-value pairs... where the value is a  
UTF-8 string... to highly portable and you can impose any information  
model you want on that, so long as you can serialize it into a  
string. Third-party assertions are documented in draft-merrells- 
assertion-xx and is a profile of a SAML assertion. Lots of code out  
there to deal with those. But, there are many forms of claim that  
could be used. The problem is moving them about, not creating or  
consuming them..

> - Are you using a mechanism to authenticate the information that  
> has widely available implementations?

See last para... basically SAML assertions for attributes.

> I'll probably have more questions, but these are along these lines  
> of the ones you should be thinking about. Answers to these here on  
> the list will help me formulate agenda items.

I'd encourage you, and everyone, to ask more general questions of the  
problem and solution proposers so that we can all learn as much about  
each other's positions before we meet up in Montreal next month. I  
hope that the BOF will be productive and that we'll leave there  
having identified the problem(s) and with a plan for how we tackle them.

John

Date: Wed, 28 Jun 2006 11:30:20 -0400
From: "Robert Sayre" <[email-masked]>
To: "Eliot Lear" <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: [dix] BOF plans (Was: Notes on Web authentication enhancements)
Cc: [email-masked], [email-masked]

On 6/28/06, Eliot Lear <[email-masked]> wrote:
>
> While I agree there may be some differences between application
> protocols, it is the primary authentication method that must be shared.
> Consider the case where some sort of authentication subsystem sits
> outside each application.

Sam Hartman asked that HMAC Digest[1] define a SASL mechanism for this
reason. I assume the same reasoning applies here [2,3]. Alexey and I
need to rev the draft to account for feedback from Yngve Pettersen,
Joe Orton, and others.

1.) <http://www.ietf.org/internet-drafts/draft-sayre-http-hmac-digest-01.txt>
2.) <http://lists.osafoundation.org/pipermail/ietf-http-auth/2006-March/000185.html>
3.) <http://lists.osafoundation.org/pipermail/ietf-http-auth/2006-March/000186.html>

-- 

Robert Sayre

Date: Wed, 28 Jun 2006 08:59:29 +0200
From: Eliot Lear <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-http-auth] Re: [dix] BOF plans (Was: Notes on Web authentication enhancements)
Cc: [email-masked], [email-masked]

Hi,

> I doubt it will be possible to use exactly the same methods for HTTP,
> XMPP, SMTP and IMAP.  The latter three (XMPP, SMTP and IMAP) are
> session based, and might require authentication/authorization only
> once during a session.   HTTP is stateless (at least in general), so
> some thought needs to be given to extending the auth across multiple
> requests.
While I agree there may be some differences between application
protocols, it is the primary authentication method that must be shared. 
Consider the case where some sort of authentication subsystem sits
outside each application.  So long as the API for that can be shared,
we're probably good.  If HTTP requires a method to retain state across
connections that is HTTP's business.  I would not link the two together.

Eliot

Date: Tue, 27 Jun 2006 15:14:51 -0400
From: [email-masked]
Subject: Re: [Ietf-http-auth] Re: [dix] BOF plans (Was: Notes on Web authentication enhancements)
To: [email-masked], [email-masked]
Cc: [email-masked]

----------MailBlocks_8C86835190CEE8E_1384_4_FWM-R33.sysops.aol.com
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

 I doubt it will be possible to use exactly the same methods for HTTP, XMPP, SMTP and IMAP. The latter three (XMPP, SMTP and IMAP) are session based, and might require authentication/authorization only once during a session. HTTP is stateless (at least in general), so some thought needs to be given to extending the auth across multiple requests.
 
 A method for HTTP will need to consider potential performance issues, replay protection, and possible tie-in with other available session state (such as a TLS channel), among other things. The others can generally get away with a on-time verification step per session.
  
 It may be possible to share portions of the mechanism. In fact, TLS/SSL with client authentication supports all 4 protocols. However it seems to be rejected because of other issues: PKI lifecycles, physical portability of the key, trust management, etc.
 
 Terry Hayes
 AOL LLC
  
 -----Original Message-----
 From: [email-masked]
 To: [email-masked]
 Cc: [email-masked]
 Sent: Tue, 27 Jun 2006 9:57 AM
 Subject: [Ietf-http-auth] Re: [dix] BOF plans (Was: Notes on Web authentication enhancements)
 
  Ben Laurie wrote:
>>
>> - Does the mechanism use or extend currently deployed web
>> authentication mechanisms (client side and server side)? If not, why
>> not?
>
> No - because if you use web authentication, then it will not work for
> protocols that are not HTTP based - XMPP and IMAP are obvious examples
> that spring to mind.

I'm not sure I'd go so far as No, but the mechanism or an analog must be
easily ported to other application protocols such as XMPP, SMTP, or
IMAP.  I would think an existence proof of 2 (one being HTTP; the other
being IMAP)  would be a very useful thing for any WG.

Eliot
_______________________________________________
Ietf-http-auth mailing list
[email-masked]
http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth
   
________________________________________________________________________
Check out AOL.com today. Breaking news, video search, pictures, email and IM. All on demand. Always Free.

----------MailBlocks_8C86835190CEE8E_1384_4_FWM-R33.sysops.aol.com
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<HTML><BODY>
<div>I doubt it will be possible to use exactly the same methods for HTTP, XMPP, SMTP and IMAP.&nbsp; The latter three (XMPP, SMTP and IMAP) are session based, and might require authentication/authorization only once during a session. &nbsp; HTTP is stateless (at least in general), so some thought needs to be given to extending the auth across multiple requests.<br>
<br>
A method for HTTP will need to consider potential performance issues, replay protection, and possible tie-in with other available session state (such as a TLS channel), among other things.&nbsp; The others can generally get away with a on-time verification step per session.<br>
</div>

<div><br>
It may be possible to share portions of the mechanism.&nbsp; In fact, TLS/SSL with client authentication supports all 4 protocols.&nbsp; However it seems to be rejected because of other issues: PKI lifecycles, physical portability of the key, trust management, etc.<br>
<br>
Terry Hayes<br>
AOL LLC<br>
</div>
&nbsp;<br>
-----Original Message-----<br>
From: [email-masked]<br>
To: [email-masked]<br>
Cc: [email-masked]<br>
Sent: Tue, 27 Jun 2006 9:57 AM<br>
Subject: [Ietf-http-auth] Re: [dix] BOF plans (Was: Notes on Web authentication enhancements)<br>
<br>

<div id="AOLMsgPart_0_7641fa3e-8d15-48a1-bbd2-71f52d27ec7d" class="AOLPlainTextBody">

<pre><tt>Ben Laurie wrote:
&gt;&gt;
&gt;&gt; - Does the mechanism use or extend currently deployed web
&gt;&gt; authentication mechanisms (client side and server side)? If not, why
&gt;&gt; not?
&gt;
&gt; No - because if you use web authentication, then it will not work for
&gt; protocols that are not HTTP based - XMPP and IMAP are obvious examples
&gt; that spring to mind.

I'm not sure I'd go so far as No, but the mechanism or an analog must be
easily ported to other application protocols such as XMPP, SMTP, or
IMAP.  I would think an existence proof of 2 (one being HTTP; the other
being IMAP)  would be a very useful thing for any WG.

Eliot
_______________________________________________
Ietf-http-auth mailing list
<a href="mailto:Ietf-http-auth%40osafoundation.org">[email-masked]</a>
<a href="http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth" target="_blank">http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth</a>
</tt></pre>
</div>
 <!-- end of AOLMsgPart_0_7641fa3e-8d15-48a1-bbd2-71f52d27ec7d -->

<div class="AOLPromoFooter">
<hr style="margin-top:10px;" />
<a href="http://pr.atwola.com/promoclk/1615326657x4311227241x4298082137/aol?redir=http%3A%2F%2Fwww%2Eaol%2Ecom" target="_blank"><b>Check out AOL.com today</b></a>. Breaking news, video search, pictures, email and IM. All on demand. Always Free.<br />
</div>

</BODY></HTML>

----------MailBlocks_8C86835190CEE8E_1384_4_FWM-R33.sysops.aol.com--

To: Eliot Lear <[email-masked]>
Subject: Re: [dix] Re: [Ietf-http-auth] Notes on Web authentication enhancements
From: Eric Rescorla <[email-masked]>
Date: Tue, 27 Jun 2006 09:59:56 -0700
Cc: Digital Identity Exchange <[email-masked]>, [email-masked]
Reply-To: EKR <[email-masked]>

Eliot Lear <[email-masked]> writes:
> In order for this replay to be effective the attacker would have had to
> compromised the privacy of the exchange or one end of the
> communication.

Yeah, like if it weren't done over TLS.

> A cookie approach is reasonable where this risk is
> reasonable, and can be further mitigated through brief durations or one
> time use depending on need.  Do we need more?

Well, I think the question is whether such settings are the only
ones we're interested in.

-Ekr

Date: Tue, 27 Jun 2006 18:57:43 +0200
From: Eliot Lear <[email-masked]>
To: Digital Identity Exchange <[email-masked]>
Cc: [email-masked]
Subject: [Ietf-http-auth] Re: [dix] BOF plans (Was: Notes on Web authentication enhancements)

Ben Laurie wrote:
>>
>> - Does the mechanism use or extend currently deployed web
>> authentication mechanisms (client side and server side)? If not, why
>> not?
>
> No - because if you use web authentication, then it will not work for
> protocols that are not HTTP based - XMPP and IMAP are obvious examples
> that spring to mind.

I'm not sure I'd go so far as No, but the mechanism or an analog must be
easily ported to other application protocols such as XMPP, SMTP, or
IMAP.  I would think an existence proof of 2 (one being HTTP; the other
being IMAP)  would be a very useful thing for any WG.

Eliot

Date: Tue, 27 Jun 2006 18:55:17 +0200
From: Eliot Lear <[email-masked]>
To: EKR <[email-masked]>, Digital Identity Exchange <[email-masked]>
Subject: Re: [dix] Re: [Ietf-http-auth] Notes on Web authentication enhancements
Cc: [email-masked]

Eric,
> So, let's take the diagram from my recent mail message:
>
>
> User                      RP                       IdP
> ----                      --                       ---
> Sell me beer ->                                         
>           <- Prove you're 21
>
> IdP, help me!                                   ->
>           <---------- Auth exchange ------------->
>                                          <- Credential
>
> Credential ->              
>                        <- OK
>
>
> The IdP gives the User some credential that he gives the
> RP. That's fine for the first request, but what happens when
> the user wants to make a second request? You clearly don't
> want to go back to the IdP every time. The classic solution
> is for the server to give you some cookie: those cookies
> can obviously be cut-and-pasted from one message to another.
> Even if you make them single-time (evolve them every time)
> there's a window between the cookie delivery (in the HTTP
> response) and the next HTTP request.
>
> Another option is to bypass the cookie thing and just make
> the Credential reusable, but this has the same problem...
>
>   
In order for this replay to be effective the attacker would have had to
compromised the privacy of the exchange or one end of the
communication.  A cookie approach is reasonable where this risk is
reasonable, and can be further mitigated through brief durations or one
time use depending on need.  Do we need more?

Eliot

Date: Tue, 27 Jun 2006 17:23:40 +0100
From: "Stephan Fowler" <[email-masked]>
Sender: [email-masked]
To: "Robert Sayre" <[email-masked]>
Subject: Re: [Ietf-http-auth] Notes on Web authentication enhancements
Cc: [email-masked], [email-masked]

On 6/27/06, Robert Sayre <[email-masked]> wrote:
> On 6/26/06, Stephan Fowler <[email-masked]> wrote:
> >
> > Notwithstanding Phil's point about protocol issues being out of scope,
> > which is likely correct, I'll nevertheless mention a recent
> > authentication protocol called HTTPsec:
> > http://httpsec.org/protocol/1.0/
>
> Interesting. But, I have a question. How does the client know to send
> the Authorization: initialization header in the first request?

Consider:

(1) Reactive authentication: the server responds to a unauthenticated
request with a "WWW-Authenticate: httpsec/1.0 challenge" header (kinda
à la Digest auth), invoking the client to retry with an initialization
header.

(2) Active authentication of server: Client sends the initialization
because it has the policy of doing so for specific sites, and has
prior notions of the public-keys that those sites must authenticate
against. Imagine bookmarks that associate URLs with server public
keys. On selection of such a bookmark, client would send an
initialization bearing a "responder-auth" directive.

(3) Active client authentication: Suppose bookmarks associate URLs
with a *client* private key. On selection of such a bookmark, the
client would sends an initialization bearing a "requester" directive
containing a reference to its public key.

Note that 1 is normative, whereas 2 and 3 are use-cases applicable
when "client" means a browser (I say that because we initially
developed this for server-to-server interactions, e.g. ReST, web
services etc, which represent another set of use-cases). The bookmark
thing is something we are experimenting with at the moment.

Stephan

Date: Tue, 27 Jun 2006 11:04:29 -0400
From: "Robert Sayre" <[email-masked]>
To: "Stephan Fowler" <[email-masked]>
Subject: Re: [Ietf-http-auth] Notes on Web authentication enhancements
Cc: [email-masked], [email-masked]

On 6/26/06, Stephan Fowler <[email-masked]> wrote:
>
> Notwithstanding Phil's point about protocol issues being out of scope,
> which is likely correct, I'll nevertheless mention a recent
> authentication protocol called HTTPsec:
> http://httpsec.org/protocol/1.0/

Interesting. But, I have a question. How does the client know to send
the Authorization: initialization header in the first request?

http://httpsec.org/protocol/1.0/#Examples

-- 

Robert Sayre

Date: Tue, 27 Jun 2006 09:01:42 +0100
From: Joe Orton <[email-masked]>
To: Eric Rescorla <[email-masked]>
Subject: Re: [Ietf-http-auth] Notes on Web authentication enhancements
Mail-Followup-To: Eric Rescorla <[email-masked]>, Mark Nottingham <[email-masked]>, [email-masked], [email-masked]
Cc: [email-masked], [email-masked]

On Mon, Jun 26, 2006 at 12:00:52PM -0700, Eric Rescorla wrote:
> Mark Nottingham <[email-masked]> writes:
> 
> > On 2006/06/23, at 3:29 PM, Eric Rescorla wrote:
> >> Part of the problem is that the user and the software have
> >> a different view of the RP's identity. The software knows that
> >> C1tibank and Citibank are different, but the user does not.
> >
> > Fair enough.
> >
> > Would it be correct to say that HTTP Digest Auth has this property
> > alreadly (because A2 includes the digest-uri-value)? There are other
> > attacks that can be made against Digest, of course (e.g., dictionary
> > against weak passwords), but it's interesting to think of it as
> > having anti-phishing properties.
> 
> I'm not 100% sure. IIRC, the digest-uri-value is only the
> path portion, i.e., 
> 
>      /example/example.html

digest-uri-value just matches the Request-URI, so it depends on whether 
the client is using a proxy or not - HTTP/1.1 clients will typically use 
an absoluteURI in the Request-URI iff configured to use a proxy (and not 
tunnelling using CONNECT); otherwise they use the abs_path.

joe

From: Dick Hardt <[email-masked]>
Subject: Re: [Ietf-http-auth] Notes on Web authentication enhancements
Date: Mon, 26 Jun 2006 15:00:08 -0700
To: EKR <[email-masked]>
Cc: [email-masked], [email-masked]

On 26-Jun-06, at 12:20 PM, Eric Rescorla wrote:

> Dick Hardt <[email-masked]> writes:
>
>> On 23-Jun-06, at 9:17 PM, Eric Rescorla wrote:
>>>>
>>>> In DIX, the RP includes a nonce in the request, which must then  
>>>> also
>>>> be in the nonce which would prevent replay attacks assuming the  
>>>> RP is
>>>> managing nonce state would it not?
>>>
>>> Only if each authentication token is only single-use. Otherwise,
>>> an attacker can replay it during the validity period. Even then,
>>> cut-and-paste attacks are still possible if you block the
>>> initial request.
>>
>> My understanding of the definition of a nonce is that it is single- 
>> use.
>> Would you humour me with an explanation of a cut-and-paste attack per
>> above?
>
> So, let's take the diagram from my recent mail message:
>
>
> User                      RP                       IdP
> ----                      --                       ---
> Sell me beer ->
>           <- Prove you're 21
>
> IdP, help me!                                   ->
>           <---------- Auth exchange ------------->
>                                          <- Credential
>
> Credential ->
>                        <- OK
>
>
> The IdP gives the User some credential that he gives the
> RP. That's fine for the first request, but what happens when
> the user wants to make a second request? You clearly don't
> want to go back to the IdP every time. The classic solution
> is for the server to give you some cookie: those cookies
> can obviously be cut-and-pasted from one message to another.
> Even if you make them single-time (evolve them every time)
> there's a window between the cookie delivery (in the HTTP
> response) and the next HTTP request.
>
> Another option is to bypass the cookie thing and just make
> the Credential reusable, but this has the same problem...

Thanks Eric. Very useful to understand.
This seems to be a more general issue of securely managing state over  
HTTP would it not?

-- Dick

Content-class: urn:content-classes:message
Subject: RE: [Ietf-http-auth] Notes on Web authentication enhancements
Date: Mon, 26 Jun 2006 14:02:58 -0700
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Mark Nottingham" <[email-masked]>, "EKR" <[email-masked]>
Cc: [email-masked], [email-masked]

I have not read any of the patents on this for reasons that will be familiar.

If I was going to revisit Digest I would at the very least include an ephemeral D-H key into the mix so that the digest value was at a minimum secure against a brute force attack by a man in the middle.

Has every avenue to that end been encumbered?

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> Of Mark Nottingham
> Sent: Monday, June 26, 2006 3:58 PM
> To: EKR
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Ietf-http-auth] Notes on Web authentication enhancements
> 
> You're right (unless I missed something else);
> 
> [2617]
> >        digest-uri       = "uri" "=" digest-uri-value
> >        digest-uri-value = request-uri   ; As specified by HTTP/1.1
> 
> [2616]
> > Request-URI    = "*" | absoluteURI | abs_path | authority
>                                        ^^^^^^^^ A pity.
> 						
> 
> On 2006/06/26, at 12:00 PM, Eric Rescorla wrote:
> 
> > Mark Nottingham <[email-masked]> writes:
> >
> >> On 2006/06/23, at 3:29 PM, Eric Rescorla wrote:
> >>> Part of the problem is that the user and the software have a 
> >>> different view of the RP's identity. The software knows that 
> >>> C1tibank and Citibank are different, but the user does not.
> >>
> >> Fair enough.
> >>
> >> Would it be correct to say that HTTP Digest Auth has this property 
> >> alreadly (because A2 includes the digest-uri-value)? There 
> are other 
> >> attacks that can be made against Digest, of course (e.g., 
> dictionary 
> >> against weak passwords), but it's interesting to think of it as 
> >> having anti-phishing properties.
> >
> > I'm not 100% sure. IIRC, the digest-uri-value is only the path 
> > portion, i.e.,
> >
> >      /example/example.html
> >
> > rather than
> >
> >      http://www.example.com/example/example.html
> >
> > But I could totally be wrong on this.
> >
> >
> > -Ekr
> >
> >
> 
> --
> Mark Nottingham
> [email-masked]
> 
> 
> 
> _______________________________________________
> Ietf-http-auth mailing list
> [email-masked]
> http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth
> 
> 

From: Mark Nottingham <[email-masked]>
Subject: Re: [Ietf-http-auth] Notes on Web authentication enhancements
Date: Mon, 26 Jun 2006 12:57:49 -0700
To: EKR <[email-masked]>
Cc: [email-masked], [email-masked]

You're right (unless I missed something else);

[2617]
>        digest-uri       = "uri" "=" digest-uri-value
>        digest-uri-value = request-uri   ; As specified by HTTP/1.1

[2616]
> Request-URI    = "*" | absoluteURI | abs_path | authority
                                       ^^^^^^^^
A pity.

On 2006/06/26, at 12:00 PM, Eric Rescorla wrote:

> Mark Nottingham <[email-masked]> writes:
>
>> On 2006/06/23, at 3:29 PM, Eric Rescorla wrote:
>>> Part of the problem is that the user and the software have
>>> a different view of the RP's identity. The software knows that
>>> C1tibank and Citibank are different, but the user does not.
>>
>> Fair enough.
>>
>> Would it be correct to say that HTTP Digest Auth has this property
>> alreadly (because A2 includes the digest-uri-value)? There are other
>> attacks that can be made against Digest, of course (e.g., dictionary
>> against weak passwords), but it's interesting to think of it as
>> having anti-phishing properties.
>
> I'm not 100% sure. IIRC, the digest-uri-value is only the
> path portion, i.e.,
>
>      /example/example.html
>
> rather than
>
>      http://www.example.com/example/example.html
>
> But I could totally be wrong on this.
>
>
> -Ekr
>
>

--
Mark Nottingham
[email-masked]

To: Dick Hardt <[email-masked]>
Subject: Re: [Ietf-http-auth] Notes on Web authentication enhancements
From: Eric Rescorla <[email-masked]>
Date: Mon, 26 Jun 2006 12:20:25 -0700
Cc: [email-masked], [email-masked]
Reply-To: EKR <[email-masked]>

Dick Hardt <[email-masked]> writes:

> On 23-Jun-06, at 9:17 PM, Eric Rescorla wrote:
>>>
>>> In DIX, the RP includes a nonce in the request, which must then also
>>> be in the nonce which would prevent replay attacks assuming the RP is
>>> managing nonce state would it not?
>>
>> Only if each authentication token is only single-use. Otherwise,
>> an attacker can replay it during the validity period. Even then,
>> cut-and-paste attacks are still possible if you block the
>> initial request.
>
> My understanding of the definition of a nonce is that it is single-use.
> Would you humour me with an explanation of a cut-and-paste attack per
> above?

So, let's take the diagram from my recent mail message:

User                      RP                       IdP
----                      --                       ---
Sell me beer ->                                         
          <- Prove you're 21

IdP, help me!                                   ->
          <---------- Auth exchange ------------->
                                         <- Credential

Credential ->              
                       <- OK

The IdP gives the User some credential that he gives the
RP. That's fine for the first request, but what happens when
the user wants to make a second request? You clearly don't
want to go back to the IdP every time. The classic solution
is for the server to give you some cookie: those cookies
can obviously be cut-and-pasted from one message to another.
Even if you make them single-time (evolve them every time)
there's a window between the cookie delivery (in the HTTP
response) and the next HTTP request.

Another option is to bypass the cookie thing and just make
the Credential reusable, but this has the same problem...

-Ekr

To: Mark Nottingham <[email-masked]>
Subject: Re: [Ietf-http-auth] Notes on Web authentication enhancements
From: Eric Rescorla <[email-masked]>
Date: Mon, 26 Jun 2006 12:00:52 -0700
Cc: [email-masked], [email-masked]
Reply-To: EKR <[email-masked]>

Mark Nottingham <[email-masked]> writes:

> On 2006/06/23, at 3:29 PM, Eric Rescorla wrote:
>> Part of the problem is that the user and the software have
>> a different view of the RP's identity. The software knows that
>> C1tibank and Citibank are different, but the user does not.
>
> Fair enough.
>
> Would it be correct to say that HTTP Digest Auth has this property
> alreadly (because A2 includes the digest-uri-value)? There are other
> attacks that can be made against Digest, of course (e.g., dictionary
> against weak passwords), but it's interesting to think of it as
> having anti-phishing properties.

I'm not 100% sure. IIRC, the digest-uri-value is only the
path portion, i.e., 

     /example/example.html

rather than

     http://www.example.com/example/example.html

But I could totally be wrong on this.

-Ekr

From: Mark Nottingham <[email-masked]>
Subject: Re: [Ietf-http-auth] Notes on Web authentication enhancements
Date: Mon, 26 Jun 2006 11:54:43 -0700
To: EKR <[email-masked]>
Cc: [email-masked], [email-masked]

On 2006/06/23, at 3:29 PM, Eric Rescorla wrote:
>>> 1. Capture-Resistant Credentials (CRC)
>>> Credentials which are designed so that if you authenticate
>>> to relying party (RP) X, X cannot use them to impersonate you to  
>>> RP Y
>>> (even if your intention was to go to Y). Phishing is based
>>> on the fact that passwords do not have this property.
>>> The rationale for this feature is to make phishing-type
>>> attacks difficult.
>>
>> This is a bit confusing; to me (disclaimer -- I'm just a layman, not
>> a security expert), phishing is based on confusing the user about the
>> RP's identity, not reusing credentials from RP X with RP Y. Of
>> course, if you enable Common User Credentials, phishing will be
>> possible in this manner.
>
> I see what you mean here, but let me try to explain what I'm
> talking about and see if you still disagree with my taxonomy.
> In a classic phishing attack, the attacker convinces you
> to authenticate to them under the impression (in between
> your ears) that you're authenticating to someone else. For
> concreteness, say that the Phishing site is spoofing Citibank
> and the Phishing site has domain name C1tibank.
>
> The reason this works is that the authentication token that
> your software sends to C1tibank (your password) is the same
> as the token it sends to Citibank. In systems where these
> are separated (e.g., Boneh's PwdHash) then phishing attacks
> don't work. You can capture an authentication token but
> you can't re-use it to impersonate the user to the real RP.
>
> Part of the problem is that the user and the software have
> a different view of the RP's identity. The software knows that
> C1tibank and Citibank are different, but the user does not.

Fair enough.

Would it be correct to say that HTTP Digest Auth has this property  
alreadly (because A2 includes the digest-uri-value)? There are other  
attacks that can be made against Digest, of course (e.g., dictionary  
against weak passwords), but it's interesting to think of it as  
having anti-phishing properties.

>> With that in mind, I wonder if this is much different from...
>>
>>> 2. Hijack-Resistant Authentication (HRA)
>>> An authentication system in which credentials which are bound to
>>> protocol messages in such a way that attacker who observes the
>>> credentials can't use them to authenticate messages of their
>>> choice. The rationale for this feature is to make cut-and-paste
>>> attacks difficult.
>
> To take a concrete example here, PwdHash is susceptible to
> hijacking attacks (do ordinary connection hijacking) if SSL/TLS
> is not used but is not susceptible to straight phishing attacks.
> So, I don't think these are different.

Did you mean you *do*?

>>> 11. Private Authentication (PA)
>>> Some third-party authentication systems require an interaction
>>> with the 3rd party for each authentication. In some such systems,
>>> the 3rd party knows the relying party for each authentication
>>> and the claims which were asserted. PA means that the 3rd party
>>> does not get that information. The rationale for this feature
>>> is to protect the user's privacy from the 3rd party.
>>
>> I *think* this is saying that there's a requirement to separate the
>> identity from authentication, so that a 3rd party site doesn't learn
>> any details about the user at all (e.g., userid, password, name, e-
>> mail, etc.), but only is given the ability to act on their behalf in
>> certain cases.
>>
>> Do I have that right, or is this something else?
>
> That's not what I had in mind, though it's another interesting
> property.

See also: http://www.w3.org/2005/Security/usability-ws/papers/32-dean- 
auth-for-web-services/

> What I meant was that the 3rd party doesn't find out
> what sites you're visiting and what credentials you proved
> to them; that way if Yahoo is my identity provider they
> don't find out what kind of porn sites I visit.

Ah, so it goes both ways...

Thanks,

--
Mark Nottingham
[email-masked]

Date: Mon, 26 Jun 2006 16:59:11 +0100
From: "Stephan Fowler" <[email-masked]>
Sender: [email-masked]
To: [email-masked], [email-masked]
Subject: Re: [Ietf-http-auth] Notes on Web authentication enhancements

> BARE CRYPTOGRAPHIC IDENTIFIER
> After username/password, probably the most familiar sort of
> remote identifier is a bare public key. The way this is
> used is familiar from SSH: the user generates a public key
> and provides the key (or fingerprint) to the relying party
> (or parties). He can then sign with the private key to
> prove possession.
> ...
>
> CRYPTOGRAPHIC BINDING INSIDE HTTP
> If you're using public key for authentication, the natural approach is
> to simply have the credentials bound directly to the HTTP PDUs they
> vouch for. So, the PDU would contain a signature line that covered the
> request itself. This is what, for example, S-HTTP does.

Notwithstanding Phil's point about protocol issues being out of scope,
which is likely correct, I'll nevertheless mention a recent
authentication protocol called HTTPsec:
http://httpsec.org/protocol/1.0/
This provides unilateral or mutual authentication using RSA public
keys, or symmetric keys if pre-shared, applicable to arbitrary
messages. It's somewhat "lighter" than S-HTTP; the latter encapsulates
the entire message, whereas HTTPsec adds a single header containing  a
MAC, amongst other directives. Obviously, it requires extra code at
client- and server-side.

Stephan Fowler

From: Dick Hardt <[email-masked]>
Subject: Re: [dix] Re: [Ietf-http-auth] Notes on Web authentication enhancements
Date: Sat, 24 Jun 2006 09:27:52 -0700
To: Digital Identity Exchange <[email-masked]>
Cc: [email-masked]

On 24-Jun-06, at 9:23 AM, Ben Laurie wrote:

>> On a related note, the primary security threat I saw with DIX was how
>> the user knows they are at their IdP. DIX considers that out of band
>> as there does not need to be a standard way of doing it for DIX, each
>> IdP could do it a different way, and given this is a place the user
>> is visiting often whose purpose is to make sure the user knows they
>> are at the IdP and the IdP to have certainty it is the user, the
>> investment in stronger authN for both the user and the site is
>> worthwhile.
>
> Isn't this essentially the primary security threat behind all  
> phishing?

Agreed. My point is that it is much easier to solve it in one place  
then on all sites. The IdP can become a combination of client side  
and server side code to deal much more effectively with the phishing  
issue. It is unreasonable for every site to do that.

-- Dick

Date: Sat, 24 Jun 2006 17:23:02 +0100
From: "Ben Laurie" <[email-masked]>
To: "Digital Identity Exchange" <[email-masked]>
Subject: Re: [dix] Re: [Ietf-http-auth] Notes on Web authentication enhancements
Cc: [email-masked]

[re-adding missing lists]

On 6/24/06, Dick Hardt <[email-masked]> wrote:
>
> On 23-Jun-06, at 9:17 PM, Eric Rescorla wrote:
> >>
> >> In DIX, the RP includes a nonce in the request, which must then also
> >> be in the nonce which would prevent replay attacks assuming the RP is
> >> managing nonce state would it not?
> >
> > Only if each authentication token is only single-use. Otherwise,
> > an attacker can replay it during the validity period. Even then,
> > cut-and-paste attacks are still possible if you block the
> > initial request.
>
> My understanding of the definition of a nonce is that it is single-use.
> Would you humour me with an explanation of a cut-and-paste attack per
> above?

Ideally a nonce is single-use, but often people want to avoid keeping
state on the server(s), so instead the nonce expires after a (short)
time. For example, the nonce is a random number+a timestamp signed by
the server. When it comes back, the server checks the signature and
the timestamp.

> >> I saw the security risk here being the reliance on DNS for identity
> >> of the IdP in the verification step.
> >
> > Hmm.... I think this depends on the design. If you're using
> > SSL/TLS, you should be able to block most attacks of this
> > class, provided you have a CRA authentication method...
>
> Agreed.
>
> On a related note, the primary security threat I saw with DIX was how
> the user knows they are at their IdP. DIX considers that out of band
> as there does not need to be a standard way of doing it for DIX, each
> IdP could do it a different way, and given this is a place the user
> is visiting often whose purpose is to make sure the user knows they
> are at the IdP and the IdP to have certainty it is the user, the
> investment in stronger authN for both the user and the site is
> worthwhile.

Isn't this essentially the primary security threat behind all phishing?

From: Dick Hardt <[email-masked]>
Subject: Re: [Ietf-http-auth] Notes on Web authentication enhancements
Date: Sat, 24 Jun 2006 07:57:14 -0700
To: EKR <[email-masked]>
Cc: [email-masked], [email-masked]

On 23-Jun-06, at 9:17 PM, Eric Rescorla wrote:
>>
>> In DIX, the RP includes a nonce in the request, which must then also
>> be in the nonce which would prevent replay attacks assuming the RP is
>> managing nonce state would it not?
>
> Only if each authentication token is only single-use. Otherwise,
> an attacker can replay it during the validity period. Even then,
> cut-and-paste attacks are still possible if you block the
> initial request.

My understanding of the definition of a nonce is that it is single-use.
Would you humour me with an explanation of a cut-and-paste attack per  
above?

>> I saw the security risk here being the reliance on DNS for identity
>> of the IdP in the verification step.
>
> Hmm.... I think this depends on the design. If you're using
> SSL/TLS, you should be able to block most attacks of this
> class, provided you have a CRA authentication method...

Agreed.

On a related note, the primary security threat I saw with DIX was how  
the user knows they are at their IdP. DIX considers that out of band  
as there does not need to be a standard way of doing it for DIX, each  
IdP could do it a different way, and given this is a place the user  
is visiting often whose purpose is to make sure the user knows they  
are at the IdP and the IdP to have certainty it is the user, the  
investment in stronger authN for both the user and the site is  
worthwhile.

-- Dick

To: Dick Hardt <[email-masked]>
Subject: Re: [Ietf-http-auth] Notes on Web authentication enhancements
From: Eric Rescorla <[email-masked]>
Date: Fri, 23 Jun 2006 21:17:06 -0700
Cc: [email-masked], [email-masked]
Reply-To: EKR <[email-masked]>

Dick Hardt <[email-masked]> writes:

> On 19-Jun-06, at 2:59 PM, Eric Rescorla wrote:
>
>> CARRIED NONCRYPTOGRAPHICALLY INSIDE HTTP
>> One approach that comes up quite a bit is to just embed
>> authentication tokens (typically generated by an IdP) in
>> the HTTP messages that go from the user to the RP (DIX is
>> an example of such a scheme). In this system, the tokens
>> themselves are "bearer"--they enable any holder to impersonate
>> the user. In order to protect against token capture, the tokens
>> are generally made specific to the RP, so that one RP can't
>> use them to impersonate the user to another.
>>
>> An additional issue is hijacking: without cryptographic
>> binding, an attacker who observes a request can make future
>> requests in the name of the user via a cut-and-paste attack
>> (remember, the token is bearer). If you take the threat of
>> this type of attack seriously, you need to run the traffic
>> over SSL/TLS. [1]
>>
>> The primary attraction of this kind of design is that it
>> may be implementable without changing the client software
>> at all (again, see DIX). Many people see that as important
>> for deployment.
>
> In DIX, the RP includes a nonce in the request, which must then also
> be in the nonce which would prevent replay attacks assuming the RP is
> managing nonce state would it not?

Only if each authentication token is only single-use. Otherwise,
an attacker can replay it during the validity period. Even then,
cut-and-paste attacks are still possible if you block the
initial request.

> I saw the security risk here being the reliance on DNS for identity
> of the IdP in the verification step.

Hmm.... I think this depends on the design. If you're using
SSL/TLS, you should be able to block most attacks of this
class, provided you have a CRA authentication method...

-Ekr

To: Dick Hardt <[email-masked]>
Subject: Re: [Ietf-http-auth] Notes on Web authentication enhancements
From: Eric Rescorla <[email-masked]>
Date: Fri, 23 Jun 2006 21:11:21 -0700
Cc: [email-masked], [email-masked]
Reply-To: EKR <[email-masked]>

Dick Hardt <[email-masked]> writes:
>> Part of the problem is that the user and the software have
>> a different view of the RP's identity. The software knows that
>> C1tibank and Citibank are different, but the user does not.
>
> Minor clarification: I was at the recent Anti Phishing Working Group
> meeting and many phishing attacks are gathering personal data in
> addition to or instead of the user's password.

Fair enough....

-Ekr

From: Dick Hardt <[email-masked]>
Subject: Re: [Ietf-http-auth] Notes on Web authentication enhancements
Date: Fri, 23 Jun 2006 19:14:58 -0700
To: Eric Rescorla <[email-masked]>
Cc: [email-masked], [email-masked]

On 19-Jun-06, at 2:59 PM, Eric Rescorla wrote:

> CARRIED NONCRYPTOGRAPHICALLY INSIDE HTTP
> One approach that comes up quite a bit is to just embed
> authentication tokens (typically generated by an IdP) in
> the HTTP messages that go from the user to the RP (DIX is
> an example of such a scheme). In this system, the tokens
> themselves are "bearer"--they enable any holder to impersonate
> the user. In order to protect against token capture, the tokens
> are generally made specific to the RP, so that one RP can't
> use them to impersonate the user to another.
>
> An additional issue is hijacking: without cryptographic
> binding, an attacker who observes a request can make future
> requests in the name of the user via a cut-and-paste attack
> (remember, the token is bearer). If you take the threat of
> this type of attack seriously, you need to run the traffic
> over SSL/TLS. [1]
>
> The primary attraction of this kind of design is that it
> may be implementable without changing the client software
> at all (again, see DIX). Many people see that as important
> for deployment.

In DIX, the RP includes a nonce in the request, which must then also  
be in the nonce which would prevent replay attacks assuming the RP is  
managing nonce state would it not?

I saw the security risk here being the reliance on DNS for identity  
of the IdP in the verification step.

-- Dick

From: Dick Hardt <[email-masked]>
Subject: Re: [Ietf-http-auth] Notes on Web authentication enhancements
Date: Fri, 23 Jun 2006 19:12:16 -0700
To: Eric Rescorla <[email-masked]>
Cc: [email-masked], [email-masked]

On 19-Jun-06, at 2:59 PM, Eric Rescorla wrote:
>
> 4. Fill-in of Personal Information (FPI)
> One of the common complaints about Web form registration systems
> is the need to repeatedly type in your user information. Think of this
> as automatic form fill-in on steroids. The rationale for this
> feature is to avoid repeated typing of this kind of information.

Once there is a programatic method of moving the identity data, it  
could be much richer then what people would type into a form. Eg. my  
list of favorite books, movies. This week I met someone that wanted  
to move virtual model data so that the user could tell a clothing  
store their dimensions etc.

This also leads into moving the identity data from a site that might  
generate to storage for later use.

From: Dick Hardt <[email-masked]>
Subject: Re: [Ietf-http-auth] Notes on Web authentication enhancements
Date: Fri, 23 Jun 2006 18:51:26 -0700
To: EKR <[email-masked]>
Cc: [email-masked], [email-masked]

On 23-Jun-06, at 3:29 PM, Eric Rescorla wrote:

>>>
>>> 1. Capture-Resistant Credentials (CRC)
>>> Credentials which are designed so that if you authenticate
>>> to relying party (RP) X, X cannot use them to impersonate you to  
>>> RP Y
>>> (even if your intention was to go to Y). Phishing is based
>>> on the fact that passwords do not have this property.
>>> The rationale for this feature is to make phishing-type
>>> attacks difficult.
>>
>> This is a bit confusing; to me (disclaimer -- I'm just a layman, not
>> a security expert), phishing is based on confusing the user about the
>> RP's identity, not reusing credentials from RP X with RP Y. Of
>> course, if you enable Common User Credentials, phishing will be
>> possible in this manner.
>
> I see what you mean here, but let me try to explain what I'm
> talking about and see if you still disagree with my taxonomy.
> In a classic phishing attack, the attacker convinces you
> to authenticate to them under the impression (in between
> your ears) that you're authenticating to someone else. For
> concreteness, say that the Phishing site is spoofing Citibank
> and the Phishing site has domain name C1tibank.
>
> The reason this works is that the authentication token that
> your software sends to C1tibank (your password) is the same
> as the token it sends to Citibank. In systems where these
> are separated (e.g., Boneh's PwdHash) then phishing attacks
> don't work. You can capture an authentication token but
> you can't re-use it to impersonate the user to the real RP.
>
> Part of the problem is that the user and the software have
> a different view of the RP's identity. The software knows that
> C1tibank and Citibank are different, but the user does not.

Minor clarification: I was at the recent Anti Phishing Working Group  
meeting and many phishing attacks are gathering personal data in  
addition to or instead of the user's password.

-- Dick 

Date: Fri, 23 Jun 2006 18:30:04 -0400
From: "Robert Sayre" <[email-masked]>
To: "Mark Nottingham" <[email-masked]>
Subject: Re: [Ietf-http-auth] Notes on Web authentication enhancements
Cc: [email-masked], [email-masked]

On 6/23/06, Mark Nottingham <[email-masked]> wrote:
>
> On 2006/06/19, at 2:59 PM, Eric Rescorla wrote:
>
>> 1. Capture-Resistant Credentials (CRC)
>
> This is a bit confusing; to me (disclaimer -- I'm just a layman, not a
> security expert), phishing is based on confusing the user about the RP's
> identity, not reusing credentials from RP X with RP Y. Of course, if you
> enable Common User Credentials, phishing will be possible in this manner.
>

FWIW, I took this mean that the attacker is able to reuse your
credentials on the site being impersonated. For example, Basic+TLS
requests give up your plain text password to chase.com if you are
tricked into sending them to evil-chase.com.

-- 

Robert Sayre

To: Mark Nottingham <[email-masked]>
Subject: Re: [Ietf-http-auth] Notes on Web authentication enhancements
From: Eric Rescorla <[email-masked]>
Date: Fri, 23 Jun 2006 15:29:20 -0700
Cc: [email-masked], [email-masked]
Reply-To: EKR <[email-masked]>

Mark Nottingham <[email-masked]> writes:

> Eric,
>
> This is excellent -- very helpful. I agree WRT the lack of a common
> view of requirements.
>
> A few comments / questions below.
>
> On 2006/06/19, at 2:59 PM, Eric Rescorla wrote:
>>
>> 1. Capture-Resistant Credentials (CRC)
>> Credentials which are designed so that if you authenticate
>> to relying party (RP) X, X cannot use them to impersonate you to RP Y
>> (even if your intention was to go to Y). Phishing is based
>> on the fact that passwords do not have this property.
>> The rationale for this feature is to make phishing-type
>> attacks difficult.
>
> This is a bit confusing; to me (disclaimer -- I'm just a layman, not
> a security expert), phishing is based on confusing the user about the
> RP's identity, not reusing credentials from RP X with RP Y. Of
> course, if you enable Common User Credentials, phishing will be
> possible in this manner.

I see what you mean here, but let me try to explain what I'm
talking about and see if you still disagree with my taxonomy.
In a classic phishing attack, the attacker convinces you
to authenticate to them under the impression (in between
your ears) that you're authenticating to someone else. For
concreteness, say that the Phishing site is spoofing Citibank
and the Phishing site has domain name C1tibank.

The reason this works is that the authentication token that
your software sends to C1tibank (your password) is the same
as the token it sends to Citibank. In systems where these
are separated (e.g., Boneh's PwdHash) then phishing attacks
don't work. You can capture an authentication token but
you can't re-use it to impersonate the user to the real RP.

Part of the problem is that the user and the software have
a different view of the RP's identity. The software knows that
C1tibank and Citibank are different, but the user does not.

> With that in mind, I wonder if this is much different from...
>
>> 2. Hijack-Resistant Authentication (HRA)
>> An authentication system in which credentials which are bound to
>> protocol messages in such a way that attacker who observes the
>> credentials can't use them to authenticate messages of their
>> choice. The rationale for this feature is to make cut-and-paste
>> attacks difficult.

To take a concrete example here, PwdHash is susceptible to 
hijacking attacks (do ordinary connection hijacking) if SSL/TLS
is not used but is not susceptible to straight phishing attacks.
So, I don't think these are different.

> FWIW, I'd leave out most of the first sentence here; protocol binding
> is more implementation detail than requirement.

Fair enough, but I think it needs to be inverted to make the 
requirement clear.

>> 7. User-Friendly Names (UFN)
>> The ability to prove possession of some non-random-appearing
>> name. The reason to separate this out is that one natural
>> way to provide CI is simply to generate some random asymmetric
>> key pair and use that (or its digest) as your identity. This
>> name is not user friendly. Note that this is the first requirement
>> in this list that appears to require a third party (to assign
>> the names). The rationale for this feature is that random names
>> are hard to remember.
>
> Well, it requires a third party if you're trying to co-ordinate names
> across multiple domains (again, there's an i-built assumption that
> there will be CUC).

I think mostly true, though even in single-site systems, it's
annoying to have to force unique names.

>> 8. Assertion of External Claims (AEC)
>> The ability to demonstrate some real-world fact about the user
>> (e.g., I am a certain age, this is my address, etc.) to the
>> RP. The rationale for this feature is that there are contexts
>> in which the relying party needs to be able to establish this
>> sort of information.
>>
>> 10. Independent Assertion of Claims (IAC)
>> The ability to assert claims independently so that the user
>> could (for instance) demonstrate their age to the RP without
>> without revealing their address. The rationale for this
>> feature is to protect the user's privacy.
>
> #10 is a sub-case of #8, no?

Yes.

>> 11. Private Authentication (PA)
>> Some third-party authentication systems require an interaction
>> with the 3rd party for each authentication. In some such systems,
>> the 3rd party knows the relying party for each authentication
>> and the claims which were asserted. PA means that the 3rd party
>> does not get that information. The rationale for this feature
>> is to protect the user's privacy from the 3rd party.
>
> I *think* this is saying that there's a requirement to separate the
> identity from authentication, so that a 3rd party site doesn't learn
> any details about the user at all (e.g., userid, password, name, e-
> mail, etc.), but only is given the ability to act on their behalf in
> certain cases.
>
> Do I have that right, or is this something else?

That's not what I had in mind, though it's another interesting
property. What I meant was that the 3rd party doesn't find out
what sites you're visiting and what credentials you proved
to them; that way if Yahoo is my identity provider they
don't find out what kind of porn sites I visit.

-Ekr

From: Mark Nottingham <[email-masked]>
Subject: Re: [Ietf-http-auth] Notes on Web authentication enhancements
Date: Fri, 23 Jun 2006 15:12:48 -0700
To: Eric Rescorla <[email-masked]>
Cc: [email-masked], [email-masked]

--Apple-Mail-1-994876998
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

Eric,

This is excellent -- very helpful. I agree WRT the lack of a common  
view of requirements.

A few comments / questions below.

On 2006/06/19, at 2:59 PM, Eric Rescorla wrote:
>
> 1. Capture-Resistant Credentials (CRC)
> Credentials which are designed so that if you authenticate
> to relying party (RP) X, X cannot use them to impersonate you to RP Y
> (even if your intention was to go to Y). Phishing is based
> on the fact that passwords do not have this property.
> The rationale for this feature is to make phishing-type
> attacks difficult.

This is a bit confusing; to me (disclaimer -- I'm just a layman, not  
a security expert), phishing is based on confusing the user about the  
RP's identity, not reusing credentials from RP X with RP Y. Of  
course, if you enable Common User Credentials, phishing will be  
possible in this manner.

With that in mind, I wonder if this is much different from...

> 2. Hijack-Resistant Authentication (HRA)
> An authentication system in which credentials which are bound to
> protocol messages in such a way that attacker who observes the
> credentials can't use them to authenticate messages of their
> choice. The rationale for this feature is to make cut-and-paste
> attacks difficult.

FWIW, I'd leave out most of the first sentence here; protocol binding  
is more implementation detail than requirement.

> 7. User-Friendly Names (UFN)
> The ability to prove possession of some non-random-appearing
> name. The reason to separate this out is that one natural
> way to provide CI is simply to generate some random asymmetric
> key pair and use that (or its digest) as your identity. This
> name is not user friendly. Note that this is the first requirement
> in this list that appears to require a third party (to assign
> the names). The rationale for this feature is that random names
> are hard to remember.

Well, it requires a third party if you're trying to co-ordinate names  
across multiple domains (again, there's an i-built assumption that  
there will be CUC).

> 8. Assertion of External Claims (AEC)
> The ability to demonstrate some real-world fact about the user
> (e.g., I am a certain age, this is my address, etc.) to the
> RP. The rationale for this feature is that there are contexts
> in which the relying party needs to be able to establish this
> sort of information.
>
> 10. Independent Assertion of Claims (IAC)
> The ability to assert claims independently so that the user
> could (for instance) demonstrate their age to the RP without
> without revealing their address. The rationale for this
> feature is to protect the user's privacy.

#10 is a sub-case of #8, no?

> 11. Private Authentication (PA)
> Some third-party authentication systems require an interaction
> with the 3rd party for each authentication. In some such systems,
> the 3rd party knows the relying party for each authentication
> and the claims which were asserted. PA means that the 3rd party
> does not get that information. The rationale for this feature
> is to protect the user's privacy from the 3rd party.

I *think* this is saying that there's a requirement to separate the  
identity from authentication, so that a 3rd party site doesn't learn  
any details about the user at all (e.g., userid, password, name, e- 
mail, etc.), but only is given the ability to act on their behalf in  
certain cases.

Do I have that right, or is this something else?

Overall, that's quite an ambitious list, and I'm very curious to see  
how much any effort will attempt to bite off.

One other thing;

> CARRIED NONCRYPTOGRAPHICALLY INSIDE HTTP
> One approach that comes up quite a bit is to just embed
> authentication tokens (typically generated by an IdP) in
> the HTTP messages that go from the user to the RP (DIX is
> an example of such a scheme). In this system, the tokens
> themselves are "bearer"--they enable any holder to impersonate
> the user. In order to protect against token capture, the tokens
> are generally made specific to the RP, so that one RP can't
> use them to impersonate the user to another.
>
> An additional issue is hijacking: without cryptographic
> binding, an attacker who observes a request can make future
> requests in the name of the user via a cut-and-paste attack
> (remember, the token is bearer). If you take the threat of
> this type of attack seriously, you need to run the traffic
> over SSL/TLS. [1]
>
> The primary attraction of this kind of design is that it
> may be implementable without changing the client software
> at all (again, see DIX). Many people see that as important
> for deployment.

It sounds like one interesting discussion would surround what  
people's tolerance for these attacks is, and ways to mitigate them.

Cheers,

--
Mark Nottingham
[email-masked]

--Apple-Mail-1-994876998
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; ">Eric,<DIV><BR class="khtml-block-placeholder"></DIV><DIV>This is excellent -- very helpful. I agree WRT the lack of a common view of requirements.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>A few comments / questions below.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><DIV><DIV>On 2006/06/19, at 2:59 PM, Eric Rescorla wrote:</DIV><BLOCKQUOTE type="cite"><DIV><FONT class="Apple-style-span" color="#000000"><BR class="khtml-block-placeholder"></FONT></DIV><DIV>1. Capture-Resistant Credentials (CRC)</DIV><DIV>Credentials which are designed so that if you authenticate</DIV><DIV>to relying party (RP) X, X cannot use them to impersonate you to RP Y</DIV><DIV>(even if your intention was to go to Y). Phishing is based</DIV><DIV>on the fact that passwords do not have this property.</DIV><DIV>The rationale for this feature is to make phishing-type</DIV><DIV>attacks difficult.</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>This is a bit confusing; to me (disclaimer -- I'm just a layman, not a security expert), phishing is based on confusing the user about the RP's identity, not reusing credentials from RP X with RP Y. Of course, if you enable Common User Credentials, phishing will be possible in this manner.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>With that in mind, I wonder if this is much different from...</DIV><BR><BLOCKQUOTE type="cite"><DIV>2. Hijack-Resistant Authentication (HRA)</DIV><DIV>An authentication system in which credentials which are bound to</DIV><DIV>protocol messages in such a way that attacker who observes the</DIV><DIV>credentials can't use them to authenticate messages of their</DIV><DIV>choice. The rationale for this feature is to make cut-and-paste</DIV><DIV>attacks difficult.</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>FWIW, I'd leave out most of the first sentence here; protocol binding is more implementation detail than requirement.</DIV><BLOCKQUOTE type="cite"></BLOCKQUOTE><BR><BLOCKQUOTE type="cite"><DIV>7. User-Friendly Names (UFN)</DIV><DIV>The ability to prove possession of some non-random-appearing</DIV><DIV>name. The reason to separate this out is that one natural</DIV><DIV>way to provide CI is simply to generate some random asymmetric</DIV><DIV>key pair and use that (or its digest) as your identity. This</DIV><DIV>name is not user friendly. Note that this is the first requirement</DIV><DIV>in this list that appears to require a third party (to assign</DIV><DIV>the names). The rationale for this feature is that random names</DIV><DIV>are hard to remember.</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Well, it requires a third party if you're trying to co-ordinate names across multiple domains (again, there's an i-built assumption that there will be CUC). </DIV><BR><BLOCKQUOTE type="cite"><DIV>8. Assertion of External Claims (AEC)</DIV><DIV>The ability to demonstrate some real-world fact about the user</DIV><DIV>(e.g., I am a certain age, this is my address, etc.) to the</DIV><DIV>RP. The rationale for this feature is that there are contexts</DIV><DIV>in which the relying party needs to be able to establish this</DIV><DIV>sort of information.</DIV><DIV><BR></DIV><DIV>10. Independent Assertion of Claims (IAC)</DIV><DIV>The ability to assert claims independently so that the user</DIV><DIV>could (for instance) demonstrate their age to the RP without</DIV><DIV>without revealing their address. The rationale for this</DIV><DIV>feature is to protect the user's privacy.</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>#10 is a sub-case of #8, no?</DIV><BR><BLOCKQUOTE type="cite"><DIV>11. Private Authentication (PA)</DIV><DIV>Some third-party authentication systems require an interaction</DIV><DIV>with the 3rd party for each authentication. In some such systems,</DIV><DIV>the 3rd party knows the relying party for each authentication</DIV><DIV>and the claims which were asserted. PA means that the 3rd party</DIV><DIV>does not get that information. The rationale for this feature</DIV><DIV>is to protect the user's privacy from the 3rd party.</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I *think* this is saying that there's a requirement to separate the identity from authentication, so that a 3rd party site doesn't learn any details about the user at all (e.g., userid, password, name, e-mail, etc.), but only is given the ability to act on their behalf in certain cases. </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Do I have that right, or is this something else?</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Overall, that's quite an ambitious list, and I'm very curious to see how much any effort will attempt to bite off.</DIV><DIV><BR class="khtml-block-placeholder"></DIV>One other thing;</DIV><DIV><BR><BLOCKQUOTE type="cite"><DIV></DIV><DIV>CARRIED NONCRYPTOGRAPHICALLY INSIDE HTTP</DIV><DIV>One approach that comes up quite a bit is to just embed </DIV><DIV>authentication tokens (typically generated by an IdP) in</DIV><DIV>the HTTP messages that go from the user to the RP (DIX is</DIV><DIV>an example of such a scheme). In this system, the tokens</DIV><DIV>themselves are "bearer"--they enable any holder to impersonate</DIV><DIV>the user. In order to protect against token capture, the tokens</DIV><DIV>are generally made specific to the RP, so that one RP can't</DIV><DIV>use them to impersonate the user to another. </DIV><DIV><BR></DIV><DIV>An additional issue is hijacking: without cryptographic </DIV><DIV>binding, an attacker who observes a request can make future</DIV><DIV>requests in the name of the user via a cut-and-paste attack</DIV><DIV>(remember, the token is bearer). If you take the threat of</DIV><DIV>this type of attack seriously, you need to run the traffic</DIV><DIV>over SSL/TLS. [1] </DIV><DIV><BR></DIV><DIV>The primary attraction of this kind of design is that it</DIV><DIV>may be implementable without changing the client software</DIV><DIV>at all (again, see DIX). Many people see that as important</DIV><DIV>for deployment. </DIV></BLOCKQUOTE></DIV><DIV><BR class="khtml-block-placeholder"></DIV>It sounds like one interesting discussion would surround what people's tolerance for these attacks is, and ways to mitigate them.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Cheers,</DIV><DIV><BR><DIV> <DIV>--</DIV><DIV>Mark Nottingham </DIV><DIV><A href="mailto:[email-masked]">[email-masked]</A></DIV><DIV><BR class="khtml-block-placeholder"></DIV><BR class="Apple-interchange-newline"> </DIV><BR></DIV></BODY></HTML>
--Apple-Mail-1-994876998--

From: Sam Hartman <[email-masked]>
To: Digital Identity Exchange <[email-masked]>
Subject: Re: [dix] RE: [Ietf-http-auth] Notes on Web authentication enhancements
Date: Wed, 21 Jun 2006 10:16:46 -0400
Cc: [email-masked]

Phil, I think I agree with the importance of having definitions.

I find it amusing that I cannot understand what you mean by user
interaction attacks and chrome attacks; I cannot tell what you would
consider within those definitions and what you would consider outside
those definitions.

I also don't know where you consider the boundary for network layer
issues; I may or may not agree with you that should be out of scope.

Content-class: urn:content-classes:message
Subject: RE: [Ietf-http-auth] Notes on Web authentication enhancements
Date: Tue, 20 Jun 2006 14:34:00 -0700
From: "Hallam-Baker, Phillip" <[email-masked]>
To: <[email-masked]>, <[email-masked]>

I just sent this message to the W3C pre-WG mailing list. I think the message is equally applicable here only any new group/groups should either identify a different part of the problem to address or they should coordinate with the W3C group so that the groups avoid going off to hunt the same bear. When that happens the most likely outcome is the groups end up shooting each other instead of the bear.

I was at the TIPPI workshop yesterday which showed a similar tendency to become defocused as people became confused about the question of what problem was being addressed in a presentation.
 
Presenter shows plugin designed to explore the user interface issues:
 
        "What about key loggers", "what about a man in the middle attack", "no the real problem is the authentication credentials", "the phishing criminals will just go into selling plots of land in the Florida", and so on.
 
There are many problems here, when we are talking about digest algorithms we have an established vocabulary of terms, SHA-1 is not broken, it is subject to a compression collision attack but is still secure against the second pre-image attack. So when we are talking about S/MIME we say, no the SHA-1attacks do not compromise the use in that protocol but they are a sign we should start the transition process. 
 
What we need is a simple taxonomy of four or five terms (5 = 7-2) that we can use to refer to the various attacks. We choose to address one or at most two of those terms in this group. Everything else is out of scope.
 
Examples:
 
Platform Layer Attacks: OUT OF SCOPE
        
        Keyboard loggers, mouse click and screen capture trojans are all serious security issues. 
 
        Building platforms resistant to those attacks are the sole responsibility of Brian, Butler, Linus and Steve (surnames redacted for their own protection). It makes no sense for a standards working group to attempt to solve those problems. Preventing the circulation of malware is going to be the responsibility of the ISPs hosting the bots. 
 
Network Layer Attacks: OUT OF SCOPE
 
        We have several people in the group who are cryptographers and/or network security protocol designers. There is a place to discuss that work, this is not it. There is no shortage of forums that are developing authentication &ct. protocols. 
 
Trust Infrastructure Attacks: OUT OF SCOPE
 
        If we are going to stop phishing we are going to need a means of making sure that the site representing itself as Contoso bank on the net reall is the same corporation as the place where you opened the account abd handed over the check. This infrastructure is necessary, complex and I am currently sitting in the CA-Browser forum where we are discussing that exact problem.
 
User Interaction Attacks: IN SCOPE
 
        How does the browser communicate the security context to the user?
 
Chrome Attacks: IN SCOPE
 
        How does the browser ensure that the trusted path used to communicate the security context is trustworthy?
        
The title of this group is not 'the lone group that is going to stop the problem of phishing all by itself'. 

We have retrod the well trodden paths plenty of times. We have to assume that the groups that are dedicated to addressing those problems are going to deliver controls that are effective at an acceptable level.
 
At the moment the groups working on those problems are all saying 'we can stop the keylogger problem but what is the point if the social engineering attack is still open'.

To: [email-masked], [email-masked]
Date: Mon, 19 Jun 2006 14:59:29 -0700
From: Eric Rescorla <[email-masked]>
Subject: [Ietf-http-auth] Notes on Web authentication enhancements

There's obviously a lot of interest in working on various enhancements
to Web and Web Services applications. Unfortunately, after reading
the various drafts and mailing list postings produced by the proponents
of various technologies, I don't come away with the sense that people
have a common view of what is needed. This message is a first cut
at a taxonomy of requirements/features and technical options.

BACKGROUND: THE CURRENT STATE OF HTTP AUTHENTICATION
----------------------------------------------------
HTTP has two native authentication mechanisms, Basic Authentication
(passwords in the clear in an HTTP header) and Digest Authentication
(a challenge-response handshake also in the HTTP header). Both
mechanisms depend on the client proving the possession of a shared
secret string (a password in all real cases) to the server. The
server is unauthenticated.

For a variety of reasons, including bad UI on the clients, nearly
all real-world Web applications use neither mechanism but rather
use an HTML form to prompt the user for his password. This
password is then sent in the clear over the HTTP connection.
The standard security advice for how to secure this data is to
use HTTPS (HTTP over SSL/TLS) to encrypt the entire channel
and use the server's certificate to authenticate the server.
Practical difficulties with checking the certificate have led
to phishing attacks, in which the attacker gathers the user's
password and can then impersonate the user. An additional problem
is that it's hard for Web Services apps (e.g., DAV) to use this
kind of mechanism because HTML may not be involved and so if 
it works at all you end up resorting to screen-scraping.

In principle, if you run HTTPS, you can leverage HTTPS's 
client authentication mechanisms (client certificates and
"pre-shared keys") to authenticate the client, but in practice
this is not done, probably due to UI reasons and lack of
familiarity with the TLS mechanisms (this applies in particular
to PSK).

DESIRABLE FUNCTIONALITY
-----------------------
As I mentioned above, a lot of different types of functionality
have been discussed. In this section, I try to break these down
into a set of somewhat independent functions, with the intention
that we can end up saying that we want a system that provides
function X and not Y. These all have sort of lame names that I
thought of on the spot.

1. Capture-Resistant Credentials (CRC)
Credentials which are designed so that if you authenticate
to relying party (RP) X, X cannot use them to impersonate you to RP Y
(even if your intention was to go to Y). Phishing is based
on the fact that passwords do not have this property.
The rationale for this feature is to make phishing-type
attacks difficult.

2. Hijack-Resistant Authentication (HRA)
An authentication system in which credentials which are bound to
protocol messages in such a way that attacker who observes the
credentials can't use them to authenticate messages of their
choice. The rationale for this feature is to make cut-and-paste
attacks difficult.

3. Portable Credentials (PC)
The nice thing about passwords is that you can memorize your
password and then use it anywhere. The rationale for this is 
to make it easy for people to use credentials on multiple
computers.

4. Fill-in of Personal Information (FPI)
One of the common complaints about Web form registration systems
is the need to repeatedly type in your user information. Think of this
as automatic form fill-in on steroids. The rationale for this
feature is to avoid repeated typing of this kind of information.

5. Common User Credentials (CUC)
One way to limit the damage from credential compromise is to
have each RP use a separate credential and force the user
to make them independent (e.g., a separate password for each
RP.) This is inconvenient, of course. CUC means that at
the number of separate credentials that the user handles is 
small (if not 1). The rationale for this feature is to minimize
user attention and storage overhead.

6. Continuity of Identity (CI)
The ability to prove to some RP that you are the same
user as was involved in some other transaction. The rationale
for this feature is to have a cheap form of personal 
"account" for systems like blog comments, message boards,
etc.

7. User-Friendly Names (UFN)
The ability to prove possession of some non-random-appearing
name. The reason to separate this out is that one natural
way to provide CI is simply to generate some random asymmetric
key pair and use that (or its digest) as your identity. This
name is not user friendly. Note that this is the first requirement
in this list that appears to require a third party (to assign
the names). The rationale for this feature is that random names
are hard to remember.

8. Assertion of External Claims (AEC)
The ability to demonstrate some real-world fact about the user
(e.g., I am a certain age, this is my address, etc.) to the
RP. The rationale for this feature is that there are contexts
in which the relying party needs to be able to establish this
sort of information.

10. Independent Assertion of Claims (IAC)
The ability to assert claims independently so that the user
could (for instance) demonstrate their age to the RP without
without revealing their address. The rationale for this
feature is to protect the user's privacy.

11. Private Authentication (PA)
Some third-party authentication systems require an interaction
with the 3rd party for each authentication. In some such systems,
the 3rd party knows the relying party for each authentication
and the claims which were asserted. PA means that the 3rd party
does not get that information. The rationale for this feature
is to protect the user's privacy from the 3rd party.

ARCHITECTURAL CHOICES
---------------------
In this section, we survey a number of potential architectural options.
This list isn't exhaustive, but is just intended to give a flavor
of the major available choices beyond the simple two-party
username-password schemes we have now. Note that I use a lot 
of PKIX-type terminology below, but the concepts are generic
and can be extended to something more SAML-oid or
something-else-oid.

BARE CRYPTOGRAPHIC IDENTIFIER 
After username/password, probably the most familiar sort of
remote identifier is a bare public key. The way this is
used is familiar from SSH: the user generates a public key
and provides the key (or fingerprint) to the relying party
(or parties). He can then sign with the private key to
prove possession.

User                                     RP
----                                     --
[Personal Info], K_pub ->                        \  Registration
                                      <- OK      /  Phase

Sign(K_priv, Something) ->                       \  Use 
                                 <- Service      /  Phase

In the Registration phase, the user provides his registration info
to the relying party (site) along with the public key. The
RP stores the data somewhere. In the Use phase the user signs
something with his key to prove his identity.

Properties:
If properly embedded in a protocol (it's easy to get this wrong),
this scheme can provide:

CRC -- the RP only has K_pub
HRA -- you can cryptographically bind the requests to the key
CUC -- you can use the same K_pub, K_priv pair over and over
CI  -- you use the same identity every time even if nobody
       knows who you are.
PA  -- there's no third-party to know anything about the
       exchange

With an automated form fillin scheme like that specified in DIX,
you could also provide FPI. 

IDENTITY CERTIFICATES
One of the major inconveniences in dealing with bare cryptographic
identifiers is that that names look basically random: they're
just public keys or hashes of public keys. This is a particular
problem if two RPs want to communicate about a user through
some human-based protocol, i.e., "Don't trust [email-masked]"

The natural way to deal with this problem is to have certificate
authorities which are responsible for sections of the namespace and
can issue certificates with user-friendly names.

These certificates can come in two flavors:

1. Real-world identity certificates.
2. Unique-identity certificates

Real-world identity certificates are familiar from the HTTPS
world: an SSL certificate from VeriSign is an assertion that
the certificate holder is the actual owner/operator of a
given domain. A unique-identity certificate is just a promise
from a CA not to issue any other certificates with the same
username. 

Either form of identity certificate allows you to have nice
userfriendly names (or at least more userfriendly than random
numbers). The protocol looks something like this:

User                                     CA
----                                     --
[Personal Info], K_pub ->                        \  Certificate
                                      <- OK      /  Issuance

The user gets a certificate (possibly covering some personal
info) from the CA. They can then use this certificate much
in the same way they used a bare key, by registering with
the RP and then getting service. 

User                                     RP
----                                     --
[Personal Info], Cert ->                         \  Registration
                                      <- OK      /  Phase

Sign(K_priv, Something) ->                       \  Use 
                                 <- Service      /  Phase

Note that some people also think of the mere possession of a
credential, even if it has no underlying AEC semantics as
worth something. I.e., this person registered *somewhere*
and I know that about them. This makes sense in contexts like
blog comment authentication where you are just trying to erect
a minimal registration barrier.

Properties:
This scheme has most of the same properties as the bare cryptographic
identifiers, but also has at minimum User Friendly Naming (UFN).
In addition, if the certificates are real-world identity certificates,
it provides a very limited form of AEC, namely "this person has
the right to this e-mail address, domain name, etc."

SIGNATURE + KEY SERVER
Both bare cryptographic identifiers and identity certificates suffer
from portability problems. The part of your identifier that you need
available to you at authentication time is a fairly long random number
that most people won't be willing to memorize. [0] The natural
approach is to carry the data around on a token (USB key, PCMCIA
card, etc.) but this seems unattractive to many. Another option is
to use a SACRED-type server to store the key and then let the user
fetch it at whatever computer they are at. SIP is also considering
a similar technique for moving keys between handsets (see
(draft-ietf-sip-certs)

Properties:
Same as underlying authentication scheme + Portable Credentials.

ATTRIBUTE CERTIFICATES
The clear problem with all the schemes mentioned so far is that
they only provide very limited AEC, which a lot of people clearly
want. The standard solution for combining AEC with public-key-based
authentication systems is to use attribute certificates: 
certificates that assert a certain fact about the holder of key
K, such as:

"The person who holds key K is an American citizen."

In PKIX these are often (always?) tied to some actual 3rd-party
certificate but from an architectural perspective, they could be tied
to a bare key. Attribute certificates can also be used to provide
IAC: you have a bundle of attribute certs with one for each claim
you wish to assert and you simply provide the relevant certs
to the RP.

The basic protocol looks like this:

User                                     CA
----                                     --
[Personal Info], K_pub ->                        \  Certificate
                           <- AC1 (Over 21)       > Issuance
                        <- AC2 (US Citizen)      /

In the Certificate Issuance phase, the user proves to the
CA the claims that he wants the CA to vouch for and the 
CA gives him ACs for those claims. 

User                                     RP
----                                     --
Sell me beer ->                               \
                         <- Prove you're 21    \ Use
Sign(K_priv, Something), AC ->                 / Phase
                                 <- Service   /

In the use phase, the RP indicates which claims he wants the
user to demonstrate and the user provides the appropriate
ACs and demonstrates that he has the corresponding key. 
Of course, for any attributes for which you have ACs, you
also get some FPI for free as part of the authentication.

Properties:
CRC, HRA, FPI (Some), PC (if used with key server), CUC, CI,
UFN, AEC, IAC, PA

IDENTITY PROVIDERS
A lot of the designs that people seem interested in involve
Identity Providers (IdP). An IdP is a server that offers
interactive identity claims. (One way to think of this is
as a real-time CA). There are a bunch of different 
topologies, but the basic idea is as below:

User                           IdP
----                           ---
[Personal Info], Auth Info ->       \  Registration 
                             <- OK  /  Phase     

The user registers with the IdP and (optionally) proves
the claims that he wishes the IdP to assert later. The
user needs to establish some sort of authentication
credential with the IdP so that he can authenticate
later. This can be a password or a public key pair (as
above). 

Later, when he wants to actually use his identity, we
get an exchange like this:

User                      RP                       IdP
----                      --                       ---
Sell me beer ->                                         
          <- Prove you're 21

IdP, help me!                                   ->
          <---------- Auth exchange ------------->
                                         <- Credential

Credential ->              
                       <- OK
                      
When the user requests service, the RP prompts them for their
identity (or in the case above, to prove some claims). The
User then contacts the IdP and proves their identity 
(authenticates as the person who previously registered)
and gets a credential. He Then provides the credential to the
RP, who provides the service. 

There are a lot of ways to implement this general architecture
and they all have different properties. 

Properties:
At minimum, IdP based schemes provide:
PC  -- you can contact the IdP from anywhere
CUC -- you only need to authenticate to the IdP and then can 
       leverage that to authenticate everywhere
CI  -- you use the same IdP acct over and over
UFN -- the IdP can issue you some easy name

If the IdP makes claims about you, then you can also have FPI, AEC and
IAC. In general, because the IdP knows which claims you're asserting
for a given RP, you do not get PA. There are, however, ways to provide
this feature, but often the contrary is part of the design of the
system.

A lot of the variation in IdP schemes is the implementation of 
the authentication, both from the user to the IdP and from the 
IdP (and user) to the RP. There's too much variation to discuss
here, but I'll cover a few high points.

Authentication to the IdP:
Part of the point of an IdP scheme is that you authenticate to
the IdP in order to get your credentials. Obviously, this 
authentication can be done in a lot of ways. Some of them
allow phishing, credential capture, etc. It's clearly
desirable to couple an IdP scheme with some sort of
auth scheme that provides CRC and probably HRA.

Binding of credentials to requests:
In an IdP scheme, the IdP provides some token to the user that is then
provided to the RP. This token may or may not be cryptographically
bound to the messages that the user is sending to the RP. If this
is not done, then the user<->RP protocol is potentially susceptible
to hijacking.

Note that it's well understood how to design both of these protocols
securely. However, it involves more changes to the current
implementations of Web and WS protocols.

TRANSPORTING/BINDING CREDENTIALS
--------------------------------
The discussion above has focused primarily on dataflow, but
from the perspective of implementation/deployment, how you
transport and bind the credentials to the PDUs they're 
authenticating matters. Note that to some extent this is 
orthogonal to the type of authentication architecture you're
using. You can, for instance, use public key signatures
with multiple binding/transport mechanisms. 

There are three commonly proposed transport/binding methods:

CRYPTOGRAPHIC BINDING INSIDE HTTP
If you're using public key for authentication, the natural approach is
to simply have the credentials bound directly to the HTTP PDUs they
vouch for. So, the PDU would contain a signature line that covered the
request itself. This is what, for example, S-HTTP does.

In systems like this, additional credentials (ACs, SAML assertions,
etc.) are just carried in the message and the whole thing is bound
together with the signature. Something like this:

         POST / HTTP/1.0
         X-Attribute-Cert: <insert A-C here>
         X-Signature: XXX

         Post arguments

The signature is computed over the entire message and headers (except
for the signature itself, of course), or part of it (hopefully enough
to block cut-and-paste attacks).  This kind of technique, if performed
correctly, provides both CRC and HRA for the messages between the user
and the RP.

Similar techniques can be use with symmetric keys and MACs over
the PDUs. In such schemes, if you're using an IdP, then you'll
probably also have to carry around a ticket that gives the 
RP the symmetric key needed to verify the message.

Implementing this kind of scheme would generally require a fair
amount of modification to the browser and server at least to
protect the messages. 

SSL/TLS CLIENT AUTHENTICATION
Another approach is to do things at a layer below HTTP, typically
using SSL/TLS client authentication. Currently, SSL/TLS supports
client authentication using pre-shared keys and certificates (you can
use self-signed certs as bare keys).  draft-housley-tls-authz-extns
defines how to carry X.509 ACs and SAML assertions inside of TLS, so
these could be used as well. This technique automatically provides CRC
and HRA.

In principle, TLS clients and servers already support at least
cert-based client auth. In practice, the UI on the client
is so bad that you would almost certainly need to clean it up
quite a bit in order to make this kind of system usable.

CARRIED NONCRYPTOGRAPHICALLY INSIDE HTTP
One approach that comes up quite a bit is to just embed 
authentication tokens (typically generated by an IdP) in
the HTTP messages that go from the user to the RP (DIX is
an example of such a scheme). In this system, the tokens
themselves are "bearer"--they enable any holder to impersonate
the user. In order to protect against token capture, the tokens
are generally made specific to the RP, so that one RP can't
use them to impersonate the user to another. 

An additional issue is hijacking: without cryptographic 
binding, an attacker who observes a request can make future
requests in the name of the user via a cut-and-paste attack
(remember, the token is bearer). If you take the threat of
this type of attack seriously, you need to run the traffic
over SSL/TLS. [1] 

The primary attraction of this kind of design is that it
may be implementable without changing the client software
at all (again, see DIX). Many people see that as important
for deployment. 

-Ekr

[0] You can use asymmetric key pairs generated from passwords,
but even with the application of key stretching techniques, this
makes a lot of people uncomfortable.

[1] Note that if you're worried about this class of attack, you need
*every* PDU to be cryptographically bound to the credential with
all designs. If, for instance, you use cert-based auth but then
transition to cookies over HTTP for state management, there's a 
cut-and-paste attack there.

From: Sam Hartman <[email-masked]>
To: [email-masked]
Date: Mon, 19 Jun 2006 13:59:25 -0400
Subject: [Ietf-http-auth] [Sam Hartman] [dix] An HTTP-based solution for digital identity

--=-=-

I think we're using the dix list to discuss stuff for the IETF 66 BOF
at this point.

--=-=-Content-Type: message/rfc822
Content-Disposition: inline

From: Sam Hartman <[email-masked]>
To: [email-masked]
Date: Mon, 19 Jun 2006 13:31:21 -0400
Subject: [dix] An HTTP-based solution for digital identity
Reply-To: Digital Identity Exchange <[email-masked]>

Hi, folks.  I said I was working on a draft describing use cases and a
specific technical proposal.  I have that draft done and it
compliments my phishing requirements draft.  I expect to update the
phishing requirements draft based on several reviews I've received and
based on what confuses people about it when I have explained it to
them in person.

I was intrigued by Phil Hallam-Baker's idea to separate HTTP
authentication into two parts : one between a user and some
authentication/identity service and one between the authentication
service and the relying party.  It is important to standardize the
second protocol; while standard methods of authentication to a
identity service would be desirable extensions offered by specific
identity providers may be useful and can be supported.  Phil suggested
starting with something like http-digest.  I started doing that
mentally during the last IETF meeting.  I found that I was reinventing
a lot of the Kerberos ap-req exchange--the exchange used to
authenticate to the server.

I started thinking about reuse of deployed code and realized that it
would probably be desirable to use existing code rather than inventing
some new protocol.  New protocols are often more complicated than they
at first seem they need to be and I definitely think this would be on
exception.  So, I decided to put together a sketch of how you could
just use Kerberos to meet these needs.  I was shocked at how much of
the infrastructure necessary to do this is already available in
current web browsers.

So, I decided to write up a proposal on how to realize some of the
goals in this space using Kerberos and other related technologies.  I
also described the use cases I'm attempting to solve.  My use cases
are less ambitious than the DIX use cases; personally I think that is
a good thing.  I do believe that my proposal can be expanded to meet
all the use cases that impinge on protocol interactions.  My belief is
that this should be done gradually.

I'm sure someone out there is going to claim that Kerberos is a
horrible fit for this and that it is too complicated.  I encourage you
to specify an alternative in at least as much detail as I have done so
we can compare the complexity, functionality, reuse of technology and
ease of deployment of proposals.  While any comments are welcome,
alternative proposals or explanations of how I got use cases wrong may
make constructive discussion easier than comments of the form "this
sucks."

At some level, the DIX proposal is an alternative.  However as I think
more about this problem space, I'm coming to the conclusion that a
redirect based approach is not really in conflict with a longer-term
in-band approach.  My approach will work better for webdav, caldav and
other non-HTML-based approaches.  I think my approach may provide a
better user experience even for web pages once it is available.
However the DIX proposal can be deployed with much less effort.  If
both proposals end up using SAML to express information about
identity, they could be complimentary.

I do have some serious questions about whether a redirect-based
approach should be standardized.  I'll ask those questions in another
message.  I'm also talking to people interested in deploying
redirect-based approaches along with those who have done so, trying to
get a more informed opinion.

Any way, I'd like to draw your attention to
draft-hartman-webauth-00.txt.  Let the flames begin.

_______________________________________________
dix mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dix

--=-=-=--

From: Dick Hardt <[email-masked]>
Subject: Re: [Ietf-http-auth] TIPPI Workshop: Trustworthy [User] Interfaces for Passwords and Personal Information
Date: Wed, 7 Jun 2006 14:33:57 -0700
To: Jeff Hodges <[email-masked]>
Cc: IETF HTTP Auth <[email-masked]>

Sounds interesting, unfortunate that it overlaps with the Berkman  
conference in Harvard

http://idmashup.com/wiki/Main_Page

On 7-Jun-06, at 2:30 PM, Jeff Hodges wrote:

> TIPPI Workshop: Trustworthy [User] Interfaces for Passwords and  
> Personal Information
> June 7th, 2006 by JeffH
> http://identitymeme.org/archives/2006/06/07/tippi-workshop- 
> trustworthy-user-interfaces-for-passwords-and-personal-information/
>
> Dan Boneh yesterday announced the open registration (free, as in  
> beer) for the 2nd Annual TIPPI Workshop <http://crypto.stanford.edu/ 
> TIPPI/> at Stanford University. Looks like there is an interesting  
> batch of papers to be presented, which have relevance to recent  
> discussions on the IETF-HTTP-Auth@ mailing list (especially threads  
> during May-2006, e.g. “New draft on anti-phishing requirements”,  
> “BOF proposal”, “BOF Request: WARP - Web Authentication Resistant  
> to Phishing”).
> Technorati Tags: Security, UI, usability, user interface
>
> Posted in Identity, Security, User Interface, Events, Workshops
>
>
>
> _______________________________________________
> Ietf-http-auth mailing list
> [email-masked]
> http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth
>
>

Date: Wed, 07 Jun 2006 14:30:48 -0700
From: Jeff Hodges <[email-masked]>
To: IETF HTTP Auth <[email-masked]>
Subject: [Ietf-http-auth] TIPPI Workshop: Trustworthy [User] Interfaces for Passwords and Personal Information

TIPPI Workshop: Trustworthy [User] Interfaces for Passwords and Personal 
Information
June 7th, 2006 by JeffH
http://identitymeme.org/archives/2006/06/07/tippi-workshop-trustworthy-user-interfaces-for-passwords-and-personal-information/

Dan Boneh yesterday announced the open registration (free, as in beer) for the 
2nd Annual TIPPI Workshop <http://crypto.stanford.edu/TIPPI/> at Stanford 
University. Looks like there is an interesting batch of papers to be presented, 
which have relevance to recent discussions on the IETF-HTTP-Auth@ mailing list 
(especially threads during May-2006, e.g. “New draft on anti-phishing 
requirements”, “BOF proposal”, “BOF Request: WARP - Web Authentication 
Resistant to Phishing”).
Technorati Tags: Security, UI, usability, user interface

Posted in Identity, Security, User Interface, Events, Workshops

To: John Merrells <[email-masked]>
Subject: Re: [Ietf-http-auth] BOF Request: WARP - Web Authentication Resistant to Phishing
From: Sam Hartman <[email-masked]>
Date: Fri, 02 Jun 2006 16:51:51 -0400
Cc: Ted Hardie <[email-masked]>, Digital Identity Exchange <[email-masked]>, [email-masked]

>>>>> "John" = John Merrells <[email-masked]> writes:

    John> I'm not sure if you're saying this but... DIX does not
    John> impose any specific number of identifiers on a user. They
    John> can have as many as they choose to have, from 0 to infinity.

No, but dix does support transporting more than one claim and does
support claims that are not identifiers.

I don't view doing so as a requirement.

    >> but that can transition to more complex forms of identity
    >> claims in the future.  You seem to want sets of identity claims
    >> today.

    John> I find the 'claim' term to be a bit ambiguous, so try to
    John> avoid it.  I'm not sure how claims relate to identifiers in
    John> your comment above.

I use the terms claim, identity, subject and relying party as they are used in the Laws of Identity paper.

An identifier is a claim that is alegidly unique; email addresses are
viewed by some as identifiers.  Email addresses *are* the identifier
within the namespace of amazon.com identifiers as an example.

--Sam

From: John Merrells <[email-masked]>
Subject: Re: [Ietf-http-auth] BOF Request: WARP - Web Authentication Resistant to Phishing
Date: Fri, 2 Jun 2006 13:19:01 -0700
To: Sam Hartman <[email-masked]>
Cc: Ted Hardie <[email-masked]>, Digital Identity Exchange <[email-masked]>, [email-masked]

On 2-Jun-06, at 8:01 AM, Sam Hartman wrote:

> I think we view the requirements somewhat differently or at least view
> what requirements need to be solved when somewhat differently.

Yes, that may well be the case. We're coming at this from a different
angle than you.

> I'm OK with a solution that supports situations where I have a single
> alegidly unique identifier today

I'm not sure if you're saying this but... DIX does not impose any
specific number of identifiers on a user. They can have as many
as they choose to have, from 0 to infinity.

> but that can transition to more
> complex forms of identity claims in the future.  You seem to want sets
> of identity claims today.

I find the 'claim' term to be a bit ambiguous, so try to avoid it.  
I'm not
sure how claims relate to identifiers in your comment above.

The DIX protocol draft specifies how the an attribute value
assertion can be moved between parties... and the assertion
draft shows how those attribute value assertions could actually
be third party attested attribute value assertions.

The benefits are that websites that use common property names
will get more data of better quality and users won't have to deal
with tedious user registration forms.... And... if we can move
around third party assertions (Beth>21) then we have a safer
more productive internet.

> I'm much more interested in reusing existing security technology and
> am not interested in working on entirely new protocols.

Well, we are too. Hence the reuse of SAML/HTML/HTTP/HMAC, etc.
We're just bringing the bits together in such a way that the barrier
to adoption (the really big problem) can be as low as possible.

> (And I do see
> this as a security problem which may also be a difference in how we
> come at this.)

Yes, we're coming at this from a slightly different angle... not that
security isn't important, but we feel that we can provide real value
with just enough security... and show a roadmap of how people
can move up to more security when they need it.

> I consider requirements related to binding things together at multiple
> levels (4.4 in my draft) really critical to forward progress on
> phishing.  A lot of people disagree with me.  One on one I have been
> able to convince people that I'm right, but the text in the current
> section 4.4 clearly does not stand on its own and needs significant
> revision.

I agree with you.

> Finally, I think it critical that whatever solution we have here needs
> to work both with non-web HTTP applications (atompub, caldav, webdav,
> deltav) and with non-HTTP applications.  I'd hate to see people pushed
> towards HTTP as a substrate to get better identity management.

I agree too.

I think the DIX messages could be mapped onto other protocols, or
pushed down into the stack. Our approach though has been to try
to avoid changing any code and any user behaviour. Not easy.

> Needless to say my vision of the solution space is different because I
> view these requirements differently.

Yes.

> I am working on a specific solution proposal to demonstrate that what
> I want to do can be accomplished with incremental changes to existing
> technology.

I'm looking forward to reading that. I hope you get buy in for  
solving the
secure user authentication problem.

John

To: John Merrells <[email-masked]>
Subject: Re: [Ietf-http-auth] BOF Request: WARP - Web Authentication Resistant to Phishing
From: Sam Hartman <[email-masked]>
Date: Fri, 02 Jun 2006 11:01:33 -0400
Cc: Ted Hardie <[email-masked]>, Digital Identity Exchange <[email-masked]>, [email-masked]

Hi, John.  Thanks for the new drafts.  I especially look forward to
the new use cases draft and will sit down to read that after finishing
this reply.

I do agree there is significant overlap; my interest in this area was
more or less directly motivated by the DIX bof and evaluating SXIP,
Infocard and other solutions for a talk I gave at a conference.

I think we view the requirements somewhat differently or at least view
what requirements need to be solved when somewhat differently.

I'm OK with a solution that supports situations where I have a single
alegidly unique identifier today but that can transition to more
complex forms of identity claims in the future.  You seem to want sets
of identity claims today.

I'm much more interested in reusing existing security technology and
am not interested in working on entirely new protocols.  (And I do see
this as a security problem which may also be a difference in how we
come at this.)

I consider requirements related to binding things together at multiple
levels (4.4 in my draft) really critical to forward progress on
phishing.  A lot of people disagree with me.  One on one I have been
able to convince people that I'm right, but the text in the current
section 4.4 clearly does not stand on its own and needs significant
revision.

Finally, I think it critical that whatever solution we have here needs
to work both with non-web HTTP applications (atompub, caldav, webdav,
deltav) and with non-HTTP applications.  I'd hate to see people pushed
towards HTTP as a substrate to get better identity management.

Needless to say my vision of the solution space is different because I
view these requirements differently.

I am working on a specific solution proposal to demonstrate that what
I want to do can be accomplished with incremental changes to existing
technology.

--Sam

From: John Merrells <[email-masked]>
Subject: Re: [Ietf-http-auth] BOF Request: WARP - Web Authentication Resistant to Phishing
Date: Thu, 1 Jun 2006 18:58:36 -0700
To: Sam Hartman <[email-masked]>
Cc: Ted Hardie <[email-masked]>, Digital Identity Exchange <[email-masked]>, [email-masked]

Hello Sam,

I read your webauth-phishing draft. I thought it explored the phishing
problem space really well.

Your BOF request below seems to go further in scope though and
overlaps with what the DIX group have been working on. I'm going
to work through your text calling out the bits where the scope of DIX
and WARP appear to overlap.

[A quick aside. I just published some updated DIX drafts today...
Use Cases, Protocol, and Assertion. They're all available here:
http://dixs.org/index.php/DIX_Protocol_Internet_Drafts]

On 23-May-06, at 2:34 PM, Sam Hartman wrote:

>    WARP is chartered to develop a method for using existing
>    authentication technology to address two critical problems with
>    authentication for the web and other HTTP-using applications.

This is a good thing. With DIX we chose for the actual authentication
of the user to be out of scope. We just focused on how the resultant
authentication assertion would be moved from the Identity Provider
to the Relying Party. (To use SAML terminology.)

> The
>    first problem is  that users must remember and maintain passwords
>    for each HTTP service they use.

The way I'm reading this I think this goes beyond the scope of  
authenticating
the user... perhaps towards identifying the user. In DIX we enable  
third-party
authentication and identify the user with an identifier (a URI...  
typically a URL).

> The second problem is that of
>    phishing.  While browser UIs must change in order to combat the
>    problem of phishing, WARP  must work with these UI changes and must
>    provide clear technical requirements for the security features
>    needed from authentication UI.

Is this in the scope of the IETF though... to provide UI requirements...
to be met by the W3C?

>    WARP will attack the problem of multiple passwords in two ways.
>    First, it will be safe from a security standpoint to use  the same
>    password with multiple HTTP services.    Second, WARP will support
>    the concept of an identity provider, which is a service that
>    clients can authenticate to and that can make assertions about
>    their identity to third parties.

In DIX we term this the Identity Agent, which can be a Website or
an Application.

What kinds of 'assertions about identity' do you mean? I'd assumed
your identity provider would only be generating authentication
assertions. In DIX we support both self asserted and third-party
attribute value assertions. Note that that's not just from the Identity
Provider, but from other Service Providers authoritative for some
attribute of the user.

And to what kinds of third parties?  Thus far I'd assumed that the
only parties involved were the User Agent and the Identity Provider.
I think these are the 'HTTP services' above. Which in DIX is a
Service Provider that consumes the attributes and assertions from
the Identity Agent. Is this what you mean? This bit clearly overlaps
with DIX.

> Employers authenticating their
>    employees to business partners, distributed communities that share
>    a concept of identity and services like Microsoft's Passport  
> service
>    demonstrate the wide variety of identity providers.  There will
>    never be a single identity that a user can use on the web: many
>    users would not choose to use the same identity in a work context
>    that they use personally; similarly business relationships and
>    policies  will dictate what identities services can accept.
>    However WARP will support the concept of identity providers so
>    that when policies permit, users can  minimize the number of
>    identities they use.  WARP must support identity providers
>    associated with servers and should support identity providers that
>    have relationships with users.

This sounds very much like DIX, and Identity 2.0 in general... but
doesn't cover all of Kim's Laws of Identity. You could just reference
that, but I'm concerned you're trying to take on the whole thing,
rather than just tackling a more secure way of authenticating the
user.

>    WARP needs to support mobile users,

'Mobile' equals 'cell phone' to me... a european thing perhaps.
Maybe there's a better word, but I can't think of one.

> including users that use
>    HTTP services from computers they have never used before.  WARP
>    must not require per-service or per-identity-provider
>    configuration.

I don't understand that statement. WARP can be deployed without
changing any service or IdP code/configuration?

> While WARP is focused on passwords as that is
>    expected to be the primary means  of authentication, WARP needs
>    to support other credentials including smart cards, one-time
>    passwords and zero-knowledge password protocols.

That's all good.

> It is
>    desirable that WARP be able to carry assertions about identity such
>    as Security Assertion Markup Language assertions.

But, is this DIX again. What are the assertions about and where are
the coming from and going to. I'm suspecting they're any assertion and
they're coming from the IdP to the SP. DIX covers that with more
flexibility... in that roles of the IdP are separated out.

>    The WARP working group will first write a problem statement and a
>    requirements draft describing what it means to produce an
>    authentication solution that is resistant to phishing.  Then WARP
>    will choose a mandatory-to-implement authentication technology

That's good.

> and
>    protocol for the interaction between the identity provider and
>    website.

I think this is DIX...

>     WARP will coordinate with W3C  in working on the UI  
> implications of
>    phishing.    WARP will not propose specific UI nor specific
>    extensions to HTML, although WARP may  recommend requirements for
>    both as these requirements directly impact the security or
>    deployability of WARP.

I'm not sure how this will work in practice. I'd image the W3C would
want to define their own UI/HTML requirements... but I'm sure they'd
welcome input if the group generates some requirements as a
side-effect of the work.

> Deliverables:
>
> * Problem statement for WARP
>
> * Requirements for authentication resistant to phishing
>
> *  WARP protocol document describing how an existing authentication
>    system  is used  to meet the requirements of WARP.  This document
>    may specify mandatory to implement modes in addition to those
>    specified in the underlying system.

I read this as WARP does 'authentication resistant to phishing', and
I don't think that covers a protocol from the identity provider to the
website.

> * A proposed standard describing how an identity is registered  with
>   an identity provider or website.

What does that mean? Maybe I just need more detail. But why an
'or' in 'identity provider or website'...

In DIX a User Identifier is either assigned by the Identity Agent, or
the user delegates authentication of an existing URL to an Identity
Agent. And a Service Provider has a range of options over whether
the User needs to identify themselves or not. There are privacy
benefits to the SP being able to offer a service without actually
having to create an 'account'.

> * A proposed standard describing how an identity associated with a
>   user is linked to an HTTP service's concept of an account.

Sounds much like the 'or website' bit above. But again... DIX
does this... and is set up so that you don't need to.

In summary:

I think there's lots of value in WARP for dealing with authentication
of the user to the identity provider... but if you go beyond that from
the identity provider to the website then you're coving the scope
of DIX... which in-my-not-so-humble-opinion has thought through
and dealt with all these issues already and more besides.

I think that if the scope of the work can be tightened up and there
are people interested in working on this that it'll be a great
complement to the DIX work.

John