Subject: Briefing paper update
From: Josh Howlett <[email-masked]>
To: [email-masked]
Date: Fri, 26 Mar 2010 10:31:33 -0000

In the run-up to IETF 78, Sam and I will be updating the 'Briefing
Paper'.

Date: Fri, 26 Mar 2010 06:02:38 +0100
From: Klaas Wierenga <[email-masked]>
To: [email-masked]
Subject: preso SASL-SAML/OpeinID

--Apple-Mail-24--785217255
Content-Disposition: inline;
filename0322_kw-SAMLOpenID-SASL-IETFApps.pdf
Content-Type: application/pdf;
name="100322_kw-SAMLOpenID-SASL-IETFApps.pdf"
Content-Transfer-Encoding: base64

--Apple-Mail-24--785217255--

Date: Fri, 26 Mar 2010 01:38:21 +0100
From: Wolfgang Steigerwald <[email-masked]>
To: [email-masked]
Subject: AW: Federated Authentication Discussion Tonight at 9 PM in

Hello all,

I'm very interested in outlined work. From the perspective of the formulated requirements in moonshot-ietf-77-briefing-paper.pdf I might bring your attention to the SWIFT project, an EU-project on identity management http://www.ist-swift.org/.

Best regards

Wolfgang 

-----Ursprüngliche Nachricht-----
Von: Moonshot community list [mailto:[email-masked]] Im Auftrag von Klaas Wierenga
Gesendet: Donnerstag, 25. März 2010 22:06
An: [email-masked]
Betreff: Re: Federated Authentication Discussion Tonight at 9 PM in Manhattan room

On Mar 25, 2010, at 7:12 PM, Sam Hartman wrote:

for those of you present in the SAAG meeting, the alternative/complimentary approaches that Sam was mentioning are the drafts on SASL-SAML integration and SASL-OpenID integration that can be found at respectively:

http://tools.ietf.org/html/draft-lear-ietf-sasl-openid-00
http://tools.ietf.org/html/draft-wierenga-ietf-sasl-saml-00

Klaas

> Folks, I'm looking forward to seeing some of you at the bar bof on
> federated authentication for non-web applications this evening at 9 PM
> in the Manhattan room.  Please see
> http://www.painless-security.com/blog/2010/03/25/moonshot3 for a
> detailed reading list and remote participation instructions.  All the
> material has been sent out previously but I've collected it all into one
> place for your convenience.
> 
> We'll be using the [email-masked] chat room and
> channel 6 on the audio streaming.

Date: Thu, 25 Mar 2010 22:06:22 +0100
From: Klaas Wierenga <[email-masked]>
To: [email-masked]
Subject: Re: Federated Authentication Discussion Tonight at 9 PM in

On Mar 25, 2010, at 7:12 PM, Sam Hartman wrote:

for those of you present in the SAAG meeting, the alternative/complimentary approaches that Sam was mentioning are the drafts on SASL-SAML integration and SASL-OpenID integration that can be found at respectively:

http://tools.ietf.org/html/draft-lear-ietf-sasl-openid-00
http://tools.ietf.org/html/draft-wierenga-ietf-sasl-saml-00

Klaas

> Folks, I'm looking forward to seeing some of you at the bar bof on
> federated authentication for non-web applications this evening at 9 PM
> in the Manhattan room.  Please see
> http://www.painless-security.com/blog/2010/03/25/moonshot3 for a
> detailed reading list and remote participation instructions.  All the
> material has been sent out previously but I've collected it all into one
> place for your convenience.
> 
> We'll be using the [email-masked] chat room and
> channel 6 on the audio streaming.

Date: Thu, 25 Mar 2010 17:08:57 -0700
From: Eliot Lear <[email-masked]>
To: [email-masked]
Subject: Re: Federated Authentication Discussion Tonight at 9 PM in

Just to add to Klaas' comment, there is room in this area for several
approaches.  As Sam wrote on his blog, there are benefits and drawbacks
to each approach, and I believe this area will evolve well over time.

Eliot

On 3/25/10 2:06 PM, Klaas Wierenga wrote:
> On Mar 25, 2010, at 7:12 PM, Sam Hartman wrote:
>
> for those of you present in the SAAG meeting, the alternative/complimentary approaches that Sam was mentioning are the drafts on SASL-SAML integration and SASL-OpenID integration that can be found at respectively:
>
> http://tools.ietf.org/html/draft-lear-ietf-sasl-openid-00
> http://tools.ietf.org/html/draft-wierenga-ietf-sasl-saml-00
>
> Klaas
>
>> Folks, I'm looking forward to seeing some of you at the bar bof on
>> federated authentication for non-web applications this evening at 9 PM
>> in the Manhattan room.  Please see
>> http://www.painless-security.com/blog/2010/03/25/moonshot3 for a
>> detailed reading list and remote participation instructions.  All the
>> material has been sent out previously but I've collected it all into one
>> place for your convenience.
>>
>> We'll be using the [email-masked] chat room and
>> channel 6 on the audio streaming.

Date: Thu, 25 Mar 2010 14:12:01 -0400
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Federated Authentication Discussion Tonight at 9 PM in Manhattan

Folks, I'm looking forward to seeing some of you at the bar bof on
federated authentication for non-web applications this evening at 9 PM
in the Manhattan room.  Please see
http://www.painless-security.com/blog/2010/03/25/moonshot3 for a
detailed reading list and remote participation instructions.  All the
material has been sent out previously but I've collected it all into one
place for your convenience.

We'll be using the [email-masked] chat room and
channel 6 on the audio streaming.

Date: Mon, 22 Mar 2010 12:40:36 -0400
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Slides for Bar BOF

--=-=-

Folks, here are the slides I'm planning to have available for
presentations.  Some people asked not to use slides at a bar bof; I plan
to poll the room at the beginning and figure out if people want me to
make the presentation with our without slides.

--=-=-Content-Type: application/pdf
Content-Disposition: attachment; filename=moonshot-slides-ietf77.pdf
Content-Transfer-Encoding: base64

--=-=-=--

Date: Thu, 18 Mar 2010 22:57:33 -0000
From: Josh Howlett <[email-masked]>
To: [email-masked]
Subject: Initial set of draft Moonshot specifications

This is a multi-part message in MIME format.

------_=_NextPart_001_01CAC6EE.66EA30E4
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I have attached the initial set of draft Moonshot specifications, which
add to the EAP GSS specification that was circulated previously
(http://tools.ietf.org/id/draft-howlett-eap-gss-00.txt). I apologise for
the late delivery; I hope this is soon enough for those of you attending
the Bar BoF to read and digest.

The scope of these specifications is for the 'Beyond Web SSO' category
of use-cases described in the Briefing Paper. These specifications also
go some way towards satisfying the 'Scalable Trust' cateory of
use-cases, but we're not there yet.

None of the attached documents have yet been submitted to the intended
SDOs.

I have made some modest changes to the model in the last few day; I list
these below to avoid potential confusion:

- I have remodelled the proposed set of RADIUS SAML attributes into a
single RADIUS SAML attribute. This is intended to improve extensibility
and avoid unnecessary use of the RADIUS attribute namespace.

- I have remodelled the "SAML RADIUS binding" as a "SAML AAA binding".
This is intended to provide an abstraction from any particular AAA
transport.

- The "SAML EAP GSS SSO Profile" (aka the "SAML EAP Profile") has been
remodelled explicitly as a profile of the SAML authentication request
protocol, following the example of the SAML Web Browser SSO Profile.

If you can think of a better name than "SAML EAP GSS SSO Profile",
please let me know.

This remodelling has resulted in some very minor inconsistencies between
the Briefing Paper and these specifications, but hopefully nothing that
should cause confusion. I recommend that these documents are read in the
following order:

1. Project Moonshot Briefing Paper (see yesterday's email)
2. draft-howlett-radius-saml-attr-00.txt
3. sstc-saml-binding-aaa-draft-00.pdf
4. draft-howlett-eap-gss-00.txt
5. sstc-saml-eapgss-sso-draft-00.pdf

This might look like a substantial reading list, but once you strip out
the boilerplate the aggregate normative text is very modest: only about
25 printed sides, and half of that is in the EAP GSS mechanism.

Unfortunately I have business in the UK which prevents me from attending
IETF (although I will be listening into the audio stream of the Bar BoF,
at 0400 local time). Sam will be presenting our results to date.

I am sincerely grateful to everyone who has taken the time to contribute
their comments, ideas and criticism. Please keep it coming!

best regards, josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

------_=_NextPart_001_01CAC6EE.66EA30E4
Content-Type: text/plain;
name="draft-howlett-radius-saml-attr-00.txt"
Content-Transfer-Encoding: base64
Content-Description: draft-howlett-radius-saml-attr-00.txt
Content-Disposition: attachment;
filename="draft-howlett-radius-saml-attr-00.txt"

OCwgMjAxMCAgICAgICAgICAgICAgIFtQYWdlIDZdCgwK

------_=_NextPart_001_01CAC6EE.66EA30E4
Content-Type: application/pdf;
name="sstc-saml-binding-aaa-draft-00.pdf"
Content-Transfer-Encoding: base64
Content-Description: sstc-saml-binding-aaa-draft-00.pdf
Content-Disposition: attachment;
filename="sstc-saml-binding-aaa-draft-00.pdf"

------_=_NextPart_001_01CAC6EE.66EA30E4
Content-Type: application/pdf;
name="sstc-saml-eapgss-sso-draft-00.pdf"
Content-Transfer-Encoding: base64
Content-Description: sstc-saml-eapgss-sso-draft-00.pdf
Content-Disposition: attachment;
filename="sstc-saml-eapgss-sso-draft-00.pdf"

------_=_NextPart_001_01CAC6EE.66EA30E4--

Date: Wed, 17 Mar 2010 23:09:32 -0000
From: Josh Howlett <[email-masked]>
To: [email-masked]
Subject: IETF 77 Moonshot briefing paper

This is a multi-part message in MIME format.

------_=_NextPart_001_01CAC626.C6833B54
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear all,

Please find attached a briefing paper on Project Moonshot for IETF 77.
The primary goal of this paper is to inform discussion at the Bar BoF on
Thursday evening by providing a comprehensive overview of the problems
we're trying to fix, the proposal we're putting on the table and the
plan for taking it forwards.

If you are not attending the Bar BoF, you are still strongly encouraged
to read it if you have some interest in Project Moonshot. We have tried
hard to make this paper pleasant and interesting to read.

The briefing paper refers to "preliminary specifications". The EAP GSS
mechanism has been available since 1 March; I'm running a little late
with the remaining specifications for various reasons, but will
circulate these to the list within the next 24 hours. Sorry for the
delay here. 

If you are planning on attending the Bar BoF, we would greatly
appreciate it if you could kindly try to read the briefing paper before
the Bar BoF at least, so that we get the maximum benefit of the time
available.

best regards, josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

------_=_NextPart_001_01CAC626.C6833B54
Content-Type: application/pdf;
name="Moonshot - IETF 77 briefing paper.pdf"
Content-Transfer-Encoding: base64
Content-Description: Moonshot - IETF 77 briefing paper.pdf
Content-Disposition: attachment;
filename="Moonshot - IETF 77 briefing paper.pdf"

------_=_NextPart_001_01CAC626.C6833B54--

Date: Mon, 15 Mar 2010 12:28:53 -0400
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: Entity trust establishment & implementation

>>>>> "Scott" = Scott Cantor <[email-masked]> writes:

Scott> Maybe I don't understand what you mean by "single
Scott> request". Are you suggesting some kind of real-time
Scott> submission + hash taking place? That would be a little tricky
Scott> unless, again, you didn't actually care what it was
Scott> hashing/signing.
>>
>> Yes.  That's roughly what Josh and I proposed.  Trusted party
>> policy for what to accept will be a bit tricky as with any
>> non-trivial policy for things like CA signing and the like.  I
>> don't think it is any more tricky than any fully automated
>> policy.

Scott> Ok, I understand your proposal now. That is in principle much
Scott> like "not hashing the whole document" except that you carve
Scott> out the exceptions semantically in the act of hashing the
Scott> whole thing rather than actually doing that cryptographically
Scott> in the hashing step.

Right.  Obviously, it is incrementally deployable.  You can start with
the TA only approving documents that its humans have approved and become
more liberal as customer demand requires without actually changing the
protocol.

To the extent that local control is a motivation for the proposal it is
to reduce opex by getting the federation operator out of the business of
approving or managing most metadata changes.  Clearly to see most of
that opex reduction, you'd need to get as far in deploying this as is
required so that you're not actually approving most metadata changes.

Date: Mon, 15 Mar 2010 12:22:49 -0400
From: Scott Cantor <[email-masked]>
To: [email-masked]
Organization: The Ohio State University

>     Scott> Maybe I don't understand what you mean by "single
>     Scott> request". Are you suggesting some kind of real-time
>     Scott> submission + hash taking place? That would be a little tricky
>     Scott> unless, again, you didn't actually care what it was
>     Scott> hashing/signing.
>
> Yes.  That's roughly what Josh and I proposed.  Trusted party policy for
> what to accept will be a bit tricky as with any non-trivial policy for
> things like CA signing and the like.
> I don't think it is any more tricky than any fully automated policy.

Ok, I understand your proposal now. That is in principle much like "not
hashing the whole document" except that you carve out the exceptions
semantically in the act of hashing the whole thing rather than actually
doing that cryptographically in the hashing step.

It's no doubt feasible, but definitely hasn't been explored much.

-- Scott

Date: Mon, 15 Mar 2010 12:10:23 -0400
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: Entity trust establishment & implementation

>>>>> "Scott" = Scott Cantor <[email-masked]> writes:

Scott> Once you require the global hash, you also require submission
Scott> of any changes you make, whether it's to controlled or
Scott> uncontrolled fields, back to the trust authority. That's what
Scott> people don't want, or at least what some people think they
Scott> don't want.
>>
>> I guess I don't see submitting something as part of a single
>> request as the same as submitting something to a CA ahead of
>> time.

Scott> Maybe I don't understand what you mean by "single
Scott> request". Are you suggesting some kind of real-time
Scott> submission + hash taking place? That would be a little tricky
Scott> unless, again, you didn't actually care what it was
Scott> hashing/signing.

Yes.  That's roughly what Josh and I proposed.  Trusted party policy for
what to accept will be a bit tricky as with any non-trivial policy for
things like CA signing and the like.
I don't think it is any more tricky than any fully automated policy.

Date: Mon, 15 Mar 2010 11:43:18 -0400
From: Scott Cantor <[email-masked]>
To: [email-masked]
Organization: The Ohio State University

>     Scott> Once you require the global hash, you also require submission
>     Scott> of any changes you make, whether it's to controlled or
>     Scott> uncontrolled fields, back to the trust authority. That's what
>     Scott> people don't want, or at least what some people think they
>     Scott> don't want.
>
> I guess I don't see submitting something as part of a single request as
> the same as submitting something to a CA ahead of time.

Maybe I don't understand what you mean by "single request". Are you
suggesting some kind of real-time submission + hash taking place? That would
be a little tricky unless, again, you didn't actually care what it was
hashing/signing.

-- Scott

Date: Mon, 15 Mar 2010 10:57:28 -0400
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: Entity trust establishment & implementation

>>>>> "Scott" = Scott Cantor <[email-masked]> writes:

Scott> Once you require the global hash, you also require submission
Scott> of any changes you make, whether it's to controlled or
Scott> uncontrolled fields, back to the trust authority. That's what
Scott> people don't want, or at least what some people think they
Scott> don't want.

I guess I don't see submitting something as part of a single request as
the same as submitting something to a CA ahead of time.

--Sam

Date: Mon, 15 Mar 2010 10:44:16 -0400
From: Scott Cantor <[email-masked]>
To: [email-masked]
Organization: The Ohio State University

> I'm not at all sure I see why this is true.
> You might be getting online revokation or something like that.

Yes, but that's just OCSP. We could do that now if we wanted to (assuming I
could figure out how to make OpenSSL do it).

> Here's where I have the big disagreement.  I think there is a middle
> ground where the TA can do online verification of some sections of the
> metadata while doing the global hashing.The TA confirms information
> about naming making sure you are not claiming to be someone you are not,
> but gives you local control of keys, algorithms, extensions and the
> like.  (I'm at a disadvantage here because I don't actually know what
> goes in SAML metadata)

We already have that middle ground, that's how the current federations
operate. (Some extensions tend to be "sensitive" and actually relate to
naming, and some would tend to be unvetted.)

Once you require the global hash, you also require submission of any changes
you make, whether it's to controlled or uncontrolled fields, back to the
trust authority. That's what people don't want, or at least what some people
think they don't want.

Personally, I believe it's fine, because it's no different than if you were
to ask a CA to sign a certificate that actually communicated useful
information and not just a key. In other words, it's what PKI was supposed
to support, but one reason most CAs don't do that (apart from being
unwilling to actually vet anything) is that it does create friction when you
want to change any of the data.

> Yes, there are other implementation strategies to get this.  However, I
> believe it does meet the problem statement of local control we agreed to
> above.

I don't think you get the kind of local control people seem to want without
the freedom to change the metadata separately from any submission process to
a third party, particularly if that third party has the potential to "flag"
your submission for examination, thus holding up whatever change you wanted
to make.

My point here is not that what you're proposing is worthless, it's that it's
not significantly more local control than people have now.

I think you can make a case to dump this trust model, deploy a PKI (with
CRLs, OCSP, whatever) that signs participant keys, and locally sign and
assert all of the information. I'm not going to make that case for various
reasons, but I understand the motivation. But once you do that, I think
you've removed any meaningful role for the central trust authority in the
sense we're talking about. It's just a CA again.

-- Scott

Date: Mon, 15 Mar 2010 09:01:20 -0400
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: Entity trust establishment & implementation

>>>>> "Scott" = Scott Cantor <[email-masked]> writes:

Scott> I don't see how. You're either hashing the whole thing,
>>
>> That is the proposal.
>>
Scott> in which case local control is an illusion because the trust
Scott> authority has to vouch for the entire thing anyway,
>>
>> I'd like to dive into what you mean here.  I think this is one of
>> those cases where it may depend heavily on what it means to vouch
>> for something.  I guess it's not obvious to me why local control
>> would be a delusion here.

Scott> For most people who ask for this capabaility in SAML, local
Scott> control means they want the ability to unilaterally change
Scott> the metadata without waiting for a trust authority to "vet"
Scott> or "accept" their changes.

OK, so we're agreed on the problem statement here.

Scott> To wit, they don't want it signed
Scott> (or hashed if you like) by the authority, they want their key
Scott> signed so they can self-assert whatever they choose to, and
Scott> they want their partners to trust that signature.

I agree signing a key is one implementation strategy.

Scott> If the trust authority is just hashing anything the entity
Scott> wants it to, which is implied by the ability to change it on
Scott> a whim, then it isn't really adding anything terribly useful
Scott> to the picture.

I'm not at all sure I see why this is true.
You might be getting online revokation or something like that.
However, I'll agree that if the TA does no checking of the signed
metadata then it is  not adding metadata trust; anything it is adding
comes from other aspects of the protocol.

Scott> And if you *do* have to submit your changes to the authority
Scott> so that it can choose to "sign" them, then you haven't gained
Scott> any local control that you don't have in a traditional model
Scott> based on obtaining the metadata directly from the trust
Scott> authority (which is more or less the current HE federation
Scott> model).

Here's where I have the big disagreement.  I think there is a middle
ground where the TA can do online verification of some sections of the
metadata while doing the global hashing.The TA confirms information
about naming making sure you are not claiming to be someone you are not,
but gives you local control of keys, algorithms, extensions and the
like.  (I'm at a disadvantage here because I don't actually know what
goes in SAML metadata)

Yes, there are other implementation strategies to get this.  However, I
believe it does meet the problem statement of local control we agreed to
above.

Date: Wed, 10 Mar 2010 18:37:58 -0800
From: Dave CROCKER <[email-masked]>
To: [email-masked]
Organization: Brandenburg InternetWorking
Comments: To: Steven Bellovin <[email-masked]>
Comments: cc: Dave Nelson <[email-masked]>, "[email-masked]" <[email-masked]>,
"[email-masked]" <[email-masked]>,
Sam Hartman <[email-masked]>, "[email-masked]" <[email-masked]>
In-Reply-To:  <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 3/10/2010 11:03 AM, Steven Bellovin wrote:
> Yes -- a good supply of solvents is necessary for many IETF discussions...

is that because candid discussion requires participation that is unvarnished?

d/
--

Dave Crocker
Brandenburg InternetWorking
bbiw.net

Date: Wed, 10 Mar 2010 17:11:42 -0500
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: Bar Bof on Federated Authentication Thursday at 9 PM during
message of "Wed, 10 Mar 2010 17:07:26 -0500")
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

>>>>> "Scott" = Scott Cantor <[email-masked]> writes:

>> Perhaps I'm confusing "user interface" (as in the end-user)
>> versus applications interface (as in programming API).  Usability
>> to the developer vs usability to the user/Mom at home.

Scott> Both matter greatly, I think. Sometimes the former trumps the
Scott> latter, there's no question.

>> However, I don't get your last sentence (punt all of it to
>> web-based authentication). Does this mean we just use whatever is
>> used today for web-based authentication (which is primarily
>> username/password over HTMLforms/SSL), and then modify the
>> authn/authz protocols underneath this (ie. introduce a new the
>> GSS-EAP API)?

Scott> No, it means you hack the non-web protocols to glue in a
Scott> callout to a browser and use an approach that tends to be
Scott> SAML Artifact / OAuth like to make the non-web protocol "pull
Scott> in" a session established via the browser.  See recent
Scott> proposals for new SASL mechs for examples of this.

See draft-wierenga-ietf-sasl-saml-00.txt for an example Klaas and I had
an extensive talk about his proposal, Moonshot, differences and
approaches for going forward this morning.
should be writing that up sometime early next week after Josh and I
have a chance to chat about that meeting.

Klaas will be at the IETF meeting and I believe at the bar bof.

Date: Wed, 10 Mar 2010 17:07:26 -0500
From: Scott Cantor <[email-masked]>
To: [email-masked]
Organization: The Ohio State University

> Perhaps I'm confusing "user interface" (as in the end-user)
> versus applications interface (as in programming API).
> Usability to the developer vs usability to the user/Mom at home.

Both matter greatly, I think. Sometimes the former trumps the latter,
there's no question.

> However, I don't get your last sentence (punt all of
> it to web-based authentication). Does this mean we just
> use whatever is used today for web-based authentication
> (which is primarily username/password over HTMLforms/SSL),
> and then modify the authn/authz protocols underneath this
> (ie. introduce a new the GSS-EAP API)?

No, it means you hack the non-web protocols to glue in a callout to a
browser and use an approach that tends to be SAML Artifact / OAuth like to
make the non-web protocol "pull in" a session established via the browser.
See recent proposals for new SASL mechs for examples of this.

-- Scott

Date: Wed, 10 Mar 2010 16:32:42 -0500
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: Bar Bof on Federated Authentication Thursday at 9 PM during
of "Wed, 10 Mar 2010 16:29:32 -0500")
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

>>>>> "Thomas" = Thomas Hardjono <[email-masked]> writes:

Thomas> Thanks Scott.

Thomas> Perhaps I'm confusing "user interface" (as in the end-user)
Thomas> versus applications interface (as in programming API).
Thomas> Usability to the developer vs usability to the user/Mom at
Thomas> home.

I think the global we care about both usability to mom at home and
usability to developers.  I personally think that for this effort both
discussions belong in the IETF.  I'm happy if someone wants to move one
of them elsewhere so long as it does happen though.

--Sam

Date: Wed, 10 Mar 2010 16:29:32 -0500
From: Thomas Hardjono <[email-masked]>
To: [email-masked]
Subject: Re: Bar Bof on Federated Authentication Thursday at 9 PM during

> -----Original Message-----
> From: Moonshot community list [mailto:[email-masked]]
On
> Behalf Of Scott Cantor
> Sent: Wednesday, March 10, 2010 4:00 PM
> To: [email-masked]
> Subject: Re: Bar Bof on Federated Authentication Thursday at 9 PM during
IETF
> week
>
> > If I understand the draft and motivations behind it correctly,
> > I think a large part of the proposal (draft-howlett-eap-gss)
> > is to develop machine to machine federated identity (and
authentication).
> > Which is why Radius is involved (as it is a common directory
> > infra in many organizations) and SAML Request/Response used
> > to carry authz info.
>
> That may be part of the goal, but the main application-related point is to
> address non-web applications, and those applications have (quite limited
in
> many cases) user interfaces for authentication. In point of fact, the
basic
> question is whether the appropriate thing to do from a usability
perspective
> is to NOT mess with that and punt all of it to web-based authentication to
> start with.
>
> So usability is essentially question #1.
>
> -- Scott

Thanks Scott.

Perhaps I'm confusing "user interface" (as in the end-user)
versus applications interface (as in programming API).
Usability to the developer vs usability to the user/Mom at home.

However, I don't get your last sentence (punt all of
it to web-based authentication). Does this mean we just
use whatever is used today for web-based authentication
(which is primarily username/password over HTMLforms/SSL),
and then modify the authn/authz protocols underneath this
(ie. introduce a new the GSS-EAP API)?

/thomas/

Date: Wed, 10 Mar 2010 16:12:31 -0500
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: Bar Bof on Federated Authentication Thursday at 9 PM during
message of "Wed, 10 Mar 2010 15:59:31 -0500")
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

>>>>> "Scott" = Scott Cantor <[email-masked]> writes:

>> If I understand the draft and motivations behind it correctly, I
>> think a large part of the proposal (draft-howlett-eap-gss) is to
>> develop machine to machine federated identity (and
>> authentication).  Which is why Radius is involved (as it is a
>> common directory infra in many organizations) and SAML
>> Request/Response used to carry authz info.

Scott> That may be part of the goal, but the main
Scott> application-related point is to address non-web applications,
Scott> and those applications have (quite limited in many cases)
Scott> user interfaces for authentication.

Scott> So usability is essentially question #1.

Agreed.

Scott> In point of fact, the
Scott> basic question is whether the appropriate thing to do from a
Scott> usability perspective is to NOT mess with that and punt all
Scott> of it to web-based authentication to start with.

I'm opposed to this approach for two key reasons.  First, outsourcing
your authentication UI to the attacker has proven to be an effective way
to decrease security and create phishing vulnerabilities.  I don't think
the web is succeeding at creating a secure user experience for
authentication: I wish to learn from not incorporate its mistakes.
Secondly, machine-to-machine authentication is an importantly use case
that works very poorly in the web outsourcing of authentication model.

We have a lot of experience from the enterprise space that you get
significantly better (although by no means perfect) security when the
OS/application presents authentication UI.  However, by its nature, it
significantly limits opportunities for branding, marketing and
consistency of user experience, which has been an incredibly difficult
sell in the web space.

--Sam

Date: Wed, 10 Mar 2010 15:59:31 -0500
From: Scott Cantor <[email-masked]>
To: [email-masked]
Organization: The Ohio State University

> If I understand the draft and motivations behind it correctly,
> I think a large part of the proposal (draft-howlett-eap-gss)
> is to develop machine to machine federated identity (and authentication).
> Which is why Radius is involved (as it is a common directory
> infra in many organizations) and SAML Request/Response used
> to carry authz info.

That may be part of the goal, but the main application-related point is to
address non-web applications, and those applications have (quite limited in
many cases) user interfaces for authentication. In point of fact, the basic
question is whether the appropriate thing to do from a usability perspective
is to NOT mess with that and punt all of it to web-based authentication to
start with.

So usability is essentially question #1.

-- Scott

Date: Wed, 10 Mar 2010 15:51:17 -0500
From: Thomas Hardjono <[email-masked]>
To: [email-masked]
Subject: Re: Bar Bof on Federated Authentication Thursday at 9 PM during
Comments: cc: [email-masked], [email-masked], [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Phillip Hallam-Baker
> Sent: Wednesday, March 10, 2010 8:05 AM
> To: Melinda Shore
> Cc: [email-masked]; Glen Zorn; [email-masked]; moonshot-
> [email-masked]; Sam Hartman; [email-masked]
> Subject: Re: Bar Bof on Federated Authentication Thursday at 9 PM during
IETF
> week
>
> Last time we had a BOF on that subject matter we had people with the
> bizarre notion that the user interface should be excluded from work on
> user authentication.I don't care if usability is outside people's
> comfort zone, if any group is going to be chartered in this space it
> should be required to address usability issues or we are better off
> without it.

If I understand the draft and motivations behind it correctly,
I think a large part of the proposal (draft-howlett-eap-gss)
is to develop machine to machine federated identity (and authentication).
Which is why Radius is involved (as it is a common directory
infra in many organizations) and SAML Request/Response used
to carry authz info.

So, I'm not sure that "user interface" is relevant here.
GSSAPI is the suggested API for applications.

Or did I read the wrong draft... :)

/thomas/

Date: Wed, 10 Mar 2010 14:03:58 -0500
From: Steven Bellovin <[email-masked]>
To: [email-masked]
Subject: Re: [Emu] Bar Bof on Federated Authentication Thursday at 9 PM
Comments: cc: Glen Zorn <[email-masked]>, "[email-masked]" <[email-masked]>,
Sam Hartman <[email-masked]>, "[email-masked]" <[email-masked]>,
"[email-masked]" <[email-masked]>
In-Reply-To:  <-3850418132860251552@unknownmsgid>
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

On Mar 9, 2010, at 10:03 PM, Dave Nelson wrote:

> Sent from my iPhone, wherein trimming posts is a challenge. :-)
>
> On Mar 9, 2010, at 7:51 PM, Glen Zorn <[email-masked]> wrote:
>
>> Suddenly I'm nostalgic for the days when bar BOFs were impromptu
>> affairs that sprang up in, well, _bars_ & were of necessity free of
>> PowerPoint infestation...
>
> And replete with alcohol.  ;-)
>
Yes -- a good supply of solvents is necessary for many IETF discussions...

--Steve Bellovin, http://www.cs.columbia.edu/~smb

Date: Wed, 10 Mar 2010 10:20:08 -0500
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: Bar Bof on Federated Authentication Thursday at 9 PM during
"Wed, 10 Mar 2010 07:51:25 +0700")
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

>>>>> "Glen" = Glen Zorn <[email-masked]> writes:

Glen> Sam Hartman [[email-masked]] writes:
>> Folks, I'm trying to get a room for the federated authentication
>> bar BOF Thursday March 25 at 9 PM US Pacific time I've requested
>> a room from the secretariat and Pasi said he would approve the
>> request, so we'll see what their availability is.
>>
>> I plan on starting out with a brief presentation on the problem
>> and solution architecture I'm working with, then we'll open it up
>> to discussion.

Glen> Suddenly I'm nostalgic for the days when bar BOFs were
Glen> impromptu affairs that sprang up in, well, _bars_ & were of
Glen> necessity free of PowerPoint infestation...

If people at the meeting  don't want me to use slides, I'd be delighted
with that.  I find slides kind of pointless for myself:-)

Grabbing a room is nice.  "Well, I know I went to IETF in significant
part to discuss this topic, but the bar was noisy and I couldn't hear
from where I was sitting," doesn't fly very well with the co workers.

If you think this topic hasn't been discussed over drinks at a bar, then
we've gone to different bars at past IETFs:-)

Date: Wed, 10 Mar 2010 07:51:25 +0700
From: Glen Zorn <[email-masked]>
To: [email-masked]
Organization: Network Zen
Comments: To: Sam Hartman <[email-masked]>
Comments: cc: [email-masked], [email-masked], [email-masked]

Sam Hartman [[email-masked]] writes:

> Folks, I'm trying to get a room for the federated authentication bar BOF
> Thursday March 25 at 9 PM US Pacific time I've requested a room from the
> secretariat and Pasi said he would approve the request, so we'll see
> what their availability is.
>
> I plan on starting out with a brief presentation on the problem and
> solution architecture I'm working with, then we'll open it up to
> discussion.

Suddenly I'm nostalgic for the days when bar BOFs were impromptu affairs
that sprang up in, well, _bars_ & were of necessity free of PowerPoint
infestation...

The goal of the discussion will be to determine if there is
> > sufficient interest to have a BOF at the next IETF and to understand
> what steps we need to take between now and then.
>
> For the announcement of the proposal see
> http://www.ietf.org/mail-archive/web/emu/current/msg01363.html
> and for our mailing list see
> http://jiscmail.ac.uk/cgi-bin/webadmin?LIST=MOONSHOT-COMMUNITY
>
> Thanks for your interest,
>
> Sam Hartman
> Painless Security, LLC
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

Date: Tue, 9 Mar 2010 17:10:34 -0800
From: Ole Jacobsen <[email-masked]>
To: [email-masked]
Subject: Re: Bar Bof on Federated Authentication Thursday at 9 PM during
Comments: cc: Glen Zorn <[email-masked]>,
[email-masked], Sam Hartman <[email-masked]>,
[email-masked], [email-masked]
In-Reply-To:  <[email-masked]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Well there is CLEARLY an opportunity for the alcohol industry to
engage in some high-profile sponsorship here. "When you think
geek in a bar, think Absolut..."

It's a no-host meeting, but that doesn't mean it has to be a no-host
bar does it?

Ole

Ole J. Jacobsen
Editor and Publisher,  The Internet Protocol Journal
Cisco Systems
Tel: +1 408-527-8972   Mobile: +1 415-370-4628
E-mail: [email-masked]  URL: http://www.cisco.com/ipj

On Tue, 9 Mar 2010, Melinda Shore wrote:

> It wasn't that long ago that a member of the IESG was objecting to
> calling them BOFs at all.  It used to be the case that it was just a
> bunch of people talking, and this stuff about rooms and
> presentations and whatnot leads me to wonder if the "bar BOF" has
> graduated to something that's got some level of sponsorship or
> support from somewhere other than just the people who show up, and
> whether or not that matters.
>
> Melinda
>

Date: Tue, 9 Mar 2010 15:57:59 -0900
From: Melinda Shore <[email-masked]>
To: [email-masked]
Subject: Re: Bar Bof on Federated Authentication Thursday at 9 PM during
Comments: cc: Sam Hartman <[email-masked]>,
[email-masked], [email-masked], [email-masked]
In-Reply-To:  <006f01cabfeb$d21a5000$764ef000$@net>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)

On Mar 9, 2010, at 3:51 PM, Glen Zorn wrote:
> Suddenly I'm nostalgic for the days when bar BOFs were impromptu
> affairs
> that sprang up in, well, _bars_ & were of necessity free of PowerPoint
> infestation...

It wasn't that long ago that a member of the IESG was
objecting to calling them BOFs at all.  It used to be
the case that it was just a bunch of people talking,
and this stuff about rooms and presentations and whatnot
leads me to wonder if the "bar BOF" has graduated to
something that's got some level of sponsorship or
support from somewhere other than just the people who
show up, and whether or not that matters.

Melinda

Date: Mon, 8 Mar 2010 13:00:33 -0500
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Bar Bof on Federated Authentication Thursday at 9 PM during IETF

Folks, I'm trying to get a room for the federated authentication bar BOF
Thursday March 25 at 9 PM US Pacific time I've requested a room from the
secretariat and Pasi said he would approve the request, so we'll see
what their availability is.

I plan on starting out with a brief presentation on the problem and
solution architecture I'm working with, then we'll open it up to
discussion.  The goal of the discussion will be to determine if there is
sufficient interest to have a BOF at the next IETF and to understand
what steps we need to take between now and then.

For the announcement of the proposal see
http://www.ietf.org/mail-archive/web/emu/current/msg01363.html
and for our mailing list see
http://jiscmail.ac.uk/cgi-bin/webadmin?LIST=MOONSHOT-COMMUNITY

Thanks for your interest,

Sam Hartman
Painless Security, LLC

Date: Sun, 7 Mar 2010 23:42:19 +0100
From: \"Diego R. Lopez\" <[email-masked]>
To: [email-masked]
Subject: Re: Entity trust establishment & implementation

On 5 Mar 2010, at 16:35, Scott Cantor wrote:
> And if you *do* have to submit your changes to the authority so that
> it can
> choose to "sign" them, then you haven't gained any local control
> that you
> don't have in a traditional model based on obtaining the metadata
> directly
> from the trust authority (which is more or less the current HE
> federation
> model).

Right, each party depends on (some form of) a TTP.  But with the
credential negotiation process
you avoid the need for both parties trusting the same TTP, as it
happens in the current
federation model, and have the opportunity of a dynamic trust path
calculation.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez

Red.es - RedIRIS
The Spanish NREN

e-mail: [email-masked]
jid:        [email-masked]
Tel:    +34 955 056 621
Mobile: +34 669 898 094
-----------------------------------------

Date: Sun, 7 Mar 2010 18:52:57 -0500
From: Scott Cantor <[email-masked]>
To: [email-masked]
Organization: The Ohio State University

> Right, each party depends on (some form of) a TTP.  But with the
> credential negotiation process you avoid the need for both parties
> trusting the same TTP, as it happens in the current federation model,
> and have the opportunity of a dynamic trust path calculation.

The current proposed model for interfed is not to force each party to use
the same TTP, so that's not an advantage per se, but the method here may
have advantages over moving batches around.

But my point was exactly that...it's this other piece related to trust
management, and *not* the ability to control the metadata locally, that
would be the motivation.

-- Scott

Date: Fri, 5 Mar 2010 10:35:04 -0500
From: Scott Cantor <[email-masked]>
To: [email-masked]
Organization: The Ohio State University

>     Scott> I don't see how. You're either hashing the whole thing,
>
> That is the proposal.
>
>     Scott> in
>     Scott> which case local control is an illusion because the trust
>     Scott> authority has to vouch for the entire thing anyway,
>
> I'd like to dive into what you mean here.  I think this is one of those
> cases where it may depend heavily on what it means to vouch for
> something.  I guess it's not obvious to me why local control would be a
> delusion here.

For most people who ask for this capabaility in SAML, local control means
they want the ability to unilaterally change the metadata without waiting
for a trust authority to "vet" or "accept" their changes. To wit, they don't
want it signed (or hashed if you like) by the authority, they want their key
signed so they can self-assert whatever they choose to, and they want their
partners to trust that signature.

If the trust authority is just hashing anything the entity wants it to,
which is implied by the ability to change it on a whim, then it isn't really
adding anything terribly useful to the picture.

And if you *do* have to submit your changes to the authority so that it can
choose to "sign" them, then you haven't gained any local control that you
don't have in a traditional model based on obtaining the metadata directly
from the trust authority (which is more or less the current HE federation
model).

-- Scott

Date: Fri, 5 Mar 2010 10:24:07 -0500
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: Entity trust establishment & implementation

>>>>> "Scott" = Scott Cantor <[email-masked]> writes:

>> 2) Assuming the AAA infrastructure knows how to obtain the
>> metadata it permits local control of the entire metadata contents
>> while allowing centralized validation of whatever seems
>> appropriate.

Scott> I don't see how. You're either hashing the whole thing,

That is the proposal.

Scott> in
Scott> which case local control is an illusion because the trust
Scott> authority has to vouch for the entire thing anyway,

I'd like to dive into what you mean here.  I think this is one of those
cases where it may depend heavily on what it means to vouch for
something.  I guess it's not obvious to me why local control would be a
delusion here.

Date: Fri, 5 Mar 2010 10:16:46 -0500
From: Scott Cantor <[email-masked]>
To: [email-masked]
Organization: The Ohio State University

> 2) Assuming the AAA infrastructure knows how to obtain the metadata it
> permits local control of the entire metadata contents while allowing
> centralized validation of whatever seems appropriate.

I don't see how. You're either hashing the whole thing, in which case local
control is an illusion because the trust authority has to vouch for the
entire thing anyway, or there's a missing piece here of significant
complexity to support partial signing and then figure out what that means at
a policy decision level.

-- Scott

Date: Fri, 5 Mar 2010 09:15:58 -0500
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: Entity trust establishment & implementation

>>>>> "Scott" = Scott Cantor <[email-masked]> writes:

>> What I believe is that the first half of this (metadata
>> acceptance) will be significantly easier to implement in existing
>> SAML software than the second part (application of the derived
>> keys for SAML crypto). I'm not a SAML implementer, so I would be
>> interested to hear the opinions of those of you who are!

Scott> I don't know if there are any others on the list yet, but
Scott> it's definitely true in my case, and I'm fairly sure it's
Scott> true in the Java code the IdP uses.

Scott> Though I would note that it's important to motivate the
Scott> former with the latter. Which is to say that if all you're
Scott> trying to do is externalize the signature from the document,
Scott> there are other ways to accomplish that. XML Signature
Scott> supports detached signatures, for example, and SAML doesn't
Scott> preclude such things, it merely dictates how its own
Scott> enveloped signatures work.

This doesn't just externalize the signature.  It accomplishes two
additional goals:

1) It expands the credential types you can use for the underlying trust.

2) Assuming the AAA infrastructure knows how to obtain the metadata it
permits local control of the entire metadata contents while allowing
centralized validation of whatever seems appropriate.

--Sam

Date: Thu, 4 Mar 2010 16:57:15 -0000
From: Josh Howlett <[email-masked]>
To: [email-masked]
Subject: Entity trust establishment & implementation

In Moonshot, we have explicitly seperated the problem of (1) applying
federated identity in a non-web SSO protocol, from (2) the problem of
deciding how these actors establish trust in each other.

We believe that we can solve both problems using essentially the same
approach. However, by keeping these as separate concerns we can avoid
requiring that non-web applications must use a particular trust
establishment method. Many people will want to keep using their existing
entity trust establishment methods, and it is important that we continue
to make that possible.

I've spent some time analysing the implementation implications -- for
the non-web SSO part only -- for the Shibboleth IdP and SP with Sam and
Scott. We think that the implications for the Shibboleth SP are fairly
modest (much of the work will be done by the EAP GSS library and
mod-auth-kerb) and trivial or non-existent for the Shibboleth IdP.

That's the good news.

It gets more complicated when you attempt the same analysis for the
'entity trust establishment' problem. What we're trying to do in this
case, in summary, is the following:

1. Enabling a metadata consumer (IdP or SP) to verify that a SAML
metadata <EntityDescriptor> is an accurate description of a 'target
entity' (IdP or SP), according to a third party whom it trusts to make
this claim.

2. Establishing keys for the metadata consumer and target entity that
they can use to secure their communications.

Normally, keys are named or represented explicitly in the entity's
metadata; whereas Moonshot proposes deriving keys dynamically.
Therefore, the Moonshot approach for the 'entity trust establishment'
problem is significantly more intrusive than the 'non-web SSO' case.

What I'm currently trying to understand is whether we can decompose the
'entity trust establishment' problem into two smaller and more
digestible problems, such that we can usefully address them
sequentially.

In Moonshot, we propose that the metadata consumer obtains an
<EntityDescriptor> for the target entity (the "how" is intentionally
out-of-scope, as it is orthogonal to the trust calculus) and establishes
trust in this descriptor by attempting to validate its own credential
against a special-purpose endpoint given in this <EntityDescriptor>
using the EAP GSS mechanism. A successful authentication results in the
metadata consumer obtaining a token, through the GSS-API, whose value
contains a hash of the <EntityDescriptor>. If the metadata consumer can
match this hash against its own independent calculation of the hash, it
can infer that the descriptor is valid and the metadata is 'accepted'.

Because this is GSS, the metadata consumer and target entity (described
by the descriptor that has just been validated) now share a GSS security
context whose Base key can be used to derive keys for the SAML crypto
operations.

What I believe is that the first half of this (metadata acceptance) will
be significantly easier to implement in existing SAML software than the
second part (application of the derived keys for SAML crypto). I'm not a
SAML implementer, so I would be interested to hear the opinions of those
of you who are!

Note that the end-point that the metadata consumer applies its
credentials against does not need to be co-located at the target entity.
It can be anywhere, providing that a trust path exists between the this
endpoint and the metadata consumer's own trust authority. It could, for
example, be an endpoint operated by the TTP. Therefore this endpoint is
not necessarily a SAML implementation consideration.

All the SAML implementation needs to do is (1) somehow obtain the entity
metadata for the target entity (if it hasn't already 'accepted' it and
cached this state), (2) play its credential against the endpoint using
HTTP/Negotiate/EAP-GSS (3) extract the token that gives the hash using
the GSS-API and (4) compare this against a locally computed hash. 

If this is the case, when it comes to implementation I suggest that
there is a strong argument for shooting /initially/ for the first part
of this, and using conventional (meaning SAML Metadata Inter-operability
Profile) keying. This means that SAML entities need both an EAP
credential and a public/private key pair; however, the latter can /also/
be used as an EAP credential and so it should be possible for entities
to hold a single credential (even if means the use of a public/private
keypair).

josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

Date: Thu, 4 Mar 2010 13:14:26 -0500
From: Scott Cantor <[email-masked]>
To: [email-masked]
Organization: The Ohio State University

> What I believe is that the first half of this (metadata acceptance) will
> be significantly easier to implement in existing SAML software than the
> second part (application of the derived keys for SAML crypto). I'm not a
> SAML implementer, so I would be interested to hear the opinions of those
> of you who are!

I don't know if there are any others on the list yet, but it's definitely
true in my case, and I'm fairly sure it's true in the Java code the IdP
uses.

Though I would note that it's important to motivate the former with the
latter. Which is to say that if all you're trying to do is externalize the
signature from the document, there are other ways to accomplish that. XML
Signature supports detached signatures, for example, and SAML doesn't
preclude such things, it merely dictates how its own enveloped signatures
work.

A major advance (to some anyway) might be to come up with a model where some
of the information can be signed and some left to local control, but a
straight hash wouldn't do it.

-- Scott

PS. Something you also have to keep in mind is that the hash would either
have to be c14n-based, or tied to the (probably non-XML) transport encoding
of the metadata.

Date: Thu, 4 Mar 2010 12:37:14 -0500
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: Entity trust establishment & implementation

I agree with this analysis.
However I'm also not a SAML implementor.

Date: Tue, 2 Mar 2010 13:59:56 -0000
From: Josh Howlett <[email-masked]>
To: [email-masked]
Subject: Re: Consent

Sam wrote:
>     Josh> Yes, that's why I was thinking of an HTTP back-channel. I
>     Josh> think it is reasonable to assume HTTP between the client and
>     Josh> client's IdP.
> 
> If the client is a user, perhaps.  If the client is a 
> service, probably not.

What's the use-case that you have in mind?

josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

Date: Tue, 2 Mar 2010 09:48:35 -0500
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: Consent

>>>>> "Josh" = Josh Howlett <[email-masked]> writes:

Josh> Sam wrote:
Josh> Yes, that's why I was thinking of an HTTP back-channel. I
Josh> think it is reasonable to assume HTTP between the client and
Josh> client's IdP.
>>
>> If the client is a user, perhaps.  If the client is a service,
>> probably not.

Josh> What's the use-case that you have in mind?

Well, first, we're designing a GSS-API mechanism, so we need to consider
how this will work as GSS-API mechanisms are used today.

Specifically, though, a service in one organization talking to a service
in another is a common thing in cloud/grid contexts.  In these cases I
think things will be provisioned/configured, so I think either obtaining
consent ahead of time, or convincing the IDP that data protection laws
don't apply to computer programs ahead of time are both reasonable
options.

Date: Tue, 2 Mar 2010 09:47:29 -0500
From: Scott Cantor <[email-masked]>
To: [email-masked]
Organization: The Ohio State University

>> If the client is a user, perhaps.  If the client is a
>> service, probably not.
>
> What's the use-case that you have in mind?

One common one is the n-tier case once you're a layer in. You can't
typically unwind in order to deal with consent, so you need either OOB
agreements as today, or long-lived delegation tokens.

-- Scott

Date: Tue, 2 Mar 2010 08:49:13 -0500
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: Consent

>>>>> "Josh" = Josh Howlett <[email-masked]> writes:
Josh> Yes, that's why I was thinking of an HTTP back-channel. I
Josh> think it is reasonable to assume HTTP between the client and
Josh> client's IdP.

If the client is a user, perhaps.  If the client is a service, probably
not.

Date: Tue, 2 Mar 2010 05:25:44 -0000
From: Josh Howlett <[email-masked]>
To: [email-masked]
Subject: Re: Consent

Sam wrote:
>     Scott> It seems like your secure tunnel between the home 
> domain and
>     Scott> the supplicant offers a way to deal with this, but 
> one issue
>     Scott> is that the thing at the end of the tunnel isn't 
> likely to be
>     Scott> the IdP, so there's more glue needed.
> 
> Another issue is that GSS and EAP basically have no concept 
> of this at all.  You could potentially define a tunneled EAP 
> method for this conversation but it's definitely going to be 
> ugly and a significant change to whatever you're looking at.

Yes, that's why I was thinking of an HTTP back-channel. I think it is
reasonable to assume HTTP between the client and client's IdP.

josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

Date: Mon, 1 Mar 2010 19:27:45 +0100
From: Alan DeKok <[email-masked]>
To: [email-masked]
Subject: Re: Domain based names vs host+realm

Nicolas Williams wrote:
> But you probably _need_ a realm name so you can use RFC1964 exported
> name tokens for servers.  Which realm name to use?  I see two choices:
> the user's realm, or the AAA server's realm.  I think I prefer the
> latter.

What is the difference between "user's realm", and "AAA server's realm" ?

I've done Wifi / WiMAX roaming for a while, with multi-layer AAA
proxies.  I've never seen anyone make a distinction like this.

Alan DeKok.

Date: Mon, 1 Mar 2010 19:26:05 +0100
From: Klaas Wierenga <[email-masked]>
To: [email-masked]
Subject: Re: What do we use SAML request for?

On Mar 1, 2010, at 6:40 PM, Scott Cantor wrote:

>> Some folks from Microsoft I talked to after the Kerberos conference that
>> long term services will need to request specific attributes.  One issue
>> is that the number of attributes available or that could be expected to
>> be computed is far larger than you'd like to send.
> 
> In theory, but rarely in practice, so much so that the IdP code is designed
> in such a manner that specifying what you want to get back isn't going to
> affect what it "computes". It just further filters what it would release.
> Partly that's because scriptlets and other methods of computing attributes
> make it a non-deterministic (or at least hard) problem to answer what set
> you need to compute to supply what you're asked to release.

how about attributes that are computed and that can have different values depending on the question. I am thinking about things like:

"is this user older than 18", "is this user under 16", "is this user between 12 and 18", the answer can be a yes/no computed by examining the single attribute "birthdate", but I can imagine that privacy concerns may lead you not to release that as an attribute, creating separate attributes for all possible values is not an option.

Klaas

> 
>> So in full generality you have:
>> * What the service would like to know
>> * What the IDP is willing to release
>> * What the user wants the IDP to release
> 
> I agree that in terms of architecture/design, yes, they're all relevant. In
> practice, the two factors I named are in my experience the main reasons why
> it's more than a nice to have to be able to specify them in a query.
> 
> -- Scott

Date: Mon, 1 Mar 2010 17:24:26 -0600
From: Nicolas Williams <[email-masked]>
To: [email-masked]
Subject: Re: Domain based names vs host+realm

On Mon, Mar 01, 2010 at 01:42:01PM -0500, Sam Hartman wrote:
> >>>>> "Alan" = Alan DeKok <[email-masked]> writes:
>
>     Alan> Nicolas Williams wrote:
>     >> But you probably _need_ a realm name so you can use RFC1964
>     >> exported name tokens for servers.  Which realm name to use?  I
>     >> see two choices: the user's realm, or the AAA server's realm.  I
>     >> think I prefer the latter.
>
>     Alan>   What is the difference between "user's realm", and "AAA
>     Alan> server's realm" ?
>
> user's realm: realm containing the EAP server.
>
> AAA realm: I think he means the visited realm containing the NAS.  At
> least that's what I'd mean.

Yes, that's what I meant.  I screwed up the terminology.

Date: Mon, 1 Mar 2010 15:53:07 -0600
From: Nicolas Williams <[email-masked]>
To: [email-masked]
Subject: Re: Domain based names vs host+realm

On Mon, Mar 01, 2010 at 12:41:55PM -0500, Sam Hartman wrote:
>     Nicolas> In some ways it seems to me that the realm of the host is
>     Nicolas> completely irrelevant in this case since the host is not
>     Nicolas> participating directly in a Kerberos relam.
>
> I disagree.

I agree with your disagreement.  I was thinking about the GSS initiator
application, where it seemed to me that in the GSS-EAP case the
application probably doesn't care about the host's "realm".  However, I
think both, the initiator application and the EAP server can both care
to authenticate the EAP proxy.

> Here's text from the draft:
>
> [Below, channel binding means EAP channel binding; it is clear from
>    context in the draft.]

When EAP and GSS collide we really need to always clearly disambiguate
the use of "channel binding".  I propose you say "EAP channel binding"
and "GSS channel binding" to properly distinguish them.

> You could argue that it's not actually the realm I care about so much as
> the identity of the server proxy.  That's true, although I think for a
> lot of practical reasons, the realm is a good stand-in for that
> identity.

I agree now.

> However, it sounds like we're in definite agreement that if there is a
> name form that includes service name, host name and administrative realm
> verifying validity of host name, that name form is most definitely not a
> domain-based name.

Definitely.

Note that in my conception of name attributes the "realm" is really an
"issuer" of credentials.  I find this to be a very useful way to think
about principal naming.

Nico
--

Date: Mon, 1 Mar 2010 14:51:16 -0500
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Draft of EAP GSS mechanism posted

I'd like to draw your attention to
http://tools.ietf.org/id/draft-howlett-eap-gss-00.txt.

This is a first version of the moonshot mechanism.

Date: Mon, 1 Mar 2010 13:42:01 -0500
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: Domain based names vs host+realm

>>>>> "Alan" = Alan DeKok <[email-masked]> writes:

Alan> Nicolas Williams wrote:
>> But you probably _need_ a realm name so you can use RFC1964
>> exported name tokens for servers.  Which realm name to use?  I
>> see two choices: the user's realm, or the AAA server's realm.  I
>> think I prefer the latter.

Alan>   What is the difference between "user's realm", and "AAA
Alan> server's realm" ?

user's realm: realm containing the EAP server.

AAA realm: I think he means the visited realm containing the NAS.  At
least that's what I'd mean.

Date: Mon, 1 Mar 2010 13:36:52 -0500
From: Scott Cantor <[email-masked]>
To: [email-masked]
Organization: The Ohio State University

> how about attributes that are computed and that can have different values
> depending on the question. I am thinking about things like:
>
> "is this user older than 18", "is this user under 16", "is this user
between
> 12 and 18", the answer can be a yes/no computed by examining the single
> attribute "birthdate", but I can imagine that privacy concerns may lead
you
> not to release that as an attribute, creating separate attributes for all
> possible values is not an option.

That's partly why I omitted it...that's really a different model than the
simple attribute mechanism currently in SAML, but if that's part of the use
case, it needs additional spec'ing.

I believe WS-Fed had some kind of partial proposal for this kind of thing,
but I'm not aware of it getting much pick up.

On a probably more relevant tack, I hear that MS is announcing the opening
of the UProve stuff from Brands at RSA today. Long lived tokens with
progressive disclosure is probably a better solution for this kind of
problem, and that's another push back against use of back channels (or Web
SSO hacks, for that matter).

-- Scott

Date: Mon, 1 Mar 2010 13:26:15 +0100
From: \"Diego R. Lopez\" <[email-masked]>
To: [email-masked]
Subject: Re: Consent (was RE: What do we use SAML request for?)

On 27 Feb 2010, at 00:55, Josh Howlett wrote:
>
> We could do a lot of interesting things; for example, the supplicant
> could maintain a local consent policy database, or it could sync these
> with the IdP's own consent management database and delegate the
> consent
> decision to the IdP.

When it comes to this sync, a mechanism similar to cookies comes to my
mind,
though not necessarily done through HTTP cookies... The supplicant
could use
some moments (installation, updates, periodically) to make the user
review
and accept consent settings for the IdP, connect to it and get a token
from
the IdP (something like a cookie) that define the settings. Whenever a
request
from consent comes from the IdP, a try using this token could avoid
excessive
(and therefore less secure) usage of the direct user intervention...

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez

Red.es - RedIRIS
The Spanish NREN

e-mail: [email-masked]
jid:        [email-masked]
Tel:    +34 955 056 621
Mobile: +34 669 898 094
-----------------------------------------

Date: Mon, 1 Mar 2010 12:47:36 -0500
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: What do we use SAML request for?

>>>>> "Scott" = Scott Cantor <[email-masked]> writes:

>> Some folks from Microsoft I talked to after the Kerberos
>> conference that long term services will need to request specific
>> attributes.  One issue is that the number of attributes available
>> or that could be expected to be computed is far larger than you'd
>> like to send.

Scott> In theory, but rarely in practice, so much so that the IdP
Scott> code is designed in such a manner that specifying what you
Scott> want to get back isn't going to affect what it "computes". It
Scott> just further filters what it would release.  Partly that's
Scott> because scriptlets and other methods of computing attributes
Scott> make it a non-deterministic (or at least hard) problem to
Scott> answer what set you need to compute to supply what you're
Scott> asked to release.

I think they are working in a different space than you.  The impression
I got was that size of returned attributes was a dominant practical
consideration for their design.
Note that we were talking about the general attribute management
problem; I don't think this could have been considered a discussion
strictly about SAML IDPs.

My point here is I believe there is a knowledgable set of implementors
of software dealing with attribute information who believe that the
number of attributes is a real concern.

I don't believe that set of people is part of our current use case, but
it seems like something to keep in the back of our minds.

Date: Mon, 1 Mar 2010 12:41:55 -0500
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: Domain based names vs host+realm
"Mon, 1 Mar 2010 11:04:10 -0600")
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

>>>>> "Nicolas" = Nicolas Williams <[email-masked]> writes:

Nicolas> On Sun, Feb 28, 2010 at 11:17:02AM -0500, Sam Hartman wrote:
>> Like Kerberos, moonshot needs to solve the host-to-realm mapping
>> problem.  It manifests differently though.  There is likely to be
>> a server AAA proxy near the server.  That proxy is responsible
>> for deciding whether the authentication request comes from the
>> indicated host.  The request eventually gets to an EAP server.
>> The EAP server probably only has the identity of the visited
>> realm of the server proxy [1].  So it must decide whether that
>> visited realm is a reasonable realm to claim the hostname that
>> the acceptor claims.
>>
>> In some ways that's easier than Kerberos.

Nicolas> In some ways it seems to me that the realm of the host is
Nicolas> completely irrelevant in this case since the host is not
Nicolas> participating directly in a Kerberos relam.

I disagree.
Here's text from the draft:

[Below, channel binding means EAP channel binding; it is clear from
context in the draft.]

The GSS_C_NT_HOSTBASED_SERVICE name form represents a service running
on a host; it is textually represented as "HOST@SERVICE".  This name
form is required by most SASL profiles and is used by many existing
applications that use the Kerberos GSS-API mechanism.  While support
for this name form is critical, it presents an interesting challenge
in terms of channel binding.  Consider a case where the server
communicates with a "server proxy," or a AAA server near the server.
That server proxy communicates with the EAP server.  The EAP server
and server proxy are in different administrative realms.  The server
proxy is in a position to verify that the request comes from the
indicated host.  However the EAP server cannot make this
determination directly.  So, the EAP server needs to determine
whether to trust the server proxy to verify the host portion of the
acceptor name.  This trust decision depends both on the host name and
the realm of the server proxy.  In effect, the EAP server decides
whether to trust that the realm of the server proxy is the right
realm for the given hostname and then makes a trust decision about
the server proxy itself.  The same problem appears in Kerberos:
there, clients decide what Kerberos realm to trust for a given
hostname.

You could argue that it's not actually the realm I care about so much as
the identity of the server proxy.  That's true, although I think for a
lot of practical reasons, the realm is a good stand-in for that
identity.

However, it sounds like we're in definite agreement that if there is a
name form that includes service name, host name and administrative realm
verifying validity of host name, that name form is most definitely not a
domain-based name.

--Sam

Date: Mon, 1 Mar 2010 12:40:10 -0500
From: Scott Cantor <[email-masked]>
To: [email-masked]
Organization: The Ohio State University

> Some folks from Microsoft I talked to after the Kerberos conference that
> long term services will need to request specific attributes.  One issue
> is that the number of attributes available or that could be expected to
> be computed is far larger than you'd like to send.

In theory, but rarely in practice, so much so that the IdP code is designed
in such a manner that specifying what you want to get back isn't going to
affect what it "computes". It just further filters what it would release.
Partly that's because scriptlets and other methods of computing attributes
make it a non-deterministic (or at least hard) problem to answer what set
you need to compute to supply what you're asked to release.

> So in full generality you have:
> * What the service would like to know
> * What the IDP is willing to release
> * What the user wants the IDP to release

I agree that in terms of architecture/design, yes, they're all relevant. In
practice, the two factors I named are in my experience the main reasons why
it's more than a nice to have to be able to specify them in a query.

-- Scott

Date: Mon, 1 Mar 2010 11:59:40 -0500
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: What do we use SAML request for?

>>>>> "Scott" = Scott Cantor <[email-masked]> writes:

>> At the risk of generalising, I think it is interesting to
>> consider whether we can extrapolate from today's Web SSO
>> practices, particularly as in the use-cases we're not using SAML
>> for authentication (where we might care about LoA etc); only as a
>> source of attributes. The SAML IdP, consequently, says what goes
>> and what doesn't
Scott> and
>> the request is moot.

Scott> Well, it's not moot because of the identifier question, but
Scott> yes, I thought about mentioning that.

Scott> The issues there are essentially whether users can consent in
Scott> real time, and/or whether requirements from the service's end
Scott> vary dynamically. Without one of those cases, you get pretty
Scott> much nothing from requesting specific attributes, and in fact
Scott> the Shibboleth IdP doesn't currently handle queries that
Scott> specify them. (It should/will at some point soon.)

Some folks from Microsoft I talked to after the Kerberos conference that
long term services will need to request specific attributes.  One issue
is that the number of attributes available or that could be expected to
be computed is far larger than you'd like to send.

So in full generality you have:
* What the service would like to know
* What the IDP is willing to release
* What the user wants the IDP to release

--Sam

Date: Mon, 1 Mar 2010 11:04:10 -0600
From: Nicolas Williams <[email-masked]>
To: [email-masked]
Subject: Re: Domain based names vs host+realm

On Sun, Feb 28, 2010 at 11:17:02AM -0500, Sam Hartman wrote:
> Like Kerberos, moonshot needs to solve the host-to-realm mapping
> problem.  It manifests differently though.  There is likely to be a
> server AAA proxy near the server.  That proxy is responsible for
> deciding whether the authentication request comes from the indicated
> host.  The request eventually gets to an EAP server.  The EAP server
> probably only has the identity of the visited realm of the server proxy
> [1].  So it must decide whether that visited realm is a reasonable realm
> to claim the hostname that the acceptor claims.
>
> In some ways that's easier than Kerberos.

In some ways it seems to me that the realm of the host is completely
irrelevant in this case since the host is not participating directly in
a Kerberos relam.

But you probably _need_ a realm name so you can use RFC1964 exported
name tokens for servers.  Which realm name to use?  I see two choices:
the user's realm, or the AAA server's realm.  I think I prefer the
latter.

> We probably also want a name form that includes a host, service and
> realm.  Syntactically that's the same as a domain-based name.  It's my
> opinion though that semantically it's not a domain-based name and thus
> we should not use that name type.  Do you agree?

It's absolutely not a domain-based name; it's a hostbased service name.
The need for a realm is artificial -- nothing in the GSS-API requires
it, so the need must come from compatibility with GSS-API apps that
specifically expect GSS_KRB5_NT_HOSTBASED_SERVICE_NAME names.

If I'm right about why you want a realm, then you should document the
fact of and reason for it.  You should also consider carefully whether
you really need it -- you might not.

> [1] It's possible the EAP server may not know the visited realm.  We
> can't actually make that case wrok from a security standpoint so we'll
> have to require the EAP server to know the visited realm.

In that case I'd say use the user's realm.

Nico
--

Date: Mon, 1 Mar 2010 08:41:26 -0500
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: Consent

>>>>> "Diego" = Diego R Lopez <[email-masked]> writes:

Diego> On 27 Feb 2010, at 00:55, Josh Howlett wrote:
>>
> We could do a lot of interesting things; for example, the supplicant
>> could maintain a local consent policy database, or it could sync
>> these with the IdP's own consent management database and delegate
>> the consent decision to the IdP.

Diego> When it comes to this sync, a mechanism similar to cookies
Diego> comes to my mind, though not necessarily done through HTTP
Diego> cookies... The supplicant could use some moments
Diego> (installation, updates, periodically) to make the user review
Diego> and accept consent settings for the IdP, connect to it and
Diego> get a token from the IdP (something like a cookie) that
Diego> define the settings. Whenever a request from consent comes
Diego> from the IdP, a try using this token could avoid excessive
Diego> (and therefore less secure) usage of the direct user
Diego> intervention...

This is definitely a promising idea.  I can think of a number of ways to
implement this and it definitely is something we can do.  I think there
are even mechanisms for communicating per-service consent information to
the IDP.

What gets tricky is to have interaction round trips as part of the
authentication conversation.  However I want to emphasize that's tricky
not impossible.

--Sam