Subject: Re: Consent
From: Sam Hartman <[email-masked]>
To: [email-masked]
Date: Sun, 28 Feb 2010 15:34:59 -0500

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

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.

Date: Sun, 28 Feb 2010 15:21:02 -0500
From: Scott Cantor <[email-masked]>
To: [email-masked]
Organization: The Ohio State University

> I find the consent issue particularly interesting (bear with me...). One
> of the benefits that we get from the browser-bound bindings is the
> opportunity to interrogate the user about things like consent.

Yes, for a lot of people that's *the* issue that argues for hacking WebSSO
or OAuth to do basically anything you have to do.

> The Interaction Service is a fairly simple spec, but there are probably
> other approaches we should also consider. Ideas welcome!

The original service in Liberty that I was familiar with had basically no
meaningful support for the back channel. It had the ability to redirect you
(web style, basically a lot like OAuth) or to tunnel information back from a
service through the service's client, and then on to the original web
client. Security-wise, that model was of course quite silly, since you were
trusting the service that needed consent to relay your (unauthenticated)
indication of consent.

The last time this came up, I was given the impression that the later
versions of the Interaction Service had other options that were more secure,
but I haven't actually read it recently.

It seems like your secure tunnel between the home domain and the supplicant
offers a way to deal with this, but one issue is that the thing at the end
of the tunnel isn't likely to be the IdP, so there's more glue needed.

-- Scott

Date: Sun, 28 Feb 2010 11:17:02 -0500
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Domain based names vs host+realm

nico, I'm writing up the 00 draft of the moonshot mechanism based on a
draft I received from Josh.

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.

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?

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

--Sam

Date: Fri, 26 Feb 2010 23:58:57 -0000
From: Josh Howlett <[email-masked]>
To: [email-masked]
Subject: Re: What do we use SAML request for?

> whether requirements from the service's end=20
> vary dynamically.

When you say dynamically, do you mean faster than requirements can be
managed out-of-band?

josh.

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

Date: Fri, 26 Feb 2010 23:55:40 -0000
From: Josh Howlett <[email-masked]>
To: [email-masked]
Subject: Consent (was RE: What do we use SAML request for?)

> The issues there are essentially whether users can consent in=20
> real time

I find the consent issue particularly interesting (bear with me...). One
of the benefits that we get from the browser-bound bindings is the
opportunity to interrogate the user about things like consent.

In Moonshot, the SAML messages are bound to a back-channel. Therefore,
we can't apply the same kind of stratgy for obtaining consent. But, in
many scenarios, consent is still necessary. How should we address this?

Given that we're assuming the existence of a supplicant for driving
identity selection and authentication, I'm also inclined to use the
supplicant for consent. How would we do this? There's probably a lot of
ways to model this, but I've been looking at the Liberty Alliance
Interaction Service. As the name suggests, this defines a way for
entities to pose questions to users. In brief, the supplicant and the
user's IdP establish an HTTP connection; when an attribute request
message hits the IdP, it could optionally send an interaction service
message to the supplicant, which would construct a form in the
supplicant for the user to complete. The user makes a decision, and the
supplicant sends it back and the IdP would act on this information.

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.

The Interaction Service is a fairly simple spec, but there are probably
other approaches we should also consider. Ideas welcome!

josh.

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

Date: Fri, 26 Feb 2010 23:08:28 -0000
From: Josh Howlett <[email-masked]>
To: [email-masked]
Subject: Re: What do we use SAML request for?

> > Here's what I think we need out of the SAML request.  I think it=20
> > provides a place for S to indicate what attributes it=20
> needs.  First,=20
> > is this correct?  Secondly, is there anything else that our=20
> particular=20
> > use cases get out of a SAML request?
>=20
> I think the way to answer that is best handled by starting=20
> with what you want to get in return, and then in parallel=20
> setting out the assumptions made about what knowledge of the=20
> user exists between S, the entity making the request (if it's=20
> not S), and the IdP.
>=20
> The main thing we have to do is determine the "fit" between=20
> those answers and the existing protocols in SAML.

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 and the request is moot.

josh.

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

Date: Fri, 26 Feb 2010 20:39:14 -0500
From: Scott Cantor <[email-masked]>
To: [email-masked]
Organization: The Ohio State University

>> whether requirements from the service's end
>> vary dynamically.
>
> When you say dynamically, do you mean faster than requirements can be
> managed out-of-band?

Yes, that's a better way of saying it.

-- Scott

Date: Fri, 26 Feb 2010 18:23:02 -0500
From: Scott Cantor <[email-masked]>
To: [email-masked]
Organization: The Ohio State University

> 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
and
> the request is moot.

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

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

-- Scott

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

> Here's what I think we need out of the SAML request.  I think it
> provides a place for S to indicate what attributes it needs.  First,
> is this correct?  Secondly, is there anything else that our particular
> use cases get out of a SAML request?

I think the way to answer that is best handled by starting with what you
want to get in return, and then in parallel setting out the assumptions made
about what knowledge of the user exists between S, the entity making the
request (if it's not S), and the IdP.

The main thing we have to do is determine the "fit" between those answers
and the existing protocols in SAML.

-- Scott

Date: Fri, 26 Feb 2010 14:38:21 -0500
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: What do we use SAML request for?

So, in a side conversation, Scott, Josh and I have been discussing the
SAML request that goes from S to TAC and thus to C's IDP.  During that
discussion I realized that I don't have a clear idea of what we're using
the SAML request to accomplish.

Here's what I think we need out of the SAML request.  I think it
provides a place for S to indicate what attributes it needs.  First, is
this correct?  Secondly, is there anything else that our particular use
cases get out of a SAML request?

--Sam

Date: Thu, 25 Feb 2010 21:36:15 +0100
From: Klaas Wierenga <[email-masked]>
To: [email-masked]
Subject: Re: Federated authentication bar bof probably Thursday evening

On Feb 25, 2010, at 8:27 PM, Sam Hartman wrote:

Hi Sam,

Either earlier and grab something to eat and keep the discussion going =
afterwards or your proposal work for me.

Klaas

> Folks, I've been talking to Vumip Khasnabish who is working on
> organizing a cloud computing bar bof.  It seems that having cloud
> computing and federated authentication at the same time would be a bad
> idea: I suspect a lot of us want to go to both.  Vumip was hoping that
> the clouds bof would land on Wednesday.  If that happens I'd like to
> meet on Thursday.
>=20
> In terms of timing, I've never done this before.  Do I want to do
> something like 9 PM-10:30 so people can grab a bite to eat before and =
so
> that those who wish may join the discussion of IPv6 deployment that =
will
> be ongoing by the time we conclude?
>=20
> --Sam

Date: Thu, 25 Feb 2010 19:05:32 -0500
From: Thomas Hardjono <[email-masked]>
To: [email-masked]
Subject: Re: Federated authentication bar bof probably Thursday evening

Sam,

I plan to attend both.  So it would be good to have them on separate
times/days.

cheers,

/thomas/

> -----Original Message-----
> From: Moonshot community list [mailto:[email-masked]]
On
> Behalf Of Sam Hartman
> Sent: Thursday, February 25, 2010 2:27 PM
> To: [email-masked]
> Subject: Federated authentication bar bof probably Thursday evening
>
> Folks, I've been talking to Vumip Khasnabish who is working on
> organizing a cloud computing bar bof.  It seems that having cloud
> computing and federated authentication at the same time would be a bad
> idea: I suspect a lot of us want to go to both.  Vumip was hoping that
> the clouds bof would land on Wednesday.  If that happens I'd like to
> meet on Thursday.
>
> In terms of timing, I've never done this before.  Do I want to do
> something like 9 PM-10:30 so people can grab a bite to eat before and so
> that those who wish may join the discussion of IPv6 deployment that will
> be ongoing by the time we conclude?
>
> --Sam

Date: Thu, 25 Feb 2010 14:27:17 -0500
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Federated authentication bar bof probably Thursday evening

Folks, I've been talking to Vumip Khasnabish who is working on
organizing a cloud computing bar bof.  It seems that having cloud
computing and federated authentication at the same time would be a bad
idea: I suspect a lot of us want to go to both.  Vumip was hoping that
the clouds bof would land on Wednesday.  If that happens I'd like to
meet on Thursday.

In terms of timing, I've never done this before.  Do I want to do
something like 9 PM-10:30 so people can grab a bite to eat before and so
that those who wish may join the discussion of IPv6 deployment that will
be ongoing by the time we conclude?

--Sam

Date: Wed, 24 Feb 2010 13:57:06 -0000
From: Josh Howlett <[email-masked]>
To: [email-masked]
Subject: Re: SAML RADIUS Binding

> > Reading SAML2Core section 2.3, would it be cleaner to use=20
> > AssertionURIRef instead, defining some namespace for this purpose?
>=20
> I don't think there's much difference, really.

I was thinking about what this might mean for the implementer of a SAML
issuer. Decorating the assertion ID with these semantics surely implies
that the code that constructs the assertion needs to be aware of binding
that will be used to obtain it, or else it must decorate all assertions
using this method; both seem rather intrusive. If we use a URI
reference, I don't think we need to touch that part of the SAML issuer.
=20
> > Thinking aloud, might there also be some advantage in using=20
> the SAML=20
> > URI Binding rather than the Assertion Request Profile? The SAML URI=20
> > Binding is somewhat more lightweight.
>=20
> It's more lightweight at the cost of limiting the security=20
> features to HTTP, rather than SOAP.

Ok, I think that's probably a feature in this context. I can't see what
value SOAP adds.

> If I understand what you're thinking about, I think all that=20
> is moot here because you're looking for different places to=20
> put the authentication of the peers and trying to exchange a=20
> hash along with the data you want to pass because the channel=20
> is already supposed to be authenticated.

That's what I was thinking.

josh.

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

Date: Wed, 24 Feb 2010 10:06:47 -0500
From: Scott Cantor <[email-masked]>
To: [email-masked]
Organization: The Ohio State University

Josh Howlett wrote on 2010-02-24:
>> It's more lightweight at the cost of limiting the security
>> features to HTTP, rather than SOAP.
>
> Ok, I think that's probably a feature in this context. I can't see what
> value SOAP adds.

A framework for message-level authentication, basically, in particular the
ability to use SAML assertions as a credential (recursive use, basically).
There really is nothing else (in wide use) that supports the use of SAML
that way on a message-oriented basis.

-- Scott

Date: Tue, 23 Feb 2010 22:51:10 -0000
From: Josh Howlett <[email-masked]>
To: [email-masked]
Subject: Re: SAML RADIUS Binding

Josh wrote:
> > The AssertionIdRef is basically just consumed by the relying party,=20
> > there aren't any rules in the spec for processing it or=20
> decorating it.
>=20
> Is there any harm in processing or decorating it such that we=20
> can obtain the kinds of semantics we've been discussing?

Reading SAML2Core section 2.3, would it be cleaner to use
AssertionURIRef instead, defining some namespace for this purpose?

Thinking aloud, might there also be some advantage in using the SAML URI
Binding rather than the Assertion Request Profile? The SAML URI Binding
is somewhat more lightweight.

josh.

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

Date: Tue, 23 Feb 2010 22:36:34 -0000
From: Josh Howlett <[email-masked]>
To: [email-masked]
Subject: Re: SAML RADIUS Binding

Scott wrote:
> Josh Howlett wrote on 2010-02-18:
> > That makes a lot of sense. If you recall, the original=20
> approach was to=20
> > avoid authentication (which would imply a turtle issue) of the=20
> > call-back responder by attempting to match a hash claimed in the=20
> > artifact to the SAML message that it resolves. I believe we can=20
> > achieve a semantically equivalent effect by incorporating the same=20
> > hash in the AssertionIdRef value.
>=20
> The AssertionIdRef is basically just consumed by the relying=20
> party, there aren't any rules in the spec for processing it=20
> or decorating it.

Is there any harm in processing or decorating it such that we can obtain
the kinds of semantics we've been discussing?

josh.

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

Date: Tue, 23 Feb 2010 19:11:04 -0500
From: Scott Cantor <[email-masked]>
To: [email-masked]
Organization: The Ohio State University

Josh Howlett wrote on 2010-02-23:
>> Is there any harm in processing or decorating it such that we
>> can obtain the kinds of semantics we've been discussing?

There's no harm unless the processing is expected to be performed by the
client of the URL. The URL in question is expected to be opaque to the
client with the exception of a convention to construct a URL if you know the
endpoint and the Assertion ID.

A different set of rules could be created with a different binding layered
on top of the original one.

> Reading SAML2Core section 2.3, would it be cleaner to use
> AssertionURIRef instead, defining some namespace for this purpose?

I don't think there's much difference, really.

> Thinking aloud, might there also be some advantage in using the SAML URI
> Binding rather than the Assertion Request Profile? The SAML URI Binding
> is somewhat more lightweight.

It's more lightweight at the cost of limiting the security features to HTTP,
rather than SOAP.

If I understand what you're thinking about, I think all that is moot here
because you're looking for different places to put the authentication of the
peers and trying to exchange a hash along with the data you want to pass
because the channel is already supposed to be authenticated.

-- Scott

Date: Tue, 23 Feb 2010 16:52:29 +0100
From: Alan DeKok <[email-masked]>
To: [email-masked]
Subject: Re: SAML RADIUS Binding

Josh Howlett wrote:
> Alan wrote:
>>   No.  The RADEXT WG has specifically rejected any attempt to
>> increase the RADIUS MTU.
>
> What was the reason(s) given?

It would involve changes to the base spec, and could have unforeseen
side effects.

Alan DeKok.

Date: Tue, 23 Feb 2010 13:32:46 -0000
From: Josh Howlett <[email-masked]>
To: [email-masked]
Subject: Re: SAML RADIUS Binding

Alan wrote:
> Josh Howlett wrote:
> > Sam wrote:
> >> First, I think the right technical approach is to ignore the RADIUS

> >> MTU issue.
> >=20
> > Would this be acceptable to IETF?=20
>=20
>   No.  The RADEXT WG has specifically rejected any attempt to=20
> increase the RADIUS MTU.

What was the reason(s) given?

josh.

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

Date: Tue, 23 Feb 2010 08:37:15 +0000
From: Alan DeKok <[email-masked]>
To: [email-masked]
Subject: Re: SAML RADIUS Binding

Josh Howlett wrote:
> Sam wrote:
>> First, I think the right technical approach is to ignore the
>> RADIUS MTU issue.
>
> Would this be acceptable to IETF?

No.  The RADEXT WG has specifically rejected any attempt to increase
the RADIUS MTU.

> Ot are you talking about the implementation?

A number of implementations are more "forgiving" about MTU.

Alan DeKok.

Date: Mon, 22 Feb 2010 22:40:05 -0000
From: Josh Howlett <[email-masked]>
To: [email-masked]
Subject: Re: SAML RADIUS Binding

> How many Moonshot folks will be at IETF 77 in Anaheim? I'll=20
> be there so I'd be happy to chat with you about it then.

We're planning a Bar BOF; more on this shortly.

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=20
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

Date: Mon, 22 Feb 2010 20:24:56 -0000
From: Josh Howlett <[email-masked]>
To: [email-masked]
Subject: Re: SAML RADIUS Binding

Hi Peter,

> You do have some XMPP experts on this list. :)

Thanks for dropping by :-)

> I'd be happy to have a chat with you and=20
> anyone else who's interested so that we can figure out what=20
> your requirements are and whether XMPP meets those=20
> requirements (or can be extended to do so). Perhaps we can=20
> set up a conference call in the near future?

Having spoken to others off-line, I think that it is likely that
defining a new lower-layer for EAP (while attractive in principle) will
introduce a host of other issues. Looking at this pragmatically, there
is a strong argument for "better the devil you know".

It could be that we end up defining a new EAP lower-layer if we fail
with RadSec/RADIUS, but at least we'll be better informed having tried.

I am personally still interested in exploring this possibility, but I
think we should consider this a 'research' topic and proceed with the
SAML RADIUS Binding as originally proposed.

In terms of having a call, I suggest that we wait until we have finished
documenting the use-cases and the concrete technical proposal to address
these. Hopefully Sam and I will have this done within 3 weeks or so.
That will provide a dart-board that other ideas can take aim against.

Thank you for your offer, and I look forward to having this discussion!

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=20
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

Date: Mon, 22 Feb 2010 18:17:33 -0000
From: Josh Howlett <[email-masked]>
To: [email-masked]
Subject: Re: SAML RADIUS Binding

Sam wrote:
> First, I think the right technical approach is to ignore the=20
> RADIUS MTU issue.

Would this be acceptable to IETF? Ot are you talking about the
implementation?

josh.

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

Date: Mon, 22 Feb 2010 15:34:49 -0700
From: Peter Saint-Andre <[email-masked]>
To: [email-masked]
Subject: Re: SAML RADIUS Binding
micalg=sha1; boundary="------------ms040402020707010106020501"

This is a cryptographically signed message in MIME format.

--------------ms040402020707010106020501
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 2/22/10 1:24 PM, Josh Howlett wrote:
> Hi Peter,
>=20
>> You do have some XMPP experts on this list. :)
>=20
> Thanks for dropping by :-)
>=20
>> I'd be happy to have a chat with you and=20
>> anyone else who's interested so that we can figure out what=20
>> your requirements are and whether XMPP meets those=20
>> requirements (or can be extended to do so). Perhaps we can=20
>> set up a conference call in the near future?
>=20
> Having spoken to others off-line, I think that it is likely that
> defining a new lower-layer for EAP (while attractive in principle) will=

> introduce a host of other issues. Looking at this pragmatically, there
> is a strong argument for "better the devil you know".
>=20
> It could be that we end up defining a new EAP lower-layer if we fail
> with RadSec/RADIUS, but at least we'll be better informed having tried.=

Yes, that might make more sense. Depending on your requirements,
naturally. :)

> I am personally still interested in exploring this possibility, but I
> think we should consider this a 'research' topic and proceed with the
> SAML RADIUS Binding as originally proposed.
>=20
> In terms of having a call, I suggest that we wait until we have finishe=
d
> documenting the use-cases and the concrete technical proposal to addres=
s
> these. Hopefully Sam and I will have this done within 3 weeks or so.
> That will provide a dart-board that other ideas can take aim against.
>=20
> Thank you for your offer, and I look forward to having this discussion!=

How many Moonshot folks will be at IETF 77 in Anaheim? I'll be there so
I'd be happy to chat with you about it then.

Peter

--=20
Peter Saint-Andre
https://stpeter.im/

--------------ms040402020707010106020501
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms040402020707010106020501--

Date: Mon, 22 Feb 2010 15:32:37 -0500
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: SAML RADIUS Binding

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

Josh> Sam wrote:
>> First, I think the right technical approach is to ignore the
>> RADIUS MTU issue.

Josh> Would this be acceptable to IETF? Ot are you talking about the
Josh> implementation?

I was talking about the IETF.  However this statement was made before
reading your comment that an expert on RADIUS recommended against
ignoring the MTU issue.

Date: Mon, 22 Feb 2010 15:31:11 -0500
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: SAML RADIUS Binding

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

Scott> Sam Hartman wrote on 2010-02-22:
>> No, not an HMAC.  Alice tells bob over an authenticated channel
>> that she's going to send him a message with hash h.  Later,
>> through an arbitrary channel that better supports large messages
>> than the authenticated channel Alice sends a message with hash h.
>> On receiving that message, Bob knows it came from Alice because
>> if a strong cryptographic hash is used, then no party can find a
>> message other than the one Alice constructed that hashes to h.

Scott> Ok, this time you said "authenticated channel", while before
Scott> you said "integrity-protected". That's why I asked.

I think the terms are more or less interchangable when applied to a
channel.  Integrity protection is definitely useless without
authentication.  To be pedantic, it seems that RFC 2828 does not require
that authentication service implies data integrity service, but does
require that data integrity service implies authentication service.  So,
if you accept that lexicon, my original statement was more correct.

--Sam

Date: Mon, 22 Feb 2010 11:14:31 -0500
From: Scott Cantor <[email-masked]>
To: [email-masked]
Organization: The Ohio State University

Sam Hartman wrote on 2010-02-22:
> No, not an HMAC.  Alice tells bob over an authenticated channel that
> she's going to send him a message with hash h.  Later, through an
> arbitrary channel that better supports large messages than the
> authenticated channel Alice sends a message with hash h.  On receiving
> that message, Bob knows it came from Alice because if a strong
> cryptographic hash is used, then no party can find a message other than
> the one Alice constructed that hashes to h.

Ok, this time you said "authenticated channel", while before you said
"integrity-protected". That's why I asked.

-- Scott

Date: Mon, 22 Feb 2010 11:06:56 -0500
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: SAML RADIUS Binding

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

Scott> Sam Hartman wrote on 2010-02-22:
>> If signing the message is acceptable, then sending a hash of a
>> message over an integrity protected channel between the two SAML
>> peers should be OK too.

Scott> The signature is for authentication of the issuer of the
Scott> message. I don't really have enough experience to understand
Scott> how you can substitute different mechanisms for that, but
Scott> sending around hashes doesn't seem to be an authentication
Scott> solution unless it's an HMAC. Maybe that's what you meant.

No, not an HMAC.  Alice tells bob over an authenticated channel that
she's going to send him a message with hash h.  Later, through an
arbitrary channel that better supports large messages than the
authenticated channel Alice sends a message with hash h.  On receiving
that message, Bob knows it came from Alice because if a strong
cryptographic hash is used, then no party can find a message other than
the one Alice constructed that hashes to h.

This is effectively exactly what a digital signature does.  A signature
is a hugely expensive RSA channel that really cannot easily send
messages larger than the key size.  We want to sign a message larger
than a key (and get several other properties besides).
So, using  our RSA channel, we send a hash of the message.  Then using
any channel of our choice, we send the message.

--Sam

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

Sam Hartman wrote on 2010-02-22:
> If signing the message is acceptable, then sending a hash of a message
> over an integrity protected channel between the two SAML peers should be
> OK too.

The signature is for authentication of the issuer of the message. I don't
really have enough experience to understand how you can substitute different
mechanisms for that, but sending around hashes doesn't seem to be an
authentication solution unless it's an HMAC. Maybe that's what you meant.

-- Scott

Date: Mon, 22 Feb 2010 10:04:04 -0500
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: SAML RADIUS Binding

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

>> Josh previously wrote:
>> > Bad news. As I suspected, it is a requirement that the
>> call-back used to > the resolve the artifact is authenticated at
>> the transport layer.

Scott> Well, it doesn't have to be the transport layer...you can
Scott> sign the messages, for example. But the protocol as designed
Scott> is for two SAML peers to interact and authenticate each other
Scott> during the exchange so that the artifact is consumed by the
Scott> intended party and the message can be trusted.

If signing the message is acceptable, then sending a hash of a message
over an integrity protected channel between the two SAML peers should be
OK too.

Date: Mon, 22 Feb 2010 09:37:48 -0500
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: SAML RADIUS Binding

Replying to  the question about artifact resolution given that SAML
requires peer-entity authentication.

First, I think the right technical approach is to ignore the RADIUS MTU
issue.

If that proves problematic, I think including endpoint channel bindings
is preferred to establishing a key to include in the access-accept.
These bindings will be sufficient for authentication--in effect you're
just telling the other end what cert to expect.

Date: Mon, 22 Feb 2010 08:21:44 -0700
From: Peter Saint-Andre <[email-masked]>
To: [email-masked]
Subject: Re: SAML RADIUS Binding
micalg=sha1; boundary="------------ms040603030409010605010303"

This is a cryptographically signed message in MIME format.

--------------ms040603030409010605010303
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 2/18/10 2:53 AM, Josh Howlett wrote:
>> So as I suspected, this is about message size? XML =3D=3D bad fit=20
>> for size constrained protocols.
>=20
> EAP doesn't have any size constraints, but RADIUS (a common EAP
> transport) does. A RADIUS message is (essentially arbitarily, AFAICT)
> limited to 4kb. In some circumstances it is possible to fragment large
> payloads over multiple RADIUS messages, but only if the payload is part=

> of an on-going conversation. The last payload (which in this context
> will contain a SAML response/assertion) must fit completely into the
> final RADIUS message.=20
> =20
>>> We discussed various alternative strategies, including=20
>> Diameter, XMPP=20
>>> messaging, a lightweight XML schema over HTTP, or the use of WS-=20
>>> Securitybinary tokens. Stefan is leaning towards XML over HTTP, but=20
>>> XMPP looks more interesting to me.
>> =20
>> It might be more interesting, but are there compelling=20
>> functional advantages?
>=20
> I think these are the desirable technical properties & abstractions of
> the inter trust authority EAP transport protocol:
>=20
> - reliable transport.
> - mutual authentication of transport peers, ideally using GSS.
> - request / response message framing with multiple round-trips over a
> constant transport.
> - message types that can hold EAP packets, EAP keys & channel bindings
> and SAML request/response messages (by value).
> - message source/destination semantics.
> - message routing over multiple hops.
> - a conversation abtraction between peers seperated by multiple hops
> using multiple message round-trips
> - message and/or conversation and/or transport integrity &
> confidentiality.
> - message extensibility
>=20
> I believe that all of the strategies listed above have (or could be
> feasibility extended to have) these properties.
>=20
> I am presently leaning towards XMPP because (as I understand it) the
> base protocol (and perhaps also extensions like In-Band Bytestreams)
> gets us these properties without significant further profiling required=

> (c.f. use of WS-Security & binary security tokens, where very
> significant profiling would be required).

Hi Josh,

You do have some XMPP experts on this list. :)

Although naturally I am partial to XMPP, it's not always the best tool
for the job. Here I think that it meets most or all of your needs, but
to know for sure I'd need to know a bit more about what you mean in this
context by "reliable transport", "framing", "multiple hops",
"integrity", and "confidentiality". I'd be happy to have a chat with you
and anyone else who's interested so that we can figure out what your
requirements are and whether XMPP meets those requirements (or can be
extended to do so). Perhaps we can set up a conference call in the near
future?

Peter

--=20
Peter Saint-Andre
https://stpeter.im/

--------------ms040603030409010605010303
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms040603030409010605010303--

Date: Thu, 18 Feb 2010 19:06:05 -0000
From: Josh Howlett <[email-masked]>
To: [email-masked]
Subject: Re: SAML RADIUS Binding

Scott wrote:
> If the semantics are such that the assertion=20
> was delivered as part of that conversation, one possibility=20
> would be to deliver it as an assertion reference, not an=20
> artifact, and just dereference it using the Assertion lookup=20
> profile that's already in the spec, via HTTP. It really=20
> depends on the security semantics in play.

That makes a lot of sense. If you recall, the original approach was to
avoid authentication (which would imply a turtle issue) of the call-back
responder by attempting to match a hash claimed in the artifact to the
SAML message that it resolves. I believe we can achieve a semantically
equivalent effect by incorporating the same hash in the AssertionIdRef
value.

> One point to make is that if there's no AuthnRequest, there=20
> probably doesn't need to be a Response. So this is probably=20
> just an Assertion anyway.

I was originally quite keen to model this exchange as a SAML binding
(i.e. a vehicle for SAML request and response messages) in the hope that
we might define something of utility beyond this proposal. I guess there
is an argument that, given the idiosyncracies of the transport, dressing
this up as a binding that is semantically equivalent to those defined in
SAML2Bindings is something of a stretch and the Response therefore
doesn't add anything, as you say.

josh.

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

Date: Thu, 18 Feb 2010 14:32:29 -0500
From: Scott Cantor <[email-masked]>
To: [email-masked]
Organization: The Ohio State University

Josh Howlett wrote on 2010-02-18:
> That makes a lot of sense. If you recall, the original approach was to
> avoid authentication (which would imply a turtle issue) of the call-back
> responder by attempting to match a hash claimed in the artifact to the
> SAML message that it resolves. I believe we can achieve a semantically
> equivalent effect by incorporating the same hash in the AssertionIdRef
> value.

The AssertionIdRef is basically just consumed by the relying party, there
aren't any rules in the spec for processing it or decorating it. It's
designed for cases in which any concerns about the context of the reference
would be handled by that context. For example, in WSS, you can sign a
reference such that the actual signature is over the result of dereferencing
it, to maintain integrity.

I guess I just don't understand the need to avoid authentication. Without
authenticaton of the issuer, you can't trust the assertion anyway, it's just
data at that point. I'm assuming that the "turtle" problem is dealt with by
using traditonal trust mechanisms or by recursing things such that you get
an assertion from some other party to let you authenticate the first one.
You have to trust somebody to start with, and the runtime manifestation of
that is authentication.

-- Scott

Date: Thu, 18 Feb 2010 11:18:03 -0500
From: Scott Cantor <[email-masked]>
To: [email-masked]
Organization: The Ohio State University

Josh Howlett wrote on 2010-02-18:
>> So as I suspected, this is about message size? XML == bad fit
>> for size constrained protocols.
>
> EAP doesn't have any size constraints, but RADIUS (a common EAP
> transport) does. A RADIUS message is (essentially arbitarily, AFAICT)
> limited to 4kb. In some circumstances it is possible to fragment large
> payloads over multiple RADIUS messages, but only if the payload is part
> of an on-going conversation. The last payload (which in this context
> will contain a SAML response/assertion) must fit completely into the
> final RADIUS message.

Ok. Reminding myself of the roles in play here, is the RADIUS traffic
(ignoring proxies) basically between the IdP and an SP of some kind? If the
semantics are such that the assertion was delivered as part of that
conversation, one possibility would be to deliver it as an assertion
reference, not an artifact, and just dereference it using the Assertion
lookup profile that's already in the spec, via HTTP. It really depends on
the security semantics in play.

One point to make is that if there's no AuthnRequest, there probably doesn't
need to be a Response. So this is probably just an Assertion anyway.

-- Scott

Date: Thu, 18 Feb 2010 10:17:22 -0000
From: Mark O\'Leary <mark.o\[email-masked]>
To: [email-masked]
Subject: Re: SAML RADIUS Binding

> EAP doesn't have any size constraints, but RADIUS (a common EAP
> transport) does. A RADIUS message is (essentially arbitarily, AFAICT)
> limited to 4kb.

I think this dates back to the early days of dialup networking hardware,
when 'large' memory buffers for assembling the packets weren't cheap. It
underlines quite how old RADIUS is, and the compromises required to
accommodate modern scenarios. DIAMETER really should have gained more
traction, but we hold onto RADIUS like an arthritic, blind and
incontinent family dog... Then again, DIAMETER really should have been a
bit better at first release...

M.

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

Date: Thu, 18 Feb 2010 09:53:55 -0000
From: Josh Howlett <[email-masked]>
To: [email-masked]
Subject: Re: SAML RADIUS Binding

> So as I suspected, this is about message size? XML =3D=3D bad fit=20
> for size constrained protocols.

EAP doesn't have any size constraints, but RADIUS (a common EAP
transport) does. A RADIUS message is (essentially arbitarily, AFAICT)
limited to 4kb. In some circumstances it is possible to fragment large
payloads over multiple RADIUS messages, but only if the payload is part
of an on-going conversation. The last payload (which in this context
will contain a SAML response/assertion) must fit completely into the
final RADIUS message.=20
=20
> > We discussed various alternative strategies, including=20
> Diameter, XMPP=20
> > messaging, a lightweight XML schema over HTTP, or the use of WS-=20
> > Securitybinary tokens. Stefan is leaning towards XML over HTTP, but=20
> > XMPP looks more interesting to me.
>=20=20
> It might be more interesting, but are there compelling=20
> functional advantages?

I think these are the desirable technical properties & abstractions of
the inter trust authority EAP transport protocol:

- reliable transport.
- mutual authentication of transport peers, ideally using GSS.
- request / response message framing with multiple round-trips over a
constant transport.
- message types that can hold EAP packets, EAP keys & channel bindings
and SAML request/response messages (by value).
- message source/destination semantics.
- message routing over multiple hops.
- a conversation abtraction between peers seperated by multiple hops
using multiple message round-trips
- message and/or conversation and/or transport integrity &
confidentiality.
- message extensibility

I believe that all of the strategies listed above have (or could be
feasibility extended to have) these properties.

I am presently leaning towards XMPP because (as I understand it) the
base protocol (and perhaps also extensions like In-Band Bytestreams)
gets us these properties without significant further profiling required
(c.f. use of WS-Security & binary security tokens, where very
significant profiling would be required).

josh.

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

Date: Thu, 18 Feb 2010 00:01:18 -0500
From: Scott Cantor <[email-masked]>
To: [email-masked]
Subject: Re: SAML RADIUS Binding

This is a multi-part message in MIME format.

----16076f72871b14ef2a2f
Content-Type: text/html; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

=26gt=3B Josh previously wrote=3A=3CBR=3E=26gt=3B =26gt=3B Bad news=2E A=
s I suspected=2C it is a requirement that the=26nbsp=3Bcall-back used to=
=3CBR=3E=26gt=3B =26gt=3B the resolve the artifact is authenticated at t=
he transport layer=2E=3CBR=3E=26nbsp=3B=3CBR=3EWell=2C it doesn=27t have=
to be the transport layer=2E=2E=2Eyou can sign the messages=2C for exam=
ple=2E But the protocol as designed is for two SAML peers to interact an=
d authenticate each other during the exchange so that the artifact is co=
nsumed by the intended party and the message can be trusted=2E=3CBR=3E=3C=
BR=3E=26gt=3B =26gt=3B Scott=27s advice was to avoid artifact resolution=
=22at all=26nbsp=3Bcosts=22=2E=3CBR=3E=26nbsp=3B=3CBR=3ESpecifically=2C=
if possible avoid passing messages by reference instead of value=2C or =
if you must use references=2C start by figuring out your requirements an=
d designing the exchange=2C and only at that point would I start worryin=
g about whether it=27s the same or different from current artifacts=2E=3C=
BR=3E=26nbsp=3B=3CBR=3E=26gt=3B =26gt=3B 1=2E Ignore the RADIUS spec=27s=
MTU requirement=2E=2E=2E=3CBR=3E=26nbsp=3B=3CBR=3ESo as I suspected=2C =
this is about message size=3F XML =3D=3D bad fit for size constrained=26=
nbsp=3Bprotocols=2E=3CBR=3E=3CBR=3E=26gt=3B We discussed various alterna=
tive strategies=2C including Diameter=2C XMPP=3CBR=3E=26gt=3B messaging=2C=
a lightweight XML schema over HTTP=2C or the use of WS-=3CBR=3E=26gt=3B=
Securitybinary tokens=2E Stefan is leaning towards XML over HTTP=2C =3C=
BR=3E=26gt=3B but XMPP looks more interesting to me=2E=3CBR=3E=26nbsp=3B=
=3CBR=3EIt might be more interesting=2C but are there compelling functio=
nal advantages=3F=3CBR=3E=26nbsp=3B=3CBR=3E-- Scott=3CBR=3E=26nbsp=3B

----16076f72871b14ef2a2f--

Date: Wed, 17 Feb 2010 22:45:21 -0000
From: Josh Howlett <[email-masked]>
To: [email-masked]
Subject: Re: SAML RADIUS Binding

Josh previously wrote:
> Bad news. As I suspected, it is a requirement that the=20
> call-back used to
> the resolve the artifact is authenticated at the transport layer.
> Scott's advice was to avoid artifact resolution "at all costs". I see
> two possible options:
>=20
> 1. Ignore the RADIUS spec's MTU requirement...
>
> 2. TAS and TAC derive a new key for the artifact call-back from the
> established AAA context...

We discussed this issue at the Vienna meeting today.

Stefan Winter was clear that he thought that using RADSEC was a bad
idea, and that it would be cleaner to use another EAP lower layer for
transporting EAP between trust authorities. He believes that attempting
to manage the legacy RADIUS issues (primarily RADIUS MTU and attribute
size limitations) would result in major headaches.

We discussed various alternative strategies, including Diameter, XMPP
messaging, a lightweight XML schema over HTTP, or the use of WS-Security
binary tokens. Stefan is leaning towards XML over HTTP, but XMPP looks
more interesting to me. Could we model this by using XMPP and the EAP
GSS mechanism to establish the trust relationship between TAS and TAC,
and within this XMPP session transport EAP messages (plus SAML messages,
and derived EAP key and channel bindings) between C and TAC?

Unfortunately I don't enough about XMPP to understand whether it would
make a good EAP lower layer. I can't see why not in principle, but I
suspect there are aesthetic issues at the very least.

In addition, from an implementation perspective, ease of integration
with FreeRADIUS is probably the most critical consideration (for access
to the EAP machinery), but adding XMPP functionality to FreeRADIUS does
not seem a natural extension. I don't believe we want to gateway between
XMPP and RADIUS, as we introduce the issues of using RADIUS.

josh.

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

Date: Sat, 13 Feb 2010 16:58:55 -0000
From: Josh Howlett <[email-masked]>
To: [email-masked]
Subject: Re: SAML RADIUS Binding

Sam wrote:
> > Ah!  My terminology failure.  Can we include a hash of the SAML=20
> > message in the artifact or along side the artifact to get=20
> authenticity=20
> > of the SAML message?

Josh wrote:
> Probably. I've discovered an issue in the specification which=20
> might prevent this (there is a requirement to "authenticate"=20
> the issuer, which to me implies a demonstration of authority=20
> to wield a name; whereas in this instance we only need to=20
> demonstrate authority to wield a SAML message). I've emailed=20
> the SSTC list for clarification.

Bad news. As I suspected, it is a requirement that the call-back used to
the resolve the artifact is authenticated at the transport layer.
Scott's advice was to avoid artifact resolution "at all costs". I see
two possible options:

1. Ignore the RADIUS spec's MTU requirement, and use RadSec to transport
the SAML message by value over TCP. The argument for doing this is that
the RADIUS MTU makes sense for UDP, but not for TCP, and being dogmatic
about the RADIUS spec is going to significantly increase complexity.
There are sufficiently few RadSec implementations at the moment that
we're realistically unlikely to cause any actual harm. Most importantly,
it is also simple and robust. The argument for not doing this is that
we're abusing the RADIUS spec.

2. TAS and TAC derive a new key for the artifact call-back from the
established AAA context. TAS replicates a copy to S with the
Access-Accept, together with the artifact. S uses the key and the
artifact to resolve the SAML message.

Any other ideas?

josh.

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

Date: Fri, 12 Feb 2010 23:12:52 -0000
From: Josh Howlett <[email-masked]>
To: [email-masked]
Subject: Re: Actors

> There we're in complete agreement.  However, I view the need=20
> to support this sort of trust path discovery as very much a=20
> next stage issue.  The rest of the project seems squarely in=20
> the category of engineering work.

Agreed. It would be nice to have a story for 3 to 5 years hence, but as
you say it is important that we focus on engineering solutions to
demonstrable problems of today. I will try to control my enthusiasm for
fixing tomorrow's poorly-defined problems :-)

josh.

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

Date: Fri, 12 Feb 2010 22:10:50 -0000
From: Josh Howlett <[email-masked]>
To: [email-masked]
Subject: Re: Actors

> I think we're on the same page regarding actors.  I didn't=20
> see anything new in your definition of actors.

That's good. What followed that is the brain dump, and so I'm not too
surprised that you raise a number of issues with that.

I understand, in particular, your skepticism concerning trust path
discovery. I guess this boils down to personal opinion about the likely
future scale of federated systems. You're probably right that we could
live without trust path discovery purely within the European Higher
Education community over the next 2 or 3 years. However - on the
evidence of the adoption of federated identity within the HE community -
I believe that we're in the early stages of exponential growth. While
the absolute numbers are nowhere near Internet-scale at the moment, I
believe that it's only a matter of time. It will escape the petri dishes
of .gov, .edu, large .com, etc, and it I think it would be prudent to be
prepared.

josh.

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

Date: Fri, 12 Feb 2010 19:34:00 -0500
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Proposed bar BOF on federated authentication for non-web

I've been working with JaNet(UK) on providing a federation solution for
client applications such as mail readers, filesystem clients,
XMPP clients and the like.  There are fairly good solutions such as Open
ID, Information Card and SAML for web applications.  Within an
enterprise, you have Kerberos.

JaNet(UK) runs one of the world's largest SAML federations.  As their
customers are beginning to take advantage of federated access for web
applications they are also asking how they can gain the same flexibility
for client-server applications.  This customer demand appears to have
traction across the entire European academic community.  I suspect that
it may find traction within enterprises and other environments.

We'd like to have a bar BOF at IETF 77 in California with a goal of an
actual BOF this summer in Europe at IETF 78.  We invite you to join our
mailing list at
https://www.jiscmail.ac.uk/cgi-bin/webadmin?A0=moonshot-community  where
we can discuss timing.

We plan to discuss the general problem and a proposed solution at the
bar BOF.  I've already prepared a feasibility analysis for JaNet(UK)'s
solution; the analysis does discuss the problem some, gives an outline
of the solution and discusses technical issues and required standards
work in detail.  By IETF we'll have a use case paper, an internet draft
on the solution,and a slide set.

we look forward to your input.  You can find a bit more detail on my
blog at http://www.painless-security.com/blog/2010/02/12/moonshot1
You can find the feasibility analysis at
http://www.painless-security.com/wp/wp-content/uploads/2010/02/moonshot-feasibility-analysis.pdf

Thanks,

Sam Hartman
Painless Security

Date: Fri, 12 Feb 2010 18:28:10 -0500
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: Actors

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

>> There we're in complete agreement.  However, I view the need to
>> support this sort of trust path discovery as very much a next
>> stage issue.  The rest of the project seems squarely in the
>> category of engineering work.

Josh> Agreed. It would be nice to have a story for 3 to 5 years
Josh> hence, but as you say it is important that we focus on
Josh> engineering solutions to demonstrable problems of today. I
Josh> will try to control my enthusiasm for fixing tomorrow's
Josh> poorly-defined problems :-)

Well, let's just try to channel it into defining the problems:-)

Date: Fri, 12 Feb 2010 17:21:31 -0500
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: Actors

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

Josh> I understand, in particular, your skepticism concerning trust
Josh> path discovery. I guess this boils down to personal opinion
Josh> about the likely future scale of federated systems. You're
Josh> probably right that we could live without trust path discovery
Josh> purely within the European Higher Education community over the
Josh> next 2 or 3 years. However - on the evidence of the adoption
Josh> of federated identity within the HE community - I believe that
Josh> we're in the early stages of exponential growth. While the
Josh> absolute numbers are nowhere near Internet-scale at the
Josh> moment, I believe that it's only a matter of time. It will
Josh> escape the petri dishes of .gov, .edu, large .com, etc, and it
Josh> I think it would be prudent to be prepared.

There we're in complete agreement.  However, I view the need to support
this sort of trust path discovery as very much a next stage issue.  The
rest of the project seems squarely in the category of engineering work.
The trust path discovery may well be research.  So, I'm finding that I
need to approach the trust path discovery and try and understand
requirements and use cases.  Then I'll want to decompose it, build
logical interfaces, and understand how they fit together.  At that point
I'll be better able to discuss specific mechanisms.

--Sam

Date: Fri, 12 Feb 2010 12:46:13 -0500
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: Actors

I think we're on the same page regarding actors.  I didn't see anything
new in your definition of actors.

I think you may be confusing BGP confederations with BGP communities.
As I remember, a BGP community is an attribute attached to a route used
for local policy with no protocol level interpretation.  A confederation
is a set of ASes aggregated together to reduce BGP-level peering
complexity.  Or perhaps BGP communities are operationally used as you
describe?

I think separating the KNP and the TNP is a very good idea.  The KNP is
what we use for setting up a key used between a SAML metadata consumer
and target entity.  That seems like a good name for that protocol.
While the TNP has the same basic structure as the KNP it probably
carries different XML and is focused on AAA relationships not SAML
relationships.  There may be some links between the two protocols.

While I've read your comments about the trust graph and TML, I have not
fully digested them.  In particular, I don't understand the security
implications of the system, nor do I understand caching and performance
implications.  I also don't understand how much trust discovery is
actually required.  For example it seems like the European academic case
could be handled relatively simply.  Ask TAS through an untrusted
channel what authorities it accepts.  Give that list to your national
federation and move from there.  In other words, the more assumptions we
can make about the graph, the simpler our task.  So, while you have a
good theoretical model, I'm not sure how general of an implementation we
will need nor how soon.

Date: Thu, 11 Feb 2010 21:39:55 -0000
From: Josh Howlett <[email-masked]>
To: [email-masked]
Subject: Re: SAML RADIUS Binding

>     Josh> I'm not concerned about the authenticity of the=20
> artifact; let
>     Josh> us assume that we have satisfied that. I'm=20
> concerned about the
>     Josh> authenticity of the SAML message that we obtain when we
>     Josh> resolve the artifact. If the acceptor does not authenticate
>     Josh> the IdP, it could be obtaining an assertion from an=20
> issuer who
>     Josh> is not who they claim to be.
>=20
> Ah!  My terminology failure.  Can we include a hash of the=20
> SAML message in the artifact or along side the artifact to=20
> get authenticity of the SAML message?

Probably. I've discovered an issue in the specification which might
prevent this (there is a requirement to "authenticate" the issuer, which
to me implies a demonstration of authority to wield a name; whereas in
this instance we only need to demonstrate authority to wield a SAML
message). I've emailed the SSTC list for clarification.

josh.

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

Date: Thu, 11 Feb 2010 21:01:53 -0000
From: Josh Howlett <[email-masked]>
To: [email-masked]
Subject: Actors (was RE: SAML RADIUS Binding)

> I think we should reject a moonshot architecture that=20
> requires routing logic in servers for the same reason.

Agreed (as discussed on the phone earlier today).

> As an aside, I remain unconvinced that treating TAS and TAC=20
> as special architectural entities doesn't simplify the model=20
> in important ways.  I definitely agree that we should support=20
> a case where TAS gets close to S--definitely on the same=20
> machine, possibly in the same process.  I'm not sure though=20
> that we want to lose the model distinction.

Right. While we're on the subject, it's probably worth making sure our
conceptions about these actors' roles are still in sync.

Towards the end it turns into a brain dump, and some of those ideas we
have not properly discussed yet.

There is one class of actor that is the subject, and a second class of
actor that is the consumer of that subject's claimed identity (C and S
respectively). At a protocol level these are the EAP peer and
authenticator and GSS initiator and acceptor. Let's keep calling these
Client and Server because it is generally intuitive to think about them
in that way.

These actors are almost always AAA stubs, having a single AAA trust
relationship with a third class of actor that is trusted by other actors
in the system to make claims about the identities of the first two types
of actor. This is what we've been refering to as a trust authority (TA).

Trust authorities themselves may be trusted by other trust authorities
to make claims about clients and servers using a long-lived AAA trust
relationship.

If two trust authorities share such a relationship with a common trust
authority, they can bootstrap a short-lived trust relationship between
themselves using what we've been calling the "key negotiation protocol".
I think name is a bit misleading, and so I propose renaming this to the
"Trust Negotiation Protocol".

The Trust Negotiation Protocol is invoked when a Trust Authority wants
to send a message that it has received from a trusted Client, Service or
Trust Authority towards a destination that it does not share a direct
AAA trust relationship with.

Once a short-lived trust AAA relationship has been established, AAA
messages can be routed directly via this relationship towards their
destination.

These short-lived trust relationships are short-lived because neither
actor wants to be caught short for long if the common trust authority
decides that one is no longer trustworthy. A short-lived trust
relationship therefore expires after a period of time that was
negotiated using the Trust Negotiation Protocol. If another AAA message
appears that needs similar routing, the Trust Negotiation Protocol is
invoked again.

This pattern can be recursed any number of times, in principal, by
leveraging a short-term trust AAA relationship to establish another
short-term trust AAA relationship with any of the Trust Authorities with
which it shares a AAA trust relationships (long-lived or short-lived).

This allows a TA to discover, by recursing through the graph described
by these AAA trust relationships, other TAs which it does not share a
long-lived AAA trust relationship with.

Each TA advertises its short and long-lived AAA trust relationships
using the Trust Mark-up Language. The Trust Markup Languages enumerates
each short and long-lived AAA trust relationship held by the Trust
Authority, and their properties. Pertinent properties include:
- a AAA URI identifying the network location of the trust authority
- a tag identifying whether this is long-lived or short-lived (and time
to expiry)
- URIs naming the NAI realms and trust communities that this TA knows
about directly
- URIs naming the policies associated with this trust relationship
- the peer trust authority's own AAA trust relationships, and its AAA
trust relationships and properties, etc.

A trust community is conceptually similar to a BGP community. It's a way
of aggregating TAs (for example, all European research and education
TAs), rather than advertising each individually.

This information allows TAs to optimise their path through the trust
graph when searching for another TA.

The trust graph will consist of two layers: the first being composed of
the long-lived AAA trust relationships; the second being composed of a
much larger number of short-lived AAA trust relationships. The former is
relatively static, evolving slowly, reflecting the pace of real-life
business trust relationships. The latter is highly dynamic, a means of
(1) optimising the transit of AAA messages between TAs in the graph and
(2) allowing TAs that are widely separated on the former layer to find
each other.

josh.

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

Date: Thu, 11 Feb 2010 09:55:46 -0000
From: Josh Howlett <[email-masked]>
To: [email-masked]
Subject: Re: SAML RADIUS Binding

Sam wrote:
>     Josh> That's where I started from. But I think that it is cleanest
>     Josh> to fold TAS into S, and then use recursive discovery to walk
>     Josh> the trust graph from the start. For example, if necessary S
>     Josh> can walk to a local TA (for name authorisation) before
>     Josh> exploring the trust graph outside of the local=20
> trust domain to
>     Josh> find TAC.
>=20
> Ah, looks like we'll both be sleeping on something.  Making S=20
> be something more than a stub RADIUS client--actually having=20
> it interact with RADIUS entities other than TAC seems=20
> esthetically bad to me.
> I'll think on this.

I think we need to move away from the idea of TAS or TAC as having a
special role to play, and just consider them as a potential first
discovery hop from the S and C respectively.

To use a routing analogy, we would consider an IP architecture that
required the use of a particular first hop router to be broken. A host
might have a default router for unknown prefixes, but it should also be
able to pick between alternative routers for prefixes it does know
about.

Consequently, I think it is reasonabe to think about TAS and TAC as
being the default trust path for S and C respectively, but that if S or
C know a better path they should use that instead.

> Certainly if S talks to more than TAS, things get=20
> complicated.  For example the club really isn't in a position=20
> to kno whether S is allowed to speak for a particular name.

Not quite. S is allowed to talk to things other than TAS by virtue of
C's trust discovery path, which must involve some TA (perhaps TAS) that
is authoritative to assert S's right to claim a particular name.
Therefore, it is entirely possible for the club to exert this type of
policy.

The short-lived credentials that the trust authorities obtain as a
result of path path discovery do mean that there is a window in which
these entities might communicate, while one has been expelled from the
club, but this can be managed by each actor deciding how long it is
willing to cache the short-lived credential, before invoking trust path
discovery again (and discovering if that actor is still in the club, or
not).

In summary I would like to move away from the proxy model of the club
enforcing policy by applying policy on AAA packets in-flight, to a model
where the club enforces policy by applying policy on the key negotiation
that is used to obtain the AAA credentials for the end-to-end transport
of AAA packets.

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=20
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

Date: Thu, 11 Feb 2010 08:44:45 -0500
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: out until the call

I will be unavailable until our 1500 call.

Date: Thu, 11 Feb 2010 08:44:23 -0500
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: SAML RADIUS Binding

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

Josh> I think we need to move away from the idea of TAS or TAC as
Josh> having a special role to play, and just consider them as a
Josh> potential first discovery hop from the S and C respectively.

Josh> To use a routing analogy, we would consider an IP architecture
Josh> that required the use of a particular first hop router to be
Josh> broken. A host might have a default router for unknown
Josh> prefixes, but it should also be able to pick between
Josh> alternative routers for prefixes it does know about.

Josh> Consequently, I think it is reasonabe to think about TAS and
Josh> TAC as being the default trust path for S and C respectively,
Josh> but that if S or C know a better path they should use that
Josh> instead.

Ah!  Thanks for describing things this way.  It makes it clear exactly
where my concerns are.

Certainly an IP architecture that depended on using a certain first-hop
router would be of concern, although LISP and GSE do both fall somewhat
into this category.  (They both have distinguished routers that a path
must go through).

my problem is with requiring S to talk to a node other than TAS.  There
are a lot of good security and simplicity reasons that you want to
minimize the number of protocols, credentials and entities S needs to
talk to.  There are also latency and performance reasons that you want
to avoid S needing to set up credentials in real time.

In IP, we've discovered that there are important classes of node that
should only have a default router.  Many classes of small IP devices
have effectively only support for a default and localhost route.  We'd
reject an IP architecture that required more complexity than that in an
end-node.

I think we should reject a moonshot architecture that requires routing
logic in servers for the same reason.

Some servers may well have complicated routing, but requiring them all
to do so seems like a bad design.

Requiring a server to engage in a key management protocol to get an
artifact is doing exactly that.

As an aside, I remain unconvinced that treating TAS and TAC as special
architectural entities doesn't simplify the model in important ways.  I
definitely agree that we should support a case where TAS gets close to
S--definitely on the same machine, possibly in the same process.  I'm
not sure though that we want to lose the model distinction.

Date: Wed, 10 Feb 2010 22:56:13 -0000
From: Josh Howlett <[email-masked]>
To: [email-masked]
Subject: Re: SAML RADIUS Binding

Sam wrote:
>     >> The acceptor has the credential shared with the TAS (trust
>     >> authority near server for the archive).  The artifact is being
>     >> issued by the TAC (trust authority near client).  We could have
>     >> the acceptor start conversing directly with TAC and use EAP-GSS
>     >> to bootstrap a credential.
>=20
>     Josh> Right. This is what I was proposing with "recursive
>     Josh> discovery". TAS recurses through the trust graph until it
>     Josh> finds TAC, and they converse directly. Policy can=20
> be enforced
>     Josh> at any point along the trust graph so that if=20
> someone doesn't
>     Josh> want these entities talking, they can enforce that.
>=20
> I thought you were proposing that TAS obtain a credential with TAC.

That's where I started from. But I think that it is cleanest to fold TAS
into S, and then use recursive discovery to walk the trust graph from
the start. For example, if necessary S can walk to a local TA (for name
authorisation) before exploring the trust graph outside of the local
trust domain to find TAC.

> What we need for artifact resolution is for S to obtain a=20
> credential with TAC.
> So, S needs to be an X server, AAA client, artifact=20
> resolution client and  key management client.

Correct.

I think the AAA client and SAML artifact resolver are implemented in the
GSS library (and, of course, any downstream trust authorities that TAC
walks to).

I think the key management client is somehow invoked or implemented by
the TA. We need to figure out an approach to the key management client
that will cause minimum pain to application developers and deployers
(think shared web hosting environments, etc).

>     Josh> I'm not concerned about the authenticity of the=20
> artifact; let
>     Josh> us assume that we have satisfied that. I'm=20
> concerned about the
>     Josh> authenticity of the SAML message that we obtain when we
>     Josh> resolve the artifact. If the acceptor does not authenticate
>     Josh> the IdP, it could be obtaining an assertion from an=20
> issuer who
>     Josh> is not who they claim to be.
>=20
> Ah!  My terminology failure.  Can we include a hash of the=20
> SAML message in the artifact or along side the artifact to=20
> get authenticity of the SAML message?

Yes, that would work fine.

I think I still have a preference for the AAA approach for reasons
pertaining to SAML aesthetics, but I'm struggling to articulate these,
and your hashed-artifact approach is certainly cheaper. I'll sleep on it
:-)

Jumping back to where we started - the SAML RADIUS Binding - I think we
can call the actual mechanism used to establish trust for artifact
resolution out-of-scope for this spec. That's what the SAML
specification does for the HTTP Artifact binding. We can then profile it
in one of the higher-level specs.

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=20
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

Date: Wed, 10 Feb 2010 21:36:57 -0000
From: Josh Howlett <[email-masked]>
To: [email-masked]
Subject: Re: SAML RADIUS Binding

>     Josh> Given that we already have AAA credentials=20
>     Josh> established, we can
>     Josh> derive a second credential which provides a PSK for TLS.
>=20
> The acceptor has the credential shared with the TAS (trust=20
> authority near  server for the archive).  The artifact is=20
> being issued by the  TAC (trust authority near client).
> We could have the acceptor start conversing directly with TAC=20
> and use  EAP-GSS to bootstrap a credential.

Right. This is what I was proposing with "recursive discovery". TAS
recurses through the trust graph until it finds TAC, and they converse
directly. Policy can be enforced at any point along the trust graph so
that if someone doesn't want these entities talking, they can enforce
that.

> However that means the server needs to act both as a server=20
> and a client.

Do you mean a protocol X server and a AAA client? Wasn't that always the
case?

> That seems like a lot of complexity compared to transporting a hash.

I was assuming that we would be doing this anyway, as a means to
establish the AAA trust between TAC and TAS. If the credential for the
artifact resolution falls out of that, then it looks really cheap.

Perhaps we need to talk about the trust model again. Until we have a
common view of that, I suspect we're going to have many other similar
debates!
=20
>     Josh> How does the acceptor validate the responder's response? We
>     Josh> need mutual authentication, or another IdP could present an
>     Josh> arbitary response.
>=20
> I'm not sure we need mutual authentication all the time.  We=20
> need authentication from server to client.  We only need=20
> authentication from client to server  if we are concerned=20
> about some third party observing the artifact.

I'm not concerned about the authenticity of the artifact; let us assume
that we have satisfied that. I'm concerned about the authenticity of the
SAML message that we obtain when we resolve the artifact. If the
acceptor does not authenticate the IdP, it could be obtaining an
assertion from an issuer who is not who they claim to be.

> We could also just transport the hash or channel binding at=20
> the RADIUS level.

True.

josh.

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

Date: Wed, 10 Feb 2010 20:52:01 -0000
From: Josh Howlett <[email-masked]>
To: [email-masked]
Subject: Re: SAML RADIUS Binding

Moving this to moonshot-community...

On the possibility of expressing SAML assertion requirements to GSS-API,
Sam wrote:

> I think that required attributes could be a property of the=20
> acceptor name/credential for our mechanism.
> I think we want to ask Nico about the general case though.
>=20
>     Josh> to require authorisation data through the GSS-API, I think
>     Josh> there are a couple of fall-back strategies:
>=20
>=20
>=20
>     Josh>  1. Express this in system configuration for the=20
> GSS mechanism
>     Josh> on a per-application basis (for initiator X and acceptor Y,
>     Josh> request attribute statement Z).
>=20
> Well, the acceptor won't be in a position to make this depend=20
> on  initiator because the acceptor needs to send the=20
> access-request

Sorry, that was a dumb statement. I don't think this configuration
requires a priori knowledge of the initiator's identity.

>     Josh>  2. Rely on the IdP to issue an unsolicited assertion.

> I hope that we can use option 2 in a lot of cases.

I expect we will.

>     >> I'm somewhat nervous about the artifact authentication.  Are we
>     >> going to have credentials in common between the acceptor and
>     >> artifact issuer?  I think the answer is no.
>=20
>     Josh> I hadn't thought of that wrinkle. However, I think=20
> we do have
>     Josh> common credentials. The artifact issuer is the SAML IdP that
>     Josh> the acceptor has a AAA relationship with.=20
>=20
> I thought the artifact issuer was the user's IDP, not the=20
> server's IDP.
> How is the server's IDP in a position to know attributes=20
> about the user?

I explained myself poorly. The user's IdP issues the artifact, and the
server consumes it. The transfer of the artifact is performed over the
SAML RADIUS binding, for which we already have an AAA trust established.

Given that we already have AAA credentials established, we can derive a
second credential which provides a PSK for TLS.

>     >> Does SAML allow us to include a hash of the response in the
>     >> artifact so we can avoid needing authentication at the artifact
>     >> resolution protocol level?
>=20
>     Josh> We could do that by defining a new artifact format, but we
>     Josh> lose TLS protection of the HTTP transport used to=20
> transfer the
>     Josh> resolved SAML message, unless we use anonymous DH. In that
>     Josh> case, we have to rely on the SAML signature to establish
>     Josh> trust.
>=20
> I don't think that's true.  First, if we have a hash of the=20
> artifact, I don't think we need TLS for anything except=20
> confidentiality.  Just as with the metadata name, if we use=20
> the AAA infrastructure to tell us what artifact to expect, we=20
> don't need to trust the artifact transport.  If for some=20
> reason we decide we want to trust TLS then instead/addition=20
> to transporting an artifact hash we could transport a TLS=20
> endpoint channel binding.

How does the acceptor validate the responder's response? We need mutual
authentication, or another IdP could present an arbitary response.

Also, having consulted the spec, I was wrong about the possibility of
defining a new artifact with these semantics. This would require a
schema extension. This is a bit more invasive than I would like, but its
not a deal breaker.

josh.=20

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

Date: Wed, 10 Feb 2010 18:16:55 -0500
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: SAML RADIUS Binding

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

Josh> That's where I started from. But I think that it is cleanest
Josh> to fold TAS into S, and then use recursive discovery to walk
Josh> the trust graph from the start. For example, if necessary S
Josh> can walk to a local TA (for name authorisation) before
Josh> exploring the trust graph outside of the local trust domain to
Josh> find TAC.

Ah, looks like we'll both be sleeping on something.  Making S be
something more than a stub RADIUS client--actually having it interact
with RADIUS entities other than TAC seems esthetically bad to me.
I'll think on this.

Certainly if S talks to more than TAS, things get complicated.  For
example the club really isn't in a position to kno whether S is allowed
to speak for a particular name.

--Sam

Date: Wed, 10 Feb 2010 16:41:29 -0500
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: SAML RADIUS Binding

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

Josh> Given that we already have AAA credentials established, we can
Josh> derive a second credential which provides a PSK for TLS.
>>
>> The acceptor has the credential shared with the TAS (trust
>> authority near server for the archive).  The artifact is being
>> issued by the TAC (trust authority near client).  We could have
>> the acceptor start conversing directly with TAC and use EAP-GSS
>> to bootstrap a credential.

Josh> Right. This is what I was proposing with "recursive
Josh> discovery". TAS recurses through the trust graph until it
Josh> finds TAC, and they converse directly. Policy can be enforced
Josh> at any point along the trust graph so that if someone doesn't
Josh> want these entities talking, they can enforce that.

I thought you were proposing that TAS obtain a credential with TAC.
What we need for artifact resolution is for S to obtain a credential
with TAC.
So, S needs to be an X server, AAA client, artifact resolution client
and  key management client.

Josh> I'm not concerned about the authenticity of the artifact; let
Josh> us assume that we have satisfied that. I'm concerned about the
Josh> authenticity of the SAML message that we obtain when we
Josh> resolve the artifact. If the acceptor does not authenticate
Josh> the IdP, it could be obtaining an assertion from an issuer who
Josh> is not who they claim to be.

Ah!  My terminology failure.  Can we include a hash of the SAML message
in the artifact or along side the artifact to get authenticity of the
SAML message?

Date: Wed, 10 Feb 2010 16:11:59 -0500
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: SAML RADIUS Binding
10 Feb 2010 20:52:01 -0000")
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

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

Josh> I explained myself poorly. The user's IdP issues the artifact,
Josh> and the server consumes it. The transfer of the artifact is
Josh> performed over the SAML RADIUS binding, for which we already
Josh> have an AAA trust established.

Josh> Given that we already have AAA credentials established, we can
Josh> derive a second credential which provides a PSK for TLS.

The acceptor has the credential shared with the TAS (trust authority near
server for the archive).  The artifact is being issued by the
TAC (trust authority near client).
We could have the acceptor start conversing directly with TAC and use
EAP-GSS to bootstrap a credential.
However that means the server needs to act both as a server and a client.

That seems like a lot of complexity compared to transporting a hash.

>> >> Does SAML allow us to include a hash of the response in the >>
>> artifact so we can avoid needing authentication at the artifact
>> >> resolution protocol level?
>>
Josh> We could do that by defining a new artifact format, but we
Josh> lose TLS protection of the HTTP transport used to
>> transfer the
Josh> resolved SAML message, unless we use anonymous DH. In that
Josh> case, we have to rely on the SAML signature to establish
Josh> trust.
>>
>> I don't think that's true.  First, if we have a hash of the
>> artifact, I don't think we need TLS for anything except
>> confidentiality.  Just as with the metadata name, if we use the
>> AAA infrastructure to tell us what artifact to expect, we don't
>> need to trust the artifact transport.  If for some reason we
>> decide we want to trust TLS then instead/addition to transporting
>> an artifact hash we could transport a TLS endpoint channel
>> binding.

Josh> How does the acceptor validate the responder's response? We
Josh> need mutual authentication, or another IdP could present an
Josh> arbitary response.

I'm not sure we need mutual authentication all the time.  We need
authentication from server to client.  We only need authentication from
client to server  if we are concerned about some third party observing
the artifact.
So, how do we confirm that the artifact is genuine?
We accept any artifact whose contents hashes to the hash value we have.
We know that the hash is protected because we received it over the AAA
channel and that's integrity-protected.
The definition of a cryptographic hash function implies that no party
can easily generate a second artifact  with the same hash as the one we
received over the integrity protected channel: that directly follows
from second preimage resistance.

Now, authenticating the client to the server is a non-trivial concern as
well.  There are cases--the data protection laws are such a case--where
we want to avoid disclosing an artifact to the wrong party.  If the
artifact name is long enough then an attacker should not be able to
guess it.

Josh> Also, having consulted the spec, I was wrong about the
Josh> possibility of defining a new artifact with these
Josh> semantics. This would require a schema extension. This is a
Josh> bit more invasive than I would like, but its not a deal
Josh> breaker.

We could also just transport the hash or channel binding at the RADIUS
level.

Date: Wed, 10 Feb 2010 13:58:05 -0500
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: GSS and SAML attribute requests

Josh and I are looking at how to express the set of attributes an
acceptor is interested in in GSS-API.  In particular, we want a way to
inform the GSS mechanism what attributes that the acceptor should
request from the IDP.  In our mechanism, the acceptor is in a position
to interact with the IDP.  (In our mechanism, the client actually turns
out not to be in a position to interact with the IDP about attribute
release.)

Options I've thought of:

1) Use name attributes on the name that the acceptor passes into
gss_acquire_cred.

2) Some other mechanism-specific or generic extension to the
credentials.

Do you have any thoughts on the best way to approach this?

P.S.  You may want to join the moonshot-community lis; I will be
announcing it to kitten and [email-masked] among other places soon.

Date: Thu, 4 Feb 2010 16:04:17 -0000
From: Josh Howlett <[email-masked]>
To: [email-masked]
Subject: I forgot to mention...

The web interface for subscribing to this list is at:

https://www.jiscmail.ac.uk/cgi-bin/webadmin?A0=3Dmoonshot-community

To subscribe via email, send a message to [email-masked] with
the word subscribe in the body.

josh.

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

Date: Thu, 4 Feb 2010 16:01:41 -0000
From: Josh Howlett <[email-masked]>
To: [email-masked]
Subject: Moonshot-community mailing list

Dear all,

Sam suggested that we set up a list to support community discussion of
Moonshot. That is the purpose of this list. JANET(UK) related project
email should go to [email-masked].

The initial subscribers are:

Josh Howlett, JANET(UK)
Henry Hughes, JANET(UK)
Louis Seachwell, JANET(UK)
Mark O'Leary, JANET(UK)
Mark Tysom, JANET(UK)
Sam Hartman, Painless Security LLC=20

The mailing list archive is public and subscription is open.

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=20
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

Date: Sun, 28 Feb 2010 11:17:02 -0500
Comments: To: [email-masked]
To: [email-masked]
nico, I'm writing up the 00 draft of the moonshot mechanism based on a
draft I received from Josh.

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.

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?

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

--Sam

Date: Thu, 25 Feb 2010 19:05:32 -0500
Comments: cc: Thomas Hardjono <[email-masked]>
To: [email-masked]

Sam,

I plan to attend both. So it would be good to have them on separate
times/days.

cheers,

/thomas/

> -----Original Message-----
> From: Moonshot community list [mailto:[email-masked]]
On
> Behalf Of Sam Hartman
> Sent: Thursday, February 25, 2010 2:27 PM
> To: [email-masked]
> Subject: Federated authentication bar bof probably Thursday evening
>
> Folks, I've been talking to Vumip Khasnabish who is working on
> organizing a cloud computing bar bof. It seems that having cloud
> computing and federated authentication at the same time would be a bad
> idea: I suspect a lot of us want to go to both. Vumip was hoping that
> the clouds bof would land on Wednesday. If that happens I'd like to
> meet on Thursday.
>
> In terms of timing, I've never done this before. Do I want to do
> something like 9 PM-10:30 so people can grab a bite to eat before and so
> that those who wish may join the discussion of IPv6 deployment that will
> be ongoing by the time we conclude?
>
> --Sam

Date: Mon, 22 Feb 2010 08:21:44 -0700
Comments: cc: Josh Howlett <[email-masked]>
To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms040603030409010605010303
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 2/18/10 2:53 AM, Josh Howlett wrote:
>> So as I suspected, this is about message size? XML =3D=3D bad fit=20
>> for size constrained protocols.
>=20
> EAP doesn't have any size constraints, but RADIUS (a common EAP
> transport) does. A RADIUS message is (essentially arbitarily, AFAICT)
> limited to 4kb. In some circumstances it is possible to fragment large
> payloads over multiple RADIUS messages, but only if the payload is part=

> of an on-going conversation. The last payload (which in this context
> will contain a SAML response/assertion) must fit completely into the
> final RADIUS message.=20
> =20
>>> We discussed various alternative strategies, including=20
>> Diameter, XMPP=20
>>> messaging, a lightweight XML schema over HTTP, or the use of WS-=20
>>> Securitybinary tokens. Stefan is leaning towards XML over HTTP, but=20
>>> XMPP looks more interesting to me.
>> =20
>> It might be more interesting, but are there compelling=20
>> functional advantages?
>=20
> I think these are the desirable technical properties & abstractions of
> the inter trust authority EAP transport protocol:
>=20
> - reliable transport.
> - mutual authentication of transport peers, ideally using GSS.
> - request / response message framing with multiple round-trips over a
> constant transport.
> - message types that can hold EAP packets, EAP keys & channel bindings
> and SAML request/response messages (by value).
> - message source/destination semantics.
> - message routing over multiple hops.
> - a conversation abtraction between peers seperated by multiple hops
> using multiple message round-trips
> - message and/or conversation and/or transport integrity &
> confidentiality.
> - message extensibility
>=20
> I believe that all of the strategies listed above have (or could be
> feasibility extended to have) these properties.
>=20
> I am presently leaning towards XMPP because (as I understand it) the
> base protocol (and perhaps also extensions like In-Band Bytestreams)
> gets us these properties without significant further profiling required=

> (c.f. use of WS-Security & binary security tokens, where very
> significant profiling would be required).

Hi Josh,

You do have some XMPP experts on this list. :)

Although naturally I am partial to XMPP, it's not always the best tool
for the job. Here I think that it meets most or all of your needs, but
to know for sure I'd need to know a bit more about what you mean in this
context by "reliable transport", "framing", "multiple hops",
"integrity", and "confidentiality". I'd be happy to have a chat with you
and anyone else who's interested so that we can figure out what your
requirements are and whether XMPP meets those requirements (or can be
extended to do so). Perhaps we can set up a conference call in the near
future?

Peter

--=20
Peter Saint-Andre
https://stpeter.im/

--------------ms040603030409010605010303
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms040603030409010605010303--

Date: Wed, 10 Feb 2010 20:52:01 -0000
Comments: To: Sam Hartman <[email-masked]>
To: [email-masked]

Moving this to moonshot-community...

On the possibility of expressing SAML assertion requirements to GSS-API,
Sam wrote:

> I think that required attributes could be a property of the=20
> acceptor name/credential for our mechanism.
> I think we want to ask Nico about the general case though.
>=20
> Josh> to require authorisation data through the GSS-API, I think
> Josh> there are a couple of fall-back strategies:
>=20
>=20
>=20
> Josh> 1. Express this in system configuration for the=20
> GSS mechanism
> Josh> on a per-application basis (for initiator X and acceptor Y,
> Josh> request attribute statement Z).
>=20
> Well, the acceptor won't be in a position to make this depend=20
> on initiator because the acceptor needs to send the=20
> access-request

Sorry, that was a dumb statement. I don't think this configuration
requires a priori knowledge of the initiator's identity.

> Josh> 2. Rely on the IdP to issue an unsolicited assertion.

> I hope that we can use option 2 in a lot of cases.

I expect we will.

> >> I'm somewhat nervous about the artifact authentication. Are we
> >> going to have credentials in common between the acceptor and
> >> artifact issuer? I think the answer is no.
>=20
> Josh> I hadn't thought of that wrinkle. However, I think=20
> we do have
> Josh> common credentials. The artifact issuer is the SAML IdP that
> Josh> the acceptor has a AAA relationship with.=20
>=20
> I thought the artifact issuer was the user's IDP, not the=20
> server's IDP.
> How is the server's IDP in a position to know attributes=20
> about the user?

I explained myself poorly. The user's IdP issues the artifact, and the
server consumes it. The transfer of the artifact is performed over the
SAML RADIUS binding, for which we already have an AAA trust established.

Given that we already have AAA credentials established, we can derive a
second credential which provides a PSK for TLS.

> >> Does SAML allow us to include a hash of the response in the
> >> artifact so we can avoid needing authentication at the artifact
> >> resolution protocol level?
>=20
> Josh> We could do that by defining a new artifact format, but we
> Josh> lose TLS protection of the HTTP transport used to=20
> transfer the
> Josh> resolved SAML message, unless we use anonymous DH. In that
> Josh> case, we have to rely on the SAML signature to establish
> Josh> trust.
>=20
> I don't think that's true. First, if we have a hash of the=20
> artifact, I don't think we need TLS for anything except=20
> confidentiality. Just as with the metadata name, if we use=20
> the AAA infrastructure to tell us what artifact to expect, we=20
> don't need to trust the artifact transport. If for some=20
> reason we decide we want to trust TLS then instead/addition=20
> to transporting an artifact hash we could transport a TLS=20
> endpoint channel binding.

How does the acceptor validate the responder's response? We need mutual
authentication, or another IdP could present an arbitary response.

Also, having consulted the spec, I was wrong about the possibility of
defining a new artifact with these semantics. This would require a
schema extension. This is a bit more invasive than I would like, but its
not a deal breaker.

josh.=20

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

Date: Wed, 10 Feb 2010 16:11:59 -0500
Comments: To: Josh Howlett <[email-masked]>
To: [email-masked]
10 Feb 2010 20:52:01 -0000")

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

Josh> I explained myself poorly. The user's IdP issues the artifact,
Josh> and the server consumes it. The transfer of the artifact is
Josh> performed over the SAML RADIUS binding, for which we already
Josh> have an AAA trust established.

Josh> Given that we already have AAA credentials established, we can
Josh> derive a second credential which provides a PSK for TLS.

The acceptor has the credential shared with the TAS (trust authority near
server for the archive). The artifact is being issued by the
TAC (trust authority near client).
We could have the acceptor start conversing directly with TAC and use
EAP-GSS to bootstrap a credential.
However that means the server needs to act both as a server and a client.

That seems like a lot of complexity compared to transporting a hash.

>> >> Does SAML allow us to include a hash of the response in the >>
>> artifact so we can avoid needing authentication at the artifact
>> >> resolution protocol level?
>>
Josh> We could do that by defining a new artifact format, but we
Josh> lose TLS protection of the HTTP transport used to
>> transfer the
Josh> resolved SAML message, unless we use anonymous DH. In that
Josh> case, we have to rely on the SAML signature to establish
Josh> trust.
>>
>> I don't think that's true. First, if we have a hash of the
>> artifact, I don't think we need TLS for anything except
>> confidentiality. Just as with the metadata name, if we use the
>> AAA infrastructure to tell us what artifact to expect, we don't
>> need to trust the artifact transport. If for some reason we
>> decide we want to trust TLS then instead/addition to transporting
>> an artifact hash we could transport a TLS endpoint channel
>> binding.

Josh> How does the acceptor validate the responder's response? We
Josh> need mutual authentication, or another IdP could present an
Josh> arbitary response.

I'm not sure we need mutual authentication all the time. We need
authentication from server to client. We only need authentication from
client to server if we are concerned about some third party observing
the artifact.
So, how do we confirm that the artifact is genuine?
We accept any artifact whose contents hashes to the hash value we have.
We know that the hash is protected because we received it over the AAA
channel and that's integrity-protected.
The definition of a cryptographic hash function implies that no party
can easily generate a second artifact with the same hash as the one we
received over the integrity protected channel: that directly follows
from second preimage resistance.

Now, authenticating the client to the server is a non-trivial concern as
well. There are cases--the data protection laws are such a case--where
we want to avoid disclosing an artifact to the wrong party. If the
artifact name is long enough then an attacker should not be able to
guess it.

Josh> Also, having consulted the spec, I was wrong about the
Josh> possibility of defining a new artifact with these
Josh> semantics. This would require a schema extension. This is a
Josh> bit more invasive than I would like, but its not a deal
Josh> breaker.

We could also just transport the hash or channel binding at the RADIUS
level.

Date: Wed, 10 Feb 2010 13:58:05 -0500
Comments: To: [email-masked]
To: [email-masked]
Josh and I are looking at how to express the set of attributes an
acceptor is interested in in GSS-API. In particular, we want a way to
inform the GSS mechanism what attributes that the acceptor should
request from the IDP. In our mechanism, the acceptor is in a position
to interact with the IDP. (In our mechanism, the client actually turns
out not to be in a position to interact with the IDP about attribute
release.)

Options I've thought of:

1) Use name attributes on the name that the acceptor passes into
gss_acquire_cred.

2) Some other mechanism-specific or generic extension to the
credentials.

Do you have any thoughts on the best way to approach this?

P.S. You may want to join the moonshot-community lis; I will be
announcing it to kitten and [email-masked] among other places soon.

Date: Thu, 4 Feb 2010 16:04:17 -0000
To: [email-masked]
The web interface for subscribing to this list is at:

https://www.jiscmail.ac.uk/cgi-bin/webadmin?A0=3Dmoonshot-community

To subscribe via email, send a message to [email-masked] with
the word subscribe in the body.

josh.

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

Date: Thu, 4 Feb 2010 16:01:41 -0000
To: [email-masked]
Dear all,

Sam suggested that we set up a list to support community discussion of
Moonshot. That is the purpose of this list. JANET(UK) related project
email should go to [email-masked].

The initial subscribers are:

Josh Howlett, JANET(UK)
Henry Hughes, JANET(UK)
Louis Seachwell, JANET(UK)
Mark O'Leary, JANET(UK)
Mark Tysom, JANET(UK)
Sam Hartman, Painless Security LLC=20

The mailing list archive is public and subscription is open.

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=20
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

Date: Thu, 4 Feb 2010 15:48:19 -0000
To: [email-masked]
Test

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