Subject: [Ietf-http-auth] DRAFT: WAE BOF minutes
From: Dick Hardt <[email-masked]>
To: Digital Identity Exchange <[email-masked]>, IETF HTTP Auth <[email-masked]>
Date: Sat, 15 Jul 2006 13:38:04 -0400
List-Id: ietf-http-auth.osafoundation.org

The meeting started off with the usual agenda review. Agenda was  
accepted as proposed.

The first item was Terminology.
Reading assignment: read RFC 2828
	Internet Security Glossary
	http://www.ietf.org/rfc/rfc2828.txt
Other Glossaries mentioned:
	Internet Security Glossary, Version 2
	http://www.ietf.org/internet-drafts/draft-shirey-secgloss-v2-04.txt

	SAMLv2: Glossary
	http://docs.oasis-open.org/security/saml/v2.0/saml-glossary-2.0-os.pdf

	"identity gang" lexicon
	http://identitygang.org/Lexicon

The next item was Problems we want to solve (see agenda)
A few things were added:
	- whitelisting
	- claim minimality
	- proof of server identity

Sam Hartman made his presentation, there were a few questions.

There was then discussion on Problems we want to solve.
****** edit here -- right title? same as before

Additional problems
	non-browsing HTTP support
	support for existing infrastructure
	Cross Application Credential (XAC)

Grouping of problems was then started.
Dick Hardt's slide was presented.

Ekr proposed grouping the problem up as:

EKR1: fix http auth
	- anti-phishing
	- passwords and other

EKR2: cross-site identity, Eliot's dad, SSO

EKR3: Claim & Attribute Transferral

More detailed discussion on each problem then ensued:

EKR1: Fix HTTP Auth
AD questions to audience concluded with:
	- Liaise w/ W3C on GUI
	- Liaise w/ APWG
	- Layer / Arch TBD
	- can stand alone, but coordinate w/ EKR2 and EKR3
	EKR1 does not require EKR2

EKR2: cross-site identifier
(Eliot's dad problem was broken off to be EKR4)
	- raw assertions of identity are easier to trust than attributes
	- name subordination
	- existing technology, but glue work
	Question: Is there glue work to be done by the IETF?
			- no one thinks there is no glue work, 15 think there is, 15 are  
not sure
	12 ok on work if EKR1 not happening,

EKR3:Claim & Attribute Transferral
	- existing claims and syntaxes may be used
	- binds attribute assertions to underlying communication
	- not limited to HTTP
	Question: Is there glue work to be done here by the IETF?
	12 support, a couple object

EKR4:
	- eliot's dad problem
	part of EKR1 & EKR 2

Discussion if EKR1 and EKR2 required different BOFs at next IETF  
meeting. Clearly different drafts would be required. Best to combine  
group working on them.

Meeting concluded 15 minutes late.

Date: Sat, 15 Jul 2006 10:05:40 -0400
From: "Ben Laurie" <[email-masked]>
To: "Digital Identity Exchange" <[email-masked]>
Cc: IETF HTTP Auth <[email-masked]>
Subject: [Ietf-http-auth] Re: [dix] More requirements

On 7/15/06, Paul Gleichauf <[email-masked]> wrote:
> I have missed significant parts of this thread, but is there
> assurance that these are in fact computationally feasible?
>
> There are cases where such guarantees are often found possible to
> break in unanticipated ways. Recently the focus is on medical records
> and the ability to identify a specific person in a large population
> when an anonymization algorithm had been appropriately applied by
> correlating data from a variety of sources.  Below is one set of
> citations often cross referenced in this area:
>
> http://lab.privacy.cs.cmu.edu/people/sweeney/confidentiality.html

I explicitly stated that these kinds of attacks were out of scope. I'm
talking about the avoidable kind of linkage, for example where you
present the same X.509 client cert everywhere.

>
> Paul
>
> On Jul 13, 2006, at 5:43 PM, Ben Laurie wrote:
>
> > On the plane to IETF I realised that there were several more potential
> > requirements to add to ekr's list:
> >
> > 12. Single Site Unlinkability (SSU)
> > The user should be able to visit the same site multiple times without
> > the site being able to tell that it is the same user, even if the user
> > is, for example, asserting the same external claims each time. This
> > protects the user's privacy. Obviously if data provided by the user is
> > unique to that user (for example, age and address combined are often
> > sufficient to uniquely identify a person) then no amount of cleverness
> > can provide SSU, but SSU should be available to the extent permitted
> > by the uniqueness of the data provided.
> >
> > 13. Multiple Site Unlinkability (MSU)
> > The user should be able to visit multiple sites without the sites
> > being able to collude to correlate the data provided by the user. This
> > is a weaker requirement than SSU (that is, MSU does not guarantee
> > SSU). Again, this protects the user's privacy.
> >
> > 14. Attack Resistant Credentials (ARC)
> > Credentials should be such that the (computationally limited) verifier
> > cannot reconstruct the original credential by brute force. Note that
> > the impossibility of this may rely on the user choosing strong
> > secrets, which is often unlikely, for example where the sole source of
> > entropy is a password.
> >
> > 15. Claim Minimality (CM)
> > The ability to show only exactly what is needed, (for example, the
> > user is over 21 rather than the user's exact age, or if there are
> > mutlple claims the ability to show a subset). This improves privacy
> > and reduces linkability.
> >
> > _______________________________________________
> > dix mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/dix
>
> _______________________________________________
> dix mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dix
>

Date: Fri, 14 Jul 2006 10:36:55 -0400 (EDT)
From: "RL 'Bob' Morgan" <[email-masked]>
To: Digital Identity Exchange <[email-masked]>
Cc: IETF HTTP Auth <[email-masked]>
Subject: [Ietf-http-auth] Re: [dix] Extant Applicable Security Glossaries

Also, the "identity gang" lexicon:

   http://identitygang.org/Lexicon

  - RL "Bob"

On Fri, 14 Jul 2006, Jeff Hodges wrote:

> Here's pointers to hopefully useful glossaries...
>
> HTH,
>
> JeffH
> -----
>
>
> Internet Security Glossary
> http://www.ietf.org/rfc/rfc2828.txt
>
>
> Internet Security Glossary, Version 2
> http://www.ietf.org/internet-drafts/draft-shirey-secgloss-v2-04.txt
>
>
> SAMLv2: Glossary
> http://docs.oasis-open.org/security/saml/v2.0/saml-glossary-2.0-os.pdf
>
>
> Liberty Technical Glossary v2-05
> http://www.projectliberty.org/specs/draft-liberty-glossary-v2.0-05.pdf
>
>
>
> Note that all of the above have extensive references to the work they are 
> built upon. Also note that the SAMLv2 and Liberty glossaries are examples of 
> going through the exercise of "profiling"/"reusing" existing terminology for 
> use within a particular context, SAMLv2 being particularly relevant to the 
> WAE discussion.
>
> Also worthwhile to point out is Lynn Wheeler's overall glossary, which 
> composes the widest collection of extant glossaries that I know of, so it is 
> particularly useful for figuring out how various constituencies are using any 
> particular term (or whether they are using it at all)
>
>
> http://www.garlic.com/~lynn/secure.htm
>
> Note that the references for Lynn's sec gloss are listed on the page "above" 
> the gloss...
>
> http://www.garlic.com/~lynn/
>
>
> ---
> end
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> dix mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dix
>

Date: Fri, 14 Jul 2006 07:34:02 -0700
From: Jeff Hodges <[email-masked]>
To: Digital Identity Exchange <[email-masked]>, IETF HTTP Auth <[email-masked]>
Subject: [Ietf-http-auth] Extant Applicable Security Glossaries

Here's pointers to hopefully useful glossaries...

HTH,

JeffH
-----

Internet Security Glossary
http://www.ietf.org/rfc/rfc2828.txt

Internet Security Glossary, Version 2
http://www.ietf.org/internet-drafts/draft-shirey-secgloss-v2-04.txt

SAMLv2: Glossary
http://docs.oasis-open.org/security/saml/v2.0/saml-glossary-2.0-os.pdf

Liberty Technical Glossary v2-05
http://www.projectliberty.org/specs/draft-liberty-glossary-v2.0-05.pdf

Note that all of the above have extensive references to the work they are built 
upon. Also note that the SAMLv2 and Liberty glossaries are examples of going 
through the exercise of "profiling"/"reusing" existing terminology for use 
within a particular context, SAMLv2 being particularly relevant to the WAE 
discussion.

Also worthwhile to point out is Lynn Wheeler's overall glossary, which composes 
the widest collection of extant glossaries that I know of, so it is 
particularly useful for figuring out how various constituencies are using any 
particular term (or whether they are using it at all)

http://www.garlic.com/~lynn/secure.htm

Note that the references for Lynn's sec gloss are listed on the page "above" 
the gloss...

http://www.garlic.com/~lynn/

---
end

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-http-auth] WAE topic/problem scope (was: Stab at grouping of problem (was: Re: [dix] Agenda bashing))
Date: Fri, 14 Jul 2006 09:54:44 -0400
To: Jeff Hodges <[email-masked]>
Cc: Digital Identity Exchange <[email-masked]>, IETF HTTP Auth <[email-masked]>

The outcome of WAE could be 0, 1 or more WGs.  The conflation in the  
BoF does not necessarily mean conflation in WG(s).  The breakdown is  
appreciated.

Lisa

On Jul 13, 2006, at 11:59 PM, Jeff Hodges wrote:

> Just to attempt to help clarify, in my understanding WAE was begot  
> by the conflation of three topic areas..
>
>  1. in-protocol authentication (for HTTP)
>
>     e.g. that which is defined within the HTTP spec set itself and is
>     used by an HTTP client to authn directly with an HTTP server.  
> Presently
>     the two available mechanisms are Basic and Digest. There are  
> use cases,
>     eg CalDAV, that would ostensibly benefit from a wider range of
>     in-protocol HTTP authn mechanisms. My understanding is that  
> this was the
>     motivation for creating the ietf-http-auth@ list.
>
>
>  2. application-level authentication/SSO and attribute sharing (for  
> HTTP-based
>     web-oriented (eg portal-based) apps)
>
>     This is a well-trod area with a plethora of existing solution  
> approaches
>     which are deployed to varying extents: SAML web sso profiles,  
> Liberty
>     ID-FF, Shib, OpenID, SXIP(/DIX), LID, WS-Federation, RoboForm,  
> etc. The
>     primary reason this topic is on the table in this venue is a  
> perception
>     that perhaps "more" can be done in order to facilitate wider  
> and more quick
>     adoption amongst websites in the wider Internet, eg "the  
> blogosphere".
>     This was the motivation for creation of the dix@ list.
>
>
>  3. anti-phishing
>
>     The motivation why this is on the list is obvious.
>     Effective overall solutions will involve a large component of user
>     interface (UI) approaches. Some would argue that the UI aspects  
> are the
>     first-order ones (and this is not a typical IETF problem  
> domain). Though
>     as well as UI, any solutions will likely rely on capabilities/ 
> properties
>     obtained from solutions to 1 and/or 2 above, and may require  
> specific
>     capabilities/properties that 1 and/or 2 don't otherwise provide.
>
>
> At this point, it isn't clear to me that the WAE BoF represents  
> just one overall "problem" to solve. Each of these are large  
> distinct topic areas in their own right, though they do intersect.  
> It will be a challenge to not short-shrift one or more of them. It  
> should be an entertaiing discussion.
>
>
> JeffH
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Ietf-http-auth mailing list
> [email-masked]
> http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth

Date: Fri, 14 Jul 2006 09:51:11 -0400 (EDT)
From: "RL 'Bob' Morgan" <[email-masked]>
To: Jeff Hodges <[email-masked]>
Subject: Re: [dix] Re: [Ietf-http-auth] More requirements
Cc: Digital Identity Exchange <[email-masked]>, IETF HTTP Auth <[email-masked]>

> Indeed, many of these are distinct "security properties". Note in the intro 
> to his note, ekr termed the content of his note as:
>
>  "a taxonomy of requirements/features and technical options"

Right, a problem we often have with stating requirements is 
differentiating between "X is required to be possible/negotiable" and "X 
is required to always be done"; where the first of these produces 
derivative requirements about the nature of the negotiation of and/or 
policy around the feature.

  - RL "Bob"

Date: Fri, 14 Jul 2006 06:30:03 -0700
From: Jeff Hodges <[email-masked]>
To: Digital Identity Exchange <[email-masked]>
Subject: Re: [dix] Re: [Ietf-http-auth] More requirements
Cc: IETF HTTP Auth <[email-masked]>

RL 'Bob' Morgan wrote:
 >
 > I think many of the requirements (no, haven't made a list yet) have the
 > assumption of "when appropriate", or "when desired", where "desired" is
 > some combination of what the user wants and what the application wants
 > or will permit.

Indeed, many of these are distinct "security properties". Note in the intro to 
his note, ekr termed the content of his note as:

   "a taxonomy of requirements/features and technical options"

JeffH

Date: Fri, 14 Jul 2006 08:39:54 -0400
From: "Ben Laurie" <[email-masked]>
To: "RL 'Bob' Morgan" <[email-masked]>
Subject: Re: [dix] Re: [Ietf-http-auth] More requirements
Cc: Digital Identity Exchange <[email-masked]>, IETF HTTP Auth <[email-masked]>

On 7/14/06, RL 'Bob' Morgan <[email-masked]> wrote:
>
> >> 12. Single Site Unlinkability (SSU)
> >> The user should be able to visit the same site multiple times without
> >> the site being able to tell that it is the same user, even if the user
> >> is, for example, asserting the same external claims each time. This
> >> protects the user's privacy. Obviously if data provided by the user is
> >> unique to that user (for example, age and address combined are often
> >> sufficient to uniquely identify a person) then no amount of cleverness
> >> can provide SSU, but SSU should be available to the extent permitted
> >> by the uniqueness of the data provided.
> >
> > This is an interesting requirement and obviously of value, but
> > it's worth noting that there are contexts in which linkability
> > (CI) is precisely what's desired--blog comments, for example.
> >
> > So, you wouldn't want to design a system that always provided SSU. :)
>
> I think many of the requirements (no, haven't made a list yet) have the
> assumption of "when appropriate", or "when desired", where "desired" is
> some combination of what the user wants and what the application wants or
> will permit.

Yeah, I see the list as being a list of things you might want, at this
stage. Presumably at some point we have to choose which things we
actually want, and which are optional or not-always-used.

>
>   - RL "Bob"
>
>

Date: Fri, 14 Jul 2006 08:38:55 -0400 (EDT)
From: "RL 'Bob' Morgan" <[email-masked]>
To: EKR <[email-masked]>, Digital Identity Exchange <[email-masked]>
Subject: Re: [dix] Re: [Ietf-http-auth] More requirements
Cc: IETF HTTP Auth <[email-masked]>

>> 12. Single Site Unlinkability (SSU)
>> The user should be able to visit the same site multiple times without
>> the site being able to tell that it is the same user, even if the user
>> is, for example, asserting the same external claims each time. This
>> protects the user's privacy. Obviously if data provided by the user is
>> unique to that user (for example, age and address combined are often
>> sufficient to uniquely identify a person) then no amount of cleverness
>> can provide SSU, but SSU should be available to the extent permitted
>> by the uniqueness of the data provided.
>
> This is an interesting requirement and obviously of value, but
> it's worth noting that there are contexts in which linkability
> (CI) is precisely what's desired--blog comments, for example.
>
> So, you wouldn't want to design a system that always provided SSU. :)

I think many of the requirements (no, haven't made a list yet) have the 
assumption of "when appropriate", or "when desired", where "desired" is 
some combination of what the user wants and what the application wants or 
will permit.

  - RL "Bob"

Date: Fri, 14 Jul 2006 08:38:18 -0400
From: "Ben Laurie" <[email-masked]>
To: EKR <[email-masked]>
Subject: Re: [Ietf-http-auth] More requirements
Cc: Digital Identity Exchange <[email-masked]>, IETF HTTP Auth <[email-masked]>

On 7/14/06, EKR <[email-masked]> wrote:
> "Ben Laurie" <[email-masked]> writes:
>
> > On the plane to IETF I realised that there were several more potential
> > requirements to add to ekr's list:
> >
> > 12. Single Site Unlinkability (SSU)
> > The user should be able to visit the same site multiple times without
> > the site being able to tell that it is the same user, even if the user
> > is, for example, asserting the same external claims each time. This
> > protects the user's privacy. Obviously if data provided by the user is
> > unique to that user (for example, age and address combined are often
> > sufficient to uniquely identify a person) then no amount of cleverness
> > can provide SSU, but SSU should be available to the extent permitted
> > by the uniqueness of the data provided.
>
> This is an interesting requirement and obviously of value, but
> it's worth noting that there are contexts in which linkability
> (CI) is precisely what's desired--blog comments, for example.
>
> So, you wouldn't want to design a system that always provided
> SSU. :)

Totally agreed.

> > 15. Claim Minimality (CM)
> > The ability to show only exactly what is needed, (for example, the
> > user is over 21 rather than the user's exact age, or if there are
> > mutlple claims the ability to show a subset). This improves privacy
> > and reduces linkability.
>
> Note that this ties in with IAC.

Right - the distinction is that rather than merely separating claims
you want to be able to prove properties of claims instead of revealing
their actual content.

>
> -Ekr
>
>
>

To: "Ben Laurie" <[email-masked]>
Subject: Re: [Ietf-http-auth] More requirements
From: EKR <[email-masked]>
Date: Fri, 14 Jul 2006 05:03:26 -0700
Cc: Digital Identity Exchange <[email-masked]>, IETF HTTP Auth <[email-masked]>
Reply-To: EKR <[email-masked]>

"Ben Laurie" <[email-masked]> writes:

> On the plane to IETF I realised that there were several more potential
> requirements to add to ekr's list:
>
> 12. Single Site Unlinkability (SSU)
> The user should be able to visit the same site multiple times without
> the site being able to tell that it is the same user, even if the user
> is, for example, asserting the same external claims each time. This
> protects the user's privacy. Obviously if data provided by the user is
> unique to that user (for example, age and address combined are often
> sufficient to uniquely identify a person) then no amount of cleverness
> can provide SSU, but SSU should be available to the extent permitted
> by the uniqueness of the data provided.

This is an interesting requirement and obviously of value, but
it's worth noting that there are contexts in which linkability
(CI) is precisely what's desired--blog comments, for example.

So, you wouldn't want to design a system that always provided
SSU. :)

> 15. Claim Minimality (CM)
> The ability to show only exactly what is needed, (for example, the
> user is over 21 rather than the user's exact age, or if there are
> mutlple claims the ability to show a subset). This improves privacy
> and reduces linkability.

Note that this ties in with IAC.

-Ekr

Date: Thu, 13 Jul 2006 20:59:50 -0700
From: Jeff Hodges <[email-masked]>
To: Digital Identity Exchange <[email-masked]>
Cc: IETF HTTP Auth <[email-masked]>
Subject: [Ietf-http-auth] WAE topic/problem scope (was: Stab at grouping of problem (was: Re: [dix] Agenda bashing))

Just to attempt to help clarify, in my understanding WAE was begot by the 
conflation of three topic areas..

  1. in-protocol authentication (for HTTP)

     e.g. that which is defined within the HTTP spec set itself and is
     used by an HTTP client to authn directly with an HTTP server. Presently
     the two available mechanisms are Basic and Digest. There are use cases,
     eg CalDAV, that would ostensibly benefit from a wider range of
     in-protocol HTTP authn mechanisms. My understanding is that this was the
     motivation for creating the ietf-http-auth@ list.

  2. application-level authentication/SSO and attribute sharing (for HTTP-based
     web-oriented (eg portal-based) apps)

     This is a well-trod area with a plethora of existing solution approaches
     which are deployed to varying extents: SAML web sso profiles, Liberty
     ID-FF, Shib, OpenID, SXIP(/DIX), LID, WS-Federation, RoboForm, etc. The
     primary reason this topic is on the table in this venue is a perception
     that perhaps "more" can be done in order to facilitate wider and more quick
     adoption amongst websites in the wider Internet, eg "the blogosphere".
     This was the motivation for creation of the dix@ list.

  3. anti-phishing

     The motivation why this is on the list is obvious.
     Effective overall solutions will involve a large component of user
     interface (UI) approaches. Some would argue that the UI aspects are the
     first-order ones (and this is not a typical IETF problem domain). Though
     as well as UI, any solutions will likely rely on capabilities/properties
     obtained from solutions to 1 and/or 2 above, and may require specific
     capabilities/properties that 1 and/or 2 don't otherwise provide.

At this point, it isn't clear to me that the WAE BoF represents just one 
overall "problem" to solve. Each of these are large distinct topic areas in 
their own right, though they do intersect. It will be a challenge to not 
short-shrift one or more of them. It should be an entertaiing discussion.

JeffH

Date: Thu, 13 Jul 2006 20:43:14 -0400
From: "Ben Laurie" <[email-masked]>
To: "Digital Identity Exchange" <[email-masked]>, "IETF HTTP Auth" <[email-masked]>
Subject: [Ietf-http-auth] More requirements

On the plane to IETF I realised that there were several more potential
requirements to add to ekr's list:

12. Single Site Unlinkability (SSU)
The user should be able to visit the same site multiple times without
the site being able to tell that it is the same user, even if the user
is, for example, asserting the same external claims each time. This
protects the user's privacy. Obviously if data provided by the user is
unique to that user (for example, age and address combined are often
sufficient to uniquely identify a person) then no amount of cleverness
can provide SSU, but SSU should be available to the extent permitted
by the uniqueness of the data provided.

13. Multiple Site Unlinkability (MSU)
The user should be able to visit multiple sites without the sites
being able to collude to correlate the data provided by the user. This
is a weaker requirement than SSU (that is, MSU does not guarantee
SSU). Again, this protects the user's privacy.

14. Attack Resistant Credentials (ARC)
Credentials should be such that the (computationally limited) verifier
cannot reconstruct the original credential by brute force. Note that
the impossibility of this may rely on the user choosing strong
secrets, which is often unlikely, for example where the sole source of
entropy is a password.

15. Claim Minimality (CM)
The ability to show only exactly what is needed, (for example, the
user is over 21 rather than the user's exact age, or if there are
mutlple claims the ability to show a subset). This improves privacy
and reduces linkability.

To: Digital Identity Exchange <[email-masked]>, IETF HTTP Auth <[email-masked]>
From: Dick Hardt <[email-masked]>
Date: Thu, 13 Jul 2006 19:31:40 -0400
Subject: [Ietf-http-auth] Stab at grouping of problem

After a number of hallway conversations I came to the following view=20=20
on the breaking down the problem and the desirable features:
(I reference Ekr's labels where applicable for sake of brevity,=20=20
included below for convenience)

1A) Phishing of Account credentials - bad guy getting account name=20=20
and password
Desirable solution features are:
	Ekr=92s CRC, HRA, PC?, CUC, CI?  (I am not certain on PC and CI)

1B) Phishing of Identity attributes - bad guy getting personal=20=20
identifying information
Desirable solution features are:
	i) Certainty of website identity (a factor in above, but since the=20=20
user may not have authenticated, it is different)
	ii) Secure channel to prevent eavesdropping (solved today with SSL/TLS)

2) Software Assisted Attribute Exchange - this is having software=20=20
assist the user in the acquisition and presentation of identity=20=20
attributes. The messages to do this include: request, response, store.
Desirable solution features are:
	Ekr=92s FPI, CI?, UFN?, AEC, IAC, PA

-- Dick

----------------

	From: 	  [email-masked]
	Subject: 	[Ietf-http-auth] Notes on Web authentication enhancements
	Date: 	June 19, 2006 2:59:29 PM PDT (CA)
	To: 	  [email-masked], [email-masked]

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.

Content-class: urn:content-classes:message
Subject: RE: [dix] Re: [Ietf-http-auth] Notes on Web authenticationenhancements
Date: Tue, 11 Jul 2006 15:11:12 -0700
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Dick Hardt" <[email-masked]>
Cc: Digital Identity Exchange <[email-masked]>, [email-masked], Sam Hartman <[email-masked]>

> From: Dick Hardt [mailto:[email-masked]]=20

> Just to clarify, phishers are spoofing Google and Blogger to=20
> steal credentials? If so, I stand corrected.

Not in production yet.

However there are malware companies that use blogger for distributing =
trojans. It is a small step from that to phish credentials of blogger =
sites and drop hardcore crimeware onto machines that visit.

From: Dick Hardt <[email-masked]>
Subject: Re: [dix] Re: [Ietf-http-auth] Notes on Web authenticationenhancements
Date: Tue, 11 Jul 2006 10:53:46 -0700
To: "Hallam-Baker, Phillip" <[email-masked]>
Cc: Digital Identity Exchange <[email-masked]>, [email-masked], Sam Hartman <[email-masked]>

On 7-Jul-06, at 1:06 PM, Hallam-Baker, Phillip wrote:

>
>> [mailto:[email-masked]] On Behalf
>
>> 1) Most sites are not targeted by phishers today, and
>> unlikely to be targeted in the future, so they should not be
>> forced to put in technology for resolving phishing.
>
> This is completely wrong.
>
> Every type of site is targetted by criminal schemes, blogs are  
> currently targets for spam and for dropping trojans onto user  
> machine via spyware.
>
> If I can get hold of a blogger's username and password I can  
> install a trojan dropper onto their site. Blogger has been infested  
> with hundreds of thousands of sites with music backgrounds provided  
> by spyware companies.
>
> There are already extensive attacks against search engines. If you  
> can see the searches someone has done recently you can quickly  
> build up a picture to use in an identity theft.

Just to clarify, phishers are spoofing Google and Blogger to steal  
credentials? If so, I stand corrected.

>
>> 2) Currently the user has NO trusted site or client and is
>> easily phished. Once the user has one trusted software
>> system, then that system can more easily determine the
>> identity of other sites. In other words, the user will not
>> have to build up the full assurance stack with each site, the
>> user can leverage something they already trust to assist in
>> making the trust decision.
>
> The problem is not a lack of trusted sites, it is a lack of sites  
> that are trustWORTHY.

Agreed. Semantics is not one of my stronger skills. :-)

Content-class: urn:content-classes:message
Subject: RE: [dix] Re: [Ietf-http-auth] Notes on Web authenticationenhancements
Date: Fri, 7 Jul 2006 13:06:34 -0700
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Dick Hardt" <[email-masked]>, "Sam Hartman" <[email-masked]>
Cc: Digital Identity Exchange <[email-masked]>, [email-masked]

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

> 1) Most sites are not targeted by phishers today, and=20
> unlikely to be targeted in the future, so they should not be=20
> forced to put in technology for resolving phishing.

This is completely wrong.

Every type of site is targetted by criminal schemes, blogs are currently =
targets for spam and for dropping trojans onto user machine via spyware.

If I can get hold of a blogger's username and password I can install a =
trojan dropper onto their site. Blogger has been infested with hundreds =
of thousands of sites with music backgrounds provided by spyware =
companies.=20

There are already extensive attacks against search engines. If you can =
see the searches someone has done recently you can quickly build up a =
picture to use in an identity theft.

> 2) Currently the user has NO trusted site or client and is=20
> easily phished. Once the user has one trusted software=20
> system, then that system can more easily determine the=20
> identity of other sites. In other words, the user will not=20
> have to build up the full assurance stack with each site, the=20
> user can leverage something they already trust to assist in=20
> making the trust decision.

The problem is not a lack of trusted sites, it is a lack of sites that =
are trustWORTHY.

From: Sam Hartman <[email-masked]>
To: Dick Hardt <[email-masked]>
Subject: Re: [dix] Re: [Ietf-http-auth] Notes on Web authentication enhancements
Date: Fri, 07 Jul 2006 10:19:23 -0400
Cc: Digital Identity Exchange <[email-masked]>, [email-masked]

>>>>> "Dick" == Dick Hardt <[email-masked]> writes:

    Dick> 1) Most sites are not targeted by phishers today, 
and
Agreed.

    Dick> unlikely to be targeted in the future, so they should not be
    Dick> forced to put in technology for resolving phishing.

Disagree.  As you start to see reuse of identity, you will see people
moving from targeting primary targets to targeting other sites where
credentials may be harvested.

I think anyone who accepts identity information will ultimately be a
target.

    Dick> 2) Currently the user has NO trusted site or client and is
    Dick> easily phished. Once the user has one trusted software
    Dick> system, then that system can more easily determine the
    Dick> identity of other sites. In other words, the user will not
    Dick> have to build up the full assurance stack with each site,
    Dick> the user can leverage something they already trust to assist
    Dick> in making the trust decision.

I more or less completely disagree with the above, especially with the
idea that the user will ever have one trusted software system.

From: Dick Hardt <[email-masked]>
Subject: Re: [dix] Re: [Ietf-http-auth] Notes on Web authentication enhancements
Date: Thu, 6 Jul 2006 21:32:53 -0700
To: Sam Hartman <[email-masked]>
Cc: Digital Identity Exchange <[email-masked]>, [email-masked]

On 6-Jul-06, at 12:56 PM, Sam Hartman wrote:

>>>>>> "Dick" == Dick Hardt <[email-masked]> writes:
>
>     Dick> Agreed. My point is that it is much easier to solve it in
>     Dick> one place then on all sites. The IdP can become a
>     Dick> combination of client side and server side code to deal much
>     Dick> more effectively with the phishing issue. It is unreasonable
>     Dick> for every site to do that.
>
> I'm missing something here.  Long term, it seems like all the clients
> are going to need to change so that they can interact with the new
> IDPs.  Long term, the servers are definitely going to need to change
> so they can accept information from the IDPs.  I don't see why it is
> unreasonable to solve this on all sites long-term.  In fact, I believe
> we're going to have to in order to deal with my requirement 4.4
> (mutual authentication).  And yes, I think that requirement is really
> important because without it, you don't have assurance that you aren't
> giving personal information to the wrong party--you don't have
> assurance that you aren't being phished.

I'll see if I can clarify:

1) Most sites are not targeted by phishers today, and unlikely to be  
targeted in the future, so they should not be forced to put in  
technology for resolving phishing.

2) Currently the user has NO trusted site or client and is easily  
phished. Once the user has one trusted software system, then that  
system can more easily determine the identity of other sites. In  
other words, the user will not have to build up the full assurance  
stack with each site, the user can leverage something they already  
trust to assist in making the trust decision.

>
>
> I think the question we should be asking in this space is whether
> there is something we can do in short-to-medium term that has
> acceptable intermediate security.  A quetion you're presumably
> interested in is whether DIX or something close to it would be such a
> something.

Agree that we need to work on a a short-to-medium term improvement.
Phishing, like most complex problems, likely requires a combination  
of things to minimize.
Per my comments above, once the user has a trusted identity agent,  
DIX could be used by the user to interact in a more trusted manner  
with other sites, with a lower burden on those sites.

>
> I don't know what my answer to that question is.  I hope to have
> decided by the end of the BOF.

I think the BOF is going to be interesting -- uncertain on what will  
be answered. :)

-- Dick

From: Sam Hartman <[email-masked]>
To: EKR <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: [dix] Notes on Web authentication enhancements
Date: Thu, 06 Jul 2006 18:31:21 -0400
Cc: Digital Identity Exchange <[email-masked]>, [email-masked]

>>>>> "Eric" == Eric Rescorla <[email-masked]> writes:

    Eric> Sam Hartman <[email-masked]> writes:
    >>>>>>> "Eric" == Eric Rescorla <[email-masked]> writes:
    >>
    Eric> Sorry, I don't see what you're getting at. PwdHash is
    Eric> specified to use the domain name of the server as the hash
    Eric> salt. RFC 2818 requires that that domain name match the
    Eric> server's certificate. There's nothing additional required.
    >>  The additional thing is that the specification of pwdhash uses
    >> the same naming for servers that tls does and that as pwdhash
    >> is used, it derives the name of the server it is contacting
    >> from the same place as TLS (the URI).

    Eric> Yes, I agree that this is necessary. I don't agree that it's
    Eric> "additional". It's a basic part of any design that aims to
    Eric> preserve referential integrity, which is why TLS and PwdHash
    Eric> both do it.

OK.  It was not obvious in your definition of CRA that you meant this.

I thin my major conclusion from WEA so far is that reasonably
intelligent people who have been thinking about these problems for
years still find it difficult to agree on common vocabulary.
Requirements and solutions are harder.

To: Sam Hartman <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: [dix] Notes on Web authentication enhancements
From: Eric Rescorla <[email-masked]>
Date: Thu, 06 Jul 2006 15:03:15 -0700
Cc: Digital Identity Exchange <[email-masked]>, [email-masked]
Reply-To: EKR <[email-masked]>

Sam Hartman <[email-masked]> writes:

>>>>>> "Eric" == Eric Rescorla <[email-masked]> writes:
>
>     Eric> Sorry, I don't see what you're getting at. PwdHash is
>     Eric> specified to use the domain name of the server as the hash
>     Eric> salt. RFC 2818 requires that that domain name match the
>     Eric> server's certificate. There's nothing additional required.
>
> The additional thing is that the specification of pwdhash uses the
>         same naming for servers that tls does and that as pwdhash is
>         used, it derives the name of the server it is contacting from
>         the same place as TLS (the URI).

Yes, I agree that this is necessary. I don't agree that it's
"additional". It's a basic part of any design that aims
to preserve referential integrity, which is why TLS and
PwdHash both do it.

> Say I replace pwdhash with an authentication scheme where the client
> needs to learn from the user an identity for the server to be used at
> the TLS layer (the domain name from the URI) and an identity to be
> used for my upper layer authentication scheme (derived somewhere
> else).
>
> For example, SASL digest effectively names the server based on a
> realm.  There's no good mapping between the server's domain name and
> the realm.  So, I'm fairly certain that a server could trick you into
> giving it a challenge to replay with another server.
>
> I think HTTP digest works approximately the same way.
> In this situation, TLS would not be enough to prevent MITM.
>
> Although perhaps the difference here is that I was using a broader
> definitiong of hi jacking than you were and my definition included
> MITM.

Uh, no. The difference is that HTTP Digest and SASL Digest don't
provide CRA, because they don't include the user's intended
URI in the C-R response.

-Ekr

From: Sam Hartman <[email-masked]>
To: EKR <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: [dix] Notes on Web authentication enhancements
Date: Thu, 06 Jul 2006 16:40:46 -0400
Cc: Digital Identity Exchange <[email-masked]>, [email-masked]

>>>>> "Eric" == Eric Rescorla <[email-masked]> writes:

    Eric> Sorry, I don't see what you're getting at. PwdHash is
    Eric> specified to use the domain name of the server as the hash
    Eric> salt. RFC 2818 requires that that domain name match the
    Eric> server's certificate. There's nothing additional required.

The additional thing is that the specification of pwdhash uses the
        same naming for servers that tls does and that as pwdhash is
        used, it derives the name of the server it is contacting from
        the same place as TLS (the URI).

Say I replace pwdhash with an authentication scheme where the client
needs to learn from the user an identity for the server to be used at
the TLS layer (the domain name from the URI) and an identity to be
used for my upper layer authentication scheme (derived somewhere
else).

For example, SASL digest effectively names the server based on a
realm.  There's no good mapping between the server's domain name and
the realm.  So, I'm fairly certain that a server could trick you into
giving it a challenge to replay with another server.

I think HTTP digest works approximately the same way.
In this situation, TLS would not be enough to prevent MITM.

Although perhaps the difference here is that I was using a broader
definitiong of hi jacking than you were and my definition included
MITM.

From: Sam Hartman <[email-masked]>
To: Digital Identity Exchange <[email-masked]>
Subject: Re: [dix] Re: [Ietf-http-auth] Notes on Web authentication enhancements
Date: Thu, 06 Jul 2006 15:56:11 -0400
Cc: [email-masked]

>>>>> "Dick" == Dick Hardt <[email-masked]> writes:

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

I'm missing something here.  Long term, it seems like all the clients
are going to need to change so that they can interact with the new
IDPs.  Long term, the servers are definitely going to need to change
so they can accept information from the IDPs.  I don't see why it is
unreasonable to solve this on all sites long-term.  In fact, I believe
we're going to have to in order to deal with my requirement 4.4
(mutual authentication).  And yes, I think that requirement is really
important because without it, you don't have assurance that you aren't
giving personal information to the wrong party--you don't have
assurance that you aren't being phished.

I think the question we should be asking in this space is whether
there is something we can do in short-to-medium term that has
acceptable intermediate security.  A quetion you're presumably
interested in is whether DIX or something close to it would be such a
something.

I don't know what my answer to that question is.  I hope to have
decided by the end of the BOF.

To: Sam Hartman <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: [dix] Notes on Web authentication enhancements
From: Eric Rescorla <[email-masked]>
Date: Thu, 06 Jul 2006 12:29:31 -0700
Cc: Digital Identity Exchange <[email-masked]>, [email-masked]
Reply-To: EKR <[email-masked]>

Sam Hartman <[email-masked]> writes:

>>>>>> "Eric" == Eric Rescorla <[email-masked]> writes:
>     >> 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.
>
>     Eric> Imagine a case where you have credentials that have CRA but
>     Eric> not HRA. A good example is Boneh's PwdHash, which includes
>     Eric> the domain name of the server in the "password". If it's
>     Eric> restricted to use with SSL/TLS then you know that each RP
>     Eric> will have a unique domain name and therefore each "password"
>     Eric> is unique to a single RP, so there's automatic CRA--if the
>     Eric> user is phished the phisher must pose as a different RP
>     Eric> because he has a different certificate. [0]
>
> This is not true of all credentials that have cra but not ha--or at
> least I don't see why it is.  TLS only provides security because you
> bind the two authentication layers together by using the same naming
> for both the TLS authentication and the higher layer authentication.
> (It also assumes that your CA is trusted; that assumption seems
> consistent with our threat model.)
>
> I was explicitly trying to get at the fact that you needed to do
> something in addition to TLS.  Here you've made the naming be the
> same.

Sorry, I don't see what you're getting at. PwdHash is specified to use
the domain name of the server as the hash salt. RFC 2818 requires
that that domain name match the server's certificate. There's nothing
additional required.

>     >> 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.
>
>     Eric> By hijacking, I mean network level hijacking. If you mean
>     Eric> typos and phishing, then I think this is a different threat.
>
> Can we have a name for that threat, because I thought you were
> lumping the two together.

Uh, I call the other one "phishing" or "credential capture"

-Ekr

From: Sam Hartman <[email-masked]>
To: EKR <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: [dix] Notes on Web authentication enhancements
Date: Thu, 06 Jul 2006 15:07:57 -0400
Cc: Digital Identity Exchange <[email-masked]>, [email-masked]

>>>>> "Eric" == Eric Rescorla <[email-masked]> writes:
    >> 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.

    Eric> Imagine a case where you have credentials that have CRA but
    Eric> not HRA. A good example is Boneh's PwdHash, which includes
    Eric> the domain name of the server in the "password". If it's
    Eric> restricted to use with SSL/TLS then you know that each RP
    Eric> will have a unique domain name and therefore each "password"
    Eric> is unique to a single RP, so there's automatic CRA--if the
    Eric> user is phished the phisher must pose as a different RP
    Eric> because he has a different certificate. [0]

This is not true of all credentials that have cra but not ha--or at
least I don't see why it is.  TLS only provides security because you
bind the two authentication layers together by using the same naming
for both the TLS authentication and the higher layer authentication.
(It also assumes that your CA is trusted; that assumption seems
consistent with our threat model.)

I was explicitly trying to get at the fact that you needed to do
something in addition to TLS.  Here you've made the naming be the
same.

    >> 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.

    Eric> By hijacking, I mean network level hijacking. If you mean
    Eric> typos and phishing, then I think this is a different threat.

Can we have a name for that threat, because I thought you were lumping the two together.

From: Sam Hartman <[email-masked]>
To: Digital Identity Exchange <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: [dix] Notes on Web authentication enhancements
Date: Thu, 06 Jul 2006 14:55:56 -0400
Cc: [email-masked]

>>>>> "Ben" == Ben Laurie <[email-masked]> writes:

    >> 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.

    Ben> HTTP proxies support the CONNECT method for this (all they do
    Ben> is copy the raw connection data in both directions). Note
    Ben> that if proxies didn't do this, then server authentication
    Ben> would also be impossible.

I'm sorry, I mean no non-connect based proxies.
I.E. proxies that are HTTP hops.

To: Sam Hartman <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: [dix] Notes on Web authentication enhancements
From: Eric Rescorla <[email-masked]>
Date: Mon, 03 Jul 2006 07:19:41 -0700
Cc: Digital Identity Exchange <[email-masked]>, [email-masked]
Reply-To: EKR <[email-masked]>

Sam Hartman <[email-masked]> writes:

> 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.

Thanks. Sorry about the slow response here but I missed this message.

>                              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.

Yes, I agree that these are separate services. I agree that
confidentiality of information carried in the transaction important,
but it's not in and of itself an *authentication* goal (though it may
be used in the service of one if, for instance, the tokens used
for authentication are bearer, like cookies.)

> 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.

I'm not sure this is applicable, since I'm not really maintaining
a document here. That was just a note to the list.

> 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.

I just forgot this one. My bad. 

That said, I think there are actually two security issues surrounding this:

1. Having the IdP perform some kind of secondary check on the identity
   of the RP.
2. Allowing the IdP to limit the use of credentials to selected RPs.

These sound like the same thing but they're strictly speaking not.
For example, consider a case where the IdP wants to charge RPs for
access to their credentials. In order to do this, they encrypt the
credentials with a fixed key that they send to subscribing
RPs <insert suitable DRM, rollover, etc. here>. This doesn't provide
any assurance to the user unless the RP demonstrates knowledge
of the credentials. The RP might just choose to pretend it had
authenticated the user, if, for instance, it wants to induce
the user to give up personal information.

>                       TLS Client AUthentication
>
> Your taxonomy assumes that TLS is a valid approach to client
> authentication. 

I'm not making a judgement about whether it's valid or not. I'm
saying it's been proposed. It has.

> As I understand HTTP, that is only true assuming
> there are no proxies between the user and the RP.

no trusted proxies, technically speaking. TLS accelerators aren't
a problem.

I certainly have seen this issue raised, but I'd like to observe
that they also exist for TLS without client auth (it's one reason
why we designed S-HTTP the way we did) but people seem willing
to live with that.

>   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.

Imagine a case where you have credentials that have CRA but not
HRA. A good example is Boneh's PwdHash, which includes the
domain name of the server in the "password". If it's
restricted to use with SSL/TLS then you know that each RP
will have a unique domain name and therefore each
"password" is unique to a single RP, so there's automatic
CRA--if the user is phished the phisher must pose as a 
different RP because he has a different certificate. [0]

Note, however, that if you use TLS in NULL mode so that the
password can be captured by a passive attacker, then he
can issue a new request to the same server, thus mounting
cut-and-paste attacks. This isn't strictly hijacking, nbut
it's effectively the same for our purposes, since HTTP is 
connectionless. (I'm not sure I got the terminology on this
feature exactly right).

>  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.

By hijacking, I mean network level hijacking. If you mean typos
and phishing, then I think this is a different threat.

-Ekr

[0] Remember that phishing's attack on cert validation is at the
interface between the user's intention and the domain name,
not at the interface between the certificate name and the domain
name.

Date: Mon, 3 Jul 2006 14:50:46 +0100
From: "Ben Laurie" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: [dix] BOF plans (Was: Notes on Web authentication enhancements)
Cc: [email-masked], [email-masked], [email-masked]

On 6/27/06, [email-masked] <[email-masked]> wrote:
>
>
> 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.

Assuming TLS is all about X.509 is completely missing the point. TLS
supports several other authentication mechanisms, such as pre-shared
secrets or Kerberos. There's nothing to stop us defining some new ones
if we need them.

>
>  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.
>
> _______________________________________________
> Ietf-http-auth mailing list
> [email-masked]
> http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth
>
>
>

Date: Mon, 3 Jul 2006 14:46:57 +0100
From: "Ben Laurie" <[email-masked]>
To: "Sam Hartman" <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: [dix] Notes on Web authentication enhancements
Cc: Digital Identity Exchange <[email-masked]>, [email-masked]

On 6/29/06, Sam Hartman <[email-masked]> wrote:
> 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.

HTTP proxies support the CONNECT method for this (all they do is copy
the raw connection data in both directions). Note that if proxies
didn't do this, then server authentication would also be impossible.

> 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
>
> _______________________________________________
> Ietf-http-auth mailing list
> [email-masked]
> http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth
>

Date: Mon, 3 Jul 2006 14:41:50 +0100
From: "Ben Laurie" <[email-masked]>
To: "Digital Identity Exchange" <[email-masked]>
Cc: IETF HTTP Auth <[email-masked]>
Subject: [Ietf-http-auth] Re: [dix] Google Account Authorization - slightly off topic

On 6/29/06, Dick Hardt <[email-masked]> wrote:
> 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?

I will be at the WAE BoF, so, to that extent, yes. Google is certainly
interested in (some of) the problems WAE may work on.

> [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
>
>
> _______________________________________________
> dix mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dix
>

Date: Sun, 2 Jul 2006 14:28:25 +1000
From: Chris Drake <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: [Ietf-http-auth] Comprehensive list - known Threat and Protection table

Hi All,

Has anyone attempted to document the threats and/or what protection
we're trying to provide to users ?

If so - please point me - if not - please add-to or amend my list:

########################################
###  Authentication Threat List 1.0  ###
########################################

1. Confidence Tricks

   1.1. phishing emails
    1.1.1. to lure victims to spoof sites
    1.1.2. to lure victims into installing malicious code
    1.1.3. to lure victims towards O/S vulnerabilities to inject
           malicious code
    1.1.4. to lure victims into revealing information directly via
           reply or via embedded FORMS within the email

   1.2. telephone phishing
    1.2.1. to directly extract auth info
    1.2.2. to direct victim to spoof site
    
   1.3. person-to-person phishing / situation engineering
    1.3.1. to directly extract auth info (ask)
    1.3.2. to direct victim to spoof site
    1.3.3. shoulder surfing (aka 4.5.2)
    1.3.4. physical attack - see 4.7

   1.4. typographic attacks
    1.4.1. spoofing (eg: paypa1.com - using a number 1 for a little L)
    1.4.2. direct download of malicious code
    1.4.3. browser exploit injection

   1.5. online phishing
    1.5.1. pop-up/pop-behind windows to spoof sites
    1.5.2. floating <DIV> or similar elements (eg: emulating an entire
           browser UI)

2. Remote Technical Tricks

   2.1. spoof techniques
    2.1.1. vanilla fake look-alike spoof web sites
    2.1.2. CGI proxied look-alike web site (server CGI talks to real
           site in real time - "man in the middle attack")
    2.1.3. popup windows hiding the address bar (3.4.1/3.4.2)
    2.1.4. <DIV> simulated browsers (1.5.2)

   2.2. iframe exploits (eg: 1.5.1/1.1.3) (spammers buy iframes to
        launch 1.5 and 1.4 attacks)
   2.3. p2p filesharing publication of products modified to
        remove/limit protection - PGP, IE7, Mozilla, ...
   2.4. DNS poisoning (causes correct URL to go to spoof server)
   2.5. traffic sniffing (eg: at ISP, telco, WiFi, LAN, phone tap...)
   2.6. proxy poisoning (correct URL returns incorrect HTML)
   2.7. browser exploits (correct URL returns incorrect HTML)
   2.8. targeted proxy attack
    2.8.1. directs to vanilla spoof web site (2.1.1)
    2.8.2. uses CGI re-writing to proxy legitimate site (eg: convert
           HTTPS into HTTP to activate traffic sniffing) (2.1.2)
    2.8.3  activates 5.7
   2.9.  Authorized exploitation - see 3.5.

3. Local Technical Tricks

   3.2. Software vulnerabilities (aka exploits - eg - 1.1.3)
    3.1.1. Known
    3.1.2. Unknown

   3.2. Browser "toolbars" (grant unrestricted DOM access to SSL data)
   
   3.3. Trojans
    3.3.1. Standalone modified/hacked legitimate products (eg: PGP or
           a MSIE7) with inbuilt protection removed/modified.
    3.3.2. Bogus products (eg: the anti-spyware tools manufactured by
           the Russian spam gangs)
    3.3.3. Legitimate products with deliberate secret functionality
           (eg: warez keygens, sony/CD-Rom music piracy-block addins)
    3.3.4. Backdoors (activate remote control and 3.4.1/3.4.2)

   3.4. Viruses
    3.4.1. General - keyloggers, mouse/screen snapshotters
    3.4.2. Targeted - specifically designed for certain victim sites
           (eg paypal/net banking) or certain victim actions (eg:
           password entry, detecting typed credit card numbers)

   3.5. Authorized exploitation (authority (eg: Microsoft WPA/GA,
        Police, ISP, MSS, FBI, CIA, MI5, Feds...) engineer a Trojan or
        Viral exploit to be shipped down the wire to local PC,
        potentially being legitimately signed/authenticated software.)
   
   3.6. Visual tricks
    3.6.1. browser address bar spoofing
    3.6.2. address bar hiding

   3.7. Hardware attacks
    3.7.1. keylogger devices
    3.7.2. TEMPEST
    3.7.3. malicious hardware modification (token mods, token
           substitution, auth device substitution/emulation/etc)

   3.8. Carnivore, DCS1000, Altivore, NetMap, Echelon, Magic Lantern,
        RIPA, SORM...

4. Victim Mistakes

   4.1. writing down passwords
   4.2. telling people passwords
    4.2.1. deliberately (eg: friends/family)
    4.2.2. under duress (see 4.7)
   4.3. picking weak passwords
   4.4. using same passwords in more than one place
   4.5. inattentiveness when entering passwords
    4.5.1. not checking "https" and padlock and URL
    4.5.2. not preventing shoulder surfing
   4.6. permitting accounts to be "borrowed"
   4.7. physical attack (getting mugged)
    4.7.1. to steal auth info
    4.7.2. to acquire active session
    4.7.3. to force victim to take action (eg: xfer money)
   4.8. allowing weak lost-password "questions"/procedures

5. Implementation Oversights

   5.1. back button
   5.2. lost password procedures
   5.3. confidence tricks against site (as opposed to user)
   5.4. insecure cookies (non-SSL session usage)
   5.5. identity theft? site trusts user's lies about identity
   5.6. trusting form data
   5.7. accepting auth info over NON-SSL (eg: forgetting to check
        $ENV{HTTPS} is 'on' when performing CGI password checks)
   5.8. allowing weak lost-password "questions"/procedures
   5.9. replay
   5.10. robot exclusion (eg: block mass password guessing)
   5.11. geographical exclusion (eg: block logins from Korea)
   6.12. user re-identification - eg - "We've never seen you using
         Mozilla before"
   6.13. site-to-user authentication
   6.14. allowing users to "remember" auth info in browser (permits
         local attacks by unauthorised users)
   6.15. blocking users from being allowed to "remember" auth info in
         browser (facilitates spoofing / keyloggers)
   6.16. using cookies (may permit local attacks by unauthorised
         users)
   6.17. not using cookies (blocks site from identifying malicious
         activity or closing co-compromised accounts)

6. Denial of Service attacks

   6.1. deliberate failed logins to lock victim out of account
   6.2. deliberate failed logins to acquire out-of-channel subsequent
        access (eg: password resets)

7. Please contribute to this document!

   7.1. on-list - just reply
   7.2. off-list - send to [email-masked]

Contributors:  Chris Drake
v.1.0 - July 2, 2006
#########################################
###  /Authentication Threat List 1.0  ###
#########################################

Kind Regards,
Chris Drake