Subject: RE: IETF 65 BOF Announcement: Digital Identity Exchange (DIX)

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 13 Feb 2006 05:42:45 -0800

> Behalf Of Dave Crocker

> Reflecting on the various postings, so far, here is what 
> seems likely to happen at the BOF:
> 
> 1. We will get some presentations, explaining things that we 
> should have read before coming to the BOF.

You mean like people should read Internet drafts before making comments?

> 2. Audience participation will immediately bog down about a) 
> related work, b) intended goals, and c) security risks.

You mean that the face to face discussion will address the three
principle issues that are relevant to the proposal.

> And that's why they need to be discussed *before* there is a 
> BOF.  The amount of time in a BOF does not permit real 
> discussion, of the type called for, here.

Good point, lets do away with all face to face meetings until the
proposers are ready for last call.

> Given the particular nature, complexity, and controversy 
> surrounding the topic of online identities, the second BOF 
> will, at best, be only marginally more productive.

This line of argument is somewhat insulting. If you do not understand
the issues concerned then please by all means stay away until you feel
that you understand them sufficiently to contribute.

I usually take the view that if one does not understand something the
best approach is to listen to people who might. In person presentations
are considerably more effective for this purpose than email. 

While I cannot claim any significant experience in the field of
'identity' I think I can fairly claim to make a definitive contribution
with respect to the question of prior work as the principle non-IETF
works being cited all bear my name as editor. The proposal being made
here is not in conflict with those initiatives and is complimentary in
many ways.

	Phill

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

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 13 Feb 2006 09:00:16 -0800

> From: Richard Shockey [mailto:[email-masked]] 

> Hallam-Baker, Phillip wrote:
> > Perhaps it is just me but I find the two assertions 
> implicit/explicit 
> > in your messages to be incompatible:
> > 
> > 1) That identity is a topic that the IETF has failed to do 
> useful work 
> > on in the past
> 
> That is a unfair statement. 1. There is lots of useful work 
> being done on Identity Management its just not being done at 
> the IETF. We are not the only standards body on the planet.

Just to make clear, what I was objecting to was Dave's constant talking
down what is known about this and other subjects by others. I was
certainly not endorsing his assertion, merely presenting an iminent
critique of his argument.

I am pretty sick of the asgument 'we do not understand this problem, we
must be cautious, therefore it would be a big mistake not to do it my
way'. The term 'we' really meaning 'you'.

I think that when you have a big problem you need to have people with a
big enough ego to solve it. People who see only pitfalls and problems
may provide useful input but nobody can solve a problem until they
understand it.

> Are you familiar with the existent SIP SAML work?

Not really, but I am familiar with SAML having been the first editor of
the core spec. I don't claim exclusive insight into SAML but I think I
can fairly claim some knowledge of the subject.

I think that one aspect of the DIX proposal has the potential to unlock
the whole field in the same way that the URL opened up the Web. Once you
decide that you are going to have one identifier for a person and the
semantics of that identifier are going to be uniform across the Internet
all the pieces of the existing federated auth designs that I have felt
are somewhat disconnected and 'squishy' become clear.

> The question continues to be what areas _could_ or _should_ 
> the IETF make a useful contribution on and how does that 
> relate if any to the existing body of work on SAML and 
> Liberty's Federated Identity Management work. I have some 
> suspicion that W3C is also looking at this area.

Actually several of the people in this thread are on the organizing
committee of the W3C workshop. That is not necessarily going to overlap,
we have to see.

Phishing is theft of credentials through a social engineering attack.
One solution to the problem is better outbound authentication mechanisms
(bank to customer) to defeat the social engineering attack. Another
solution is better inbound credentials (customer to bank) that are theft
proof.

I think that it is clear that both problems have to be addressed. It is
also clear that W3C is much better placed to address the user interface
related issues of outbound authentication. The IETF as a rule avoids
that area. So that is an item I very much hope that W3C will take up.

The question of inbound credentials is not how to make the credentials
theft proof, plenty have solved that problem. The question is how to use
theft proof credentials in the existing Internet infrastructure. How to
make them snap into use.

This is not the problem that DIX is intended to solve but it is a
problem that DIX provides a solution for. Federate the authentication
scheme so that the identity holder chooses their own identity broker and
all things become clear and possible.

With DIX unified identifiers in place I can see how I could choose an
identity broker that supports a strong authentication scheme of my
choice (biometric, PKI, OTP) and use it with a range of sites without
each web site having to take special steps.

> You were correct earlier post that the current work in 
> Liberty has been oriented towards the enterprise single sign 
> on problem but that does not mean it cannot be generalized to 
> the cross domain problem that is the focus of the current 
> Liberty Federation work. As everyone knows modern Identity 
> management theory came out of the violent reaction to 
> Microsoft's Passport proposal.

Violent? I don't recall any Microsoft offices being burnt down or
ransacked. Must have missed that bit.

> I remain very cautious about reinventing the wheel here.

As one of the inventors of the wheel allegedly being reinvented I see
this more as an essential refinement on the wheel, the axle perhaps.

> You incorrectly assume there are failures in this space. In 
> fact there are several successes. I for one agree that the 
> IETF has not looked correctly at Identity management in 
> general but I also strongly believe the IETF has ignored the 
> significant body of existing work in the space.

As I said, I was anoyed at the argument 'we do not understand this,
therefore the group must listen to us'.

My experience is that when someone says 'we do not understand this' what
they really mean is 'you do not understand this you great ignorant oaf
but I do and I am going to try to force you to admit the fact of your
ignorant oafishness by forcing you to either agree with my statement or
appear to be suffering from meglomania.'

Of course in the real world 95% of important stuff is done by people who
are not concerned about appearing to be suffering from meglomania.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 13 Feb 2006 10:05:30 -0800

> Some IETF work items involve narrow topics that are 
> well-understood and have a core of interested folk who are 
> clear about both of these facts, and clear about their goals.
>
> Other work items are not so lucky.

So it would appear to be a good idea to hold a BOF to decide which of
these categories this particular problem falls into.

> As part of our efforts to ensure timely, useful output, we 
> should work pretty hard to assess likely risks for IETF work, 
> from before its inception (and on an on-going basis, of course.)

That is the type of decision I am happy for the Area Directors to have
made.

> Some items are clearly *very* important and *very* risky.  
> They warrant pursuit but they are prime candidates for 
> wasting the IETF's time.  So they require extra efforts to 
> find ways to make things be both timely and productive.

So far it appears that at least 15 of the 50 or so people most closely
involved in this space over the years (SAML, Infocard, Identity 2.0)
will be attending the IETF for the sole purpose of attending this
particular BOF. At least another 10 were planning to attend anyway.

That looks like critical mass to me.

> At the very least, a wasted BOF consumes an expensive slot 
> and delays the topic by at least 4 months.

15 * $650 = $9750, should be enough to cover the room hire.

> Note, however, that the opportunity costs associated with a 
> BOF that is a public debacle can, in fact, have strategic 
> impact, essentially poisoning the IETF waters.

Given that this community is already familiar with working in OASIS,
Liberty and OATH and a workshop is planned in W3C it would appear to me
that far from being premature that the IETF would risk missing an
opportunity here if it does not act.

In retrospect it seems that the reason we did not address these issues
in the SAML group was that we did not feel we had sufficient leverage in
that forum to deploy a uniform identifier.

---

From: "Gray, Eric" <[email-masked]>
Date: Mon, 13 Feb 2006 20:00:21 -0500

Steven,

	There's a certain (very much non-zero) cost associated with 
announcing _anything_ very widely.  Generally it means the person
making the announcement has to subscribe to the list (and hope the
list manager does not filter the announcement anyway) - in part so
that it will actually get posted and in part to capture comments
made on each list that do not also get posted to an appropriate
list (no matter what the announcement says, this will happen).  In
addition, there have been complaints in the past to the general
use of cross-posting, and some list managers may even be actively
filtering (for moderation in any case) on the basis of these prior
complaints.

	I suspect that posting it to the IETF mailing list must be 
considered sufficient, with the understanding that people who care
are subscribed to this list.  Better to expect people to subscribe 
to this list to find out about stuff like BoFs and new mailing 
lists than to declare open season on all mailing lists. If others,
who already subscribe to additional lists, want to repost these on
those other lists (as an FYI, because they feel they are relevant), 
that would take care of widening of the potential audience.

--
Eric

--> -----Original Message-----
--> From: [email-masked] [mailto:[email-masked]] 
--> On Behalf Of Steven M. Bellovin
--> Sent: Sunday, February 12, 2006 9:11 PM
--> To: Hollenbeck, Scott
--> Cc: Ted Hardie; [email-masked]; [email-masked]
--> Subject: Re: IETF 65 BOF Announcement: Digital Identity 
--> Exchange (DIX) 
--> 
--> In message 
--> <[email-masked]
--> .com>, "Hollenbeck, Scott" writes:
--> 
--> >
--> >What sort of manner is that, Dave?  That's a serious 
--> question.  There is
--> >an open mailing list on which discussion has been taking 
--> place since the
--> >Vancouver meeting.  There is still a month to continue 
--> discussion before
--> >Dallas.  If something is too broad or not clear, please share your
--> >thoughts on the dix list so that appropriate changes can 
--> be considered.
--> >
--> 
--> I think Dave has a point.  It's not that there should be an active 
--> mailing list first -- ADs generally require a list and an 
--> I-D first, 
--> per RFC 2418 (a pointer to which should be in 
--> http://www.ietf.org/ietf/1bof-procedures.txt).  The problem is that 
--> most people don't know about BoFs.  I might be interested 
--> in tracking 
--> this one, but I learned of it only through John's voluntary 
--> posting to 
--> the IETF list.  I agree with Dave -- BoFs should indeed be 
--> posted to 
--> the ietf-announce list as soon as they're approved.  (By the same 
--> token, people proposing BoFs should announce their mailing 
--> lists quite 
--> widely.  This one, for example, should have been sent to 
--> the SAAG list, 
--> among many other places, given the strong interest many 
--> security folks 
--> have in such issues.)
--> 
--> 		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
--> 
--> 
--> 
--> _______________________________________________
--> Ietf mailing list
--> [email-masked]
--> https://www1.ietf.org/mailman/listinfo/ietf
-->

---

From: [email-masked]
Date: Mon, 13 Feb 2006 18:10:12 -0800

[email-masked] said:
> While the members of the [dix] list appear to be reaching consensus on an
> approach,

I don't believe that's the case at all on the [email-masked] list. I think there 
have been a fair number of concerns raised there -- so far inadequately 
addressed by the BoF organizers -- especially with respect to prior related 
work. So far the draft charter appears to be adroitly crafted to match the  
hawked input document, imho.

JeffH

---

From: [email-masked]
Date: Mon, 13 Feb 2006 18:42:11 -0800

> As the editor of SAML 1.0 and someone who will be a panelist on the
> Liberty panel at RSA next week the answer is DIX is solving a very
> different part of the same problem space.

I disagree. SXIP (nee DIX) is overall attempting to solve essentially the same 
problem space that the SAML web browser SSO profile addresses.

The extra aspects defined in the DIX I-D, which are largely various named 
attribute-value pairs, could be defined on top of the SAML web browser SSO 
profile (see  saml-profiles-2.0-os.pdf  at http://docs.oasis-open.org/security/
saml/v2.0/). Hence many of the questions and objections raised on the DIX list 
in terms of "why reinvent the wheel??".

> The principle point of SAML was to devise an open standard that allowed
> an ERP application to hook into the enterprise authorization system. 

That's incorrect. I was there from the beginning too. We did not do any 
special tailoring of the SAMLv1.x specs to make them particularly 
complementary to any particular form of web-enabled app. Any vanilla website 
can be SAML-enabled by dropping in one of a plethora webserver plugins 
available from F/OSS sources thru your friendly for-profit software vendors.

> Liberty is addressing a slightly different part of the same enterprise
> federated identity space. In this case the identities being managed may
> be consumer identities but the exchange of information is typically
> taking place within a commercial context. 

This is also incorrect. The early liberty architecture overview did attempt to 
illustrate the problem domain with cross-business-enterprise examples, for 
better or worse (I, by the way, wrote that doc), but there is *nothing* in the 
protocol specifications that limit their applicability to strictly business 
contexts.

> At the moment there is some debate as to what that identifier should be.
> Most people in the group are proposing it should be a URL. As far as I
> am concerned we have an identifier already:
> 
>    [email-masked]
> 
> That's it. Now when I go to any site on the net I want to be able to
> first give my universal user identifier. Then have some magic happen so
> that I can safely authenticate myself against the universal
> authentication service of the domain name specified in my identifier.

This can be accomplished using SAML. SAML, as you note, doesn't stipulate a 
particular identifier format. However, it is a small matter of crafting a new 
SAML profile that does stipulate one, and you will have what you're interested 
in. I nomially believe the DIX I-D could be recast as a SAMLv2 profile, fwiw. 
Hence, again, folks wanting to know why we need to specify something new 
protocol-wise, because that work's largely already been done.

[email-masked] said:
> 'identity' I think I can fairly claim to make a definitive
> contribution with respect to the question of prior work as the
> principle non-IETF works being cited all bear my name as editor. 

Only the SAMLv1.0 "core spec" does, and you share the editor billing with Eve 
Maler. You did not actively edit SAMLv1.1 nor SAMLV2.0, nor actively 
contribute to their development. It appears from mailing list archives that 
your active participation in the OASIS Security Services Technical Committee 
tapered off in summer/fall of 2002.

SAMLv2 supersedes v1.x and is substantially different in various aspects, e.g. 
explicitly supporting the notion of identity federation, refined assertion 
schema, richer notions of protocol bindings and profiles, richer set of 
pofiles, etc.

[email-masked] later said:
> theft proof, plenty have solved that problem. The question is how to
> use theft proof credentials in the existing Internet infrastructure.
> How to make them snap into use.

> scheme so that the identity holder chooses their own identity broker
> and all things become clear and possible.

this could be accomplished via a specific profile of SAML.

> each web site having to take special steps.

the notion of a "global identifier" scheme is also being developed by various 
folks, notably the OASIS-based XRI (eXtensible resource identifiers) tech 
committee...

  http://www.oasis-open.org/committees/xri/

.. (which is on v2.0, and undergoing deployment) so any effort along those 
lines would also need to carefully evaluate/address prior related work, imv.

JeffH

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 14 Feb 2006 00:36:33 -0800

> Behalf Of [email-masked]

The original claim made by Dave Crocker was that this is an area that is
essentially not understood by anyone. I disagree, I think that it is an
area that is very well understood and one in which many of the problems
have already been solved.

If someone attacks my professional competence in a public forum I
believe that I have the right of rebuttal. It is difficult to see how
such a claim can be effectively rebutted without pointing to work done
in that field.

As I pointed out in another message the 'we do not understand this'
trope is essentially a rhetorical trap where the target has to either
admit they don't understand the problem or appear to be immodest. Having
heard it used in MARID and DKIM I decided to draw the line more firmly
this time.

I note that while we disagree on the need for a new protocol here you
are essentially doing so by arguing that the problem is already solved
which is an even stronger rebuttal of the claim that the problem is not
understood.

> I disagree. SXIP (nee DIX) is overall attempting to solve 
> essentially the same problem space that the SAML web browser 
> SSO profile addresses.

There is some overlap between the use cases but not between the
deployment communities. 

I have already suggested that people in DIX look at the SAML artifact
and look at how that might solve the same problem.

There may be more convergence possible, I think that this is best done
through face to face meetings.

> The extra aspects defined in the DIX I-D, which are largely 
> various named attribute-value pairs, could be defined on top 
> of the SAML web browser SSO profile (see  
> saml-profiles-2.0-os.pdf  at http://docs.oasis-open.org/security/
> saml/v2.0/). Hence many of the questions and objections 
> raised on the DIX list in terms of "why reinvent the wheel??".

However having talked to several of the DIX people and looking at the
environment where they propose to deploy I think that there is a case to
be made for an ultra-minimal protocol.

My concern here is that there may be a parallel with X.509/PKIX which
solve every imaginable security problem but we still find that there is
a utility to lightweight hacks like SSH.

I don't want to wait five years to find out that we need a lightweight
hack in addition to SAML. 

If we had handled things a little differently when the need for the SSH
approach had first been spotted we might have come up with a hybrid
scheme that provides a seamless transition from lightweight SSH keying
to full PKI.

My principle concern these days is design for deployability. SAML was
designed with a particular deployment stragegy in mind and it is being
relatively successful in its early adopter niche. Liberty has a more
ambitious goal which again begins from an early adopter niche. The
Identity 2.0 community is working from a totally separate niche, one
that did not exist in 2000 and one that has the potential to be by far
the most rapid.

Done right these three strategies might all meet in the middle.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 14 Feb 2006 07:38:04 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Sent: Monday, February 13, 2006 9:10 PM
> To: [email-masked]
> Subject: Re: IETF 65 BOF Announcement: Digital Identity 
> Exchange (DIX) 
> 

A "fair number" is subjective, especially since I've also seen a fair
number ;-) of comments acknowleding related work.  This is why I want to
hold a BOF - the opportunity for face-to-face discussion will give
everyone a better opportunity to see where consensus lies.

-Scott-