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

<[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

- providing a clearer picture of how the technology would work from the
PoV of the various actors, and how it satifies their goals as described
in the use-case section.

- providing a bit more detail describing how the various technologies
are composed together.

- explaining how trust establishment could be made to work, in
practical operational and organisational terms, with the kinds of
properties (scaling, semantics, security properties & assumptions, etc)
that we're interested in.

Any other ideas where the document could be improved would be very
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

this works at an implementation level with GSS.  In particular, it seems
very undesirable to force all the cross-domain credentials out to
endpoints.

--Sam

From [email-masked]  Mon Dec 13 11:40:50 2010
From: Sam Hartman <[email-masked]>
To: [email-masked]
Date: Mon, 13 Dec 2010 14:42:19 -0500
Cc: [email-masked]
Subject: [abfab] Should gss-eap support empty target_name

Folks, GSS-API has two modes of naming acceptors.  The first is to
specify an explicit name in the call to gss_init_sec_context.  If
authentication succeeds, then the initiator knows that the acceptor is
the entity identified by that name.

The other option is to pass in no name.
In this optional mode, the initiator authenticates to the target. If
mutual authentication is requested, the initiator learns the name of the
target, but does not verify that name.

This can be used to support leap-of-faith style authentication.  An
application can remember the target name that was received and warn if
this name ever changes.

The first mode--specified target name--is required.  The second mode is
optional but recommended by RFC 2743.  I'm not aware of IETF protocols
that consume GSS-API and use the empty target name mode.

We've seen some discussion of these two modes and the tradeoffs between
them in the kitten WG recently.

Currently the gss-eap implementation and specification do not support
empty target_name.  (Nor does Kerberos nor the Kerberos derivatives.)

It's kind of complex for us to support this mode.  The problem is that
in order to verify the target name we'd need to know what it is in order
to pass it into EAP channel binding during the EAP authentication
process.  So, we somehow have to learn the target name from the acceptor
fairly early on.

Currently, we just exchange EAP tokens at that stage of the
authentication.
So, that would mean:

* Somehow indicate to the target/acceptor that we want to know the
  target name

* Add a new token where the acceptor tells us

This is kind of messy because you presumably want the token where we
learn the target name to be combined with an EAP token to avoid adding a
round trip.  That makes things a bit more annoying.

However if people are going to find this capability useful, we should do
it.  We could add support for empty target name later, but we could not
easily add graceful failure. If you wanted empty target name and the
other side didn't implement that, you'd probably get a fairly messy
failure.  (There are some heavy-weight mechanisms available like a new
mechanism OID, but that seems like a very big hammer for this.)

--Sam

From [email-masked]  Mon Dec 13 11:46:22 2010
From: Sam Hartman <[email-masked]>
To: [email-masked]
Date: Mon, 13 Dec 2010 14:47:54 -0500
Cc: [email-masked]
Subject: [abfab] Should GSS-EAP support server name indication?

Folks, while writing up my null target name mail, I realized there's
another question about support.

TLS has an extension where a client can indicate what it believes the
server name is before the authentication.  This allows name-based
virtual hosting among other things.

Right now, we don't support a similarconcept for GSS-EAP.

An IDP actually would be in a technical position to support aliases for the RP.
However, the IDP is in no position to actually know what the aliases
are.

So, if we do want to have virtual hosting, we probably need to have some
way to indicate the server name to the RP.

Do we need this?

From [email-masked]  Mon Dec 13 12:33:16 2010
Date: Mon, 13 Dec 2010 14:34:03 -0600
From: Nicolas Williams <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [abfab] Should GSS-EAP support server name indication?

On Mon, Dec 13, 2010 at 02:47:54PM -0500, Sam Hartman wrote:
> 
> 
> Folks, while writing up my null target name mail, I realized there's
> another question about support.
> 
> TLS has an extension where a client can indicate what it believes the
> server name is before the authentication.  This allows name-based
> virtual hosting among other things.
> 
> Right now, we don't support a similarconcept for GSS-EAP.
> 
> An IDP actually would be in a technical position to support aliases for the RP.
> However, the IDP is in no position to actually know what the aliases
> are.
> 
> So, if we do want to have virtual hosting, we probably need to have some
> way to indicate the server name to the RP.
> 
> Do we need this?

Yes, I believe that you do.

Nico
-- 

From [email-masked]  Mon Dec 13 12:47:21 2010
Date: Mon, 13 Dec 2010 14:48:46 -0600
From: Nicolas Williams <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [abfab] Should gss-eap support empty target_name

On Mon, Dec 13, 2010 at 02:42:19PM -0500, Sam Hartman wrote:
> Folks, GSS-API has two modes of naming acceptors.  The first is to
> specify an explicit name in the call to gss_init_sec_context.  If
> authentication succeeds, then the initiator knows that the acceptor is
> the entity identified by that name.
> 
> The other option is to pass in no name.
> [...]
> 
> This can be used to support leap-of-faith style authentication.  An
> application can remember the target name that was received and warn if
> this name ever changes.

I think this may be desirable for some mechanisms, particularly
PKI-based mechanisms, in at least some use cases.  Though even then it's
best, UI-wise, if the application knows the acceptor name a priori.

> The first mode--specified target name--is required.  The second mode is
> optional but recommended by RFC 2743.  I'm not aware of IETF protocols
> that consume GSS-API and use the empty target name mode.

Me either.

> We've seen some discussion of these two modes and the tradeoffs between
> them in the kitten WG recently.

Indeed.

> Currently the gss-eap implementation and specification do not support
> empty target_name.  (Nor does Kerberos nor the Kerberos derivatives.)
> 
> It's kind of complex for us to support this mode.  The problem is that
> in order to verify the target name we'd need to know what it is in order
> to pass it into EAP channel binding during the EAP authentication
> process.  So, we somehow have to learn the target name from the acceptor
> fairly early on.

I don't understand.  Since EAP is initiated by the server, surely you
get to use the first GSS round-trip to exchange the "I don't know your
name" / "my name is XYZ" messages, along with the initial EAP message.
Also, the acceptor's choice of name can't affect the construction of the
initial security context token, thus learning it from the first reply
token can't actually result in needing extra round-trips.

What am I missing?

> Currently, we just exchange EAP tokens at that stage of the
> authentication.

A stackable mechanism could be used, as a last resort, to get the
acceptor's name from the acceptor in a round-trip just for that
purpose...  It'd be better if the mechanism supported such a feature
natively.  I think the key question is: will ABFAB apps need this
feature?  I don't know the answer, which I suspect will depend on
context.

For the applications that I think you have in mind (e.g., traditional
SASL and GSS-API applications) there's no need for this feature (there's
a non-existence proof, as it were, of this assertion, no?  please
correct me if not).

> So, that would mean:
> 
> * Somehow indicate to the target/acceptor that we want to know the
>   target name
> 
> * Add a new token where the acceptor tells us

It'd be a whole new round-trip.  OTOH, since EAP is initiated by the
server...  the initial context token can't bear anything terribly
useful, and the first reply token sure could bear the acceptor name.

If you just provide a flags field in the initial security context token
and some framing in the first reply token, then I think you can revisit
this issue later, if you ever need to.  But if it's as simple as I'm
thinking it is, do it now.

Nico
-- 

From [email-masked]  Mon Dec 13 16:44:34 2010
From: "Cantor, Scott E." <[email-masked]>
To: Sam Hartman <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 14 Dec 2010 00:46:05 +0000
Accept-Language: en-US
Subject: Re: [abfab] Should gss-eap support empty target_name

On 12/13/10 2:42 PM, "Sam Hartman" <[email-masked]> wrote:
>This can be used to support leap-of-faith style authentication.  An
>application can remember the target name that was received and warn if
>this name ever changes.

What is it that the application is "remembering" (the analogy to the SSH
public key) across sessions?

-- Scott

From [email-masked]  Mon Dec 13 18:45:16 2010
From: "Cantor, Scott E." <[email-masked]>
To: "Henry B. Hotz" <[email-masked]>
Date: Tue, 14 Dec 2010 02:46:48 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [abfab] Should gss-eap support empty target_name

>IIUC it would be the GSS name (display form?) of the server.

So I'm basically connecting to some assumed service at a particular
endpoint, but not with a "known" GSS identity, and then I store the fact
that the assumed service identity is actually some particular GSS name so
any future connections use the name. Is that the idea?

Yes, that seems useful to me, but then I'm a believer in dumping
commercial CAs in favor of the certpatrol model too.

-- Scott

From [email-masked]  Tue Dec 14 04:37:13 2010
From: Sam Hartman <[email-masked]>
To: "Cantor\, Scott E." <[email-masked]>
Date: Tue, 14 Dec 2010 07:38:45 -0500
Cc: "[email-masked]" <[email-masked]>, "Henry B. Hotz" <[email-masked]>
Subject: Re: [abfab] Should gss-eap support empty target_name

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

    >> IIUC it would be the GSS name (display form?) of the server.
    Cantor,> So I'm basically connecting to some assumed service at a
    Cantor,> particular endpoint, but not with a "known" GSS identity,
    Cantor,> and then I store the fact that the assumed service identity
    Cantor,> is actually some particular GSS name so any future
    Cantor,> connections use the name. Is that the idea?

    Cantor,> Yes, that seems useful to me, but then I'm a believer in
    Cantor,> dumping commercial CAs in favor of the certpatrol model
    Cantor,> too.

That's the idea.

--Sam

From [email-masked]  Tue Dec 14 07:53:33 2010
Date: Tue, 14 Dec 2010 09:54:36 -0600
From: Nicolas Williams <[email-masked]>
To: "Cantor, Scott E." <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Henry B. Hotz" <[email-masked]>
Subject: Re: [abfab] Should gss-eap support empty target_name

On Tue, Dec 14, 2010 at 02:46:48AM +0000, Cantor, Scott E. wrote:
> >IIUC it would be the GSS name (display form?) of the server.
> 
> So I'm basically connecting to some assumed service at a particular
> endpoint, but not with a "known" GSS identity, and then I store the fact
> that the assumed service identity is actually some particular GSS name so
> any future connections use the name. Is that the idea?

To be more specific, the application would store a tuple consisting of
the "name" (or whatever) given by the user and either the display name
of, or better yet, exported name token form of the acceptor's actual
name, indexed by the former.  The "name" provided by the user needn't
resemble a hostname, though often it will be (and when it is I think
this feature has little value unless the mechanism has no way to
authenticate hostnames).

Nico
-- 

From [email-masked]  Mon Dec 13 18:06:58 2010
From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 13 Dec 2010 18:08:33 -0800
To: "Cantor, Scott E." <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [abfab] Should gss-eap support empty target_name

IIUC it would be the GSS name (display form?) of the server.

On Dec 13, 2010, at 4:46 PM, Cantor, Scott E. wrote:

> On 12/13/10 2:42 PM, "Sam Hartman" <[email-masked]> wrote:
>> This can be used to support leap-of-faith style authentication.  An
>> application can remember the target name that was received and warn if
>> this name ever changes.
> 
> What is it that the application is "remembering" (the analogy to the SSH
> public key) across sessions?
> 
> -- Scott

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

From [email-masked]  Tue Dec 14 13:56:12 2010
From: "Jim Schaad" <[email-masked]>
To: "'Nicolas Williams'" <[email-masked]>, "'Sam Hartman'" <[email-masked]>
Date: Tue, 14 Dec 2010 14:13:21 -0800
Cc: [email-masked], [email-masked]
Subject: Re: [abfab] Should GSS-EAP support server name indication?

+1

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Nicolas Williams
> Sent: Monday, December 13, 2010 12:34 PM
> To: Sam Hartman
> Cc: [email-masked]; [email-masked]
> Subject: Re: [abfab] Should GSS-EAP support server name indication?
> 
> On Mon, Dec 13, 2010 at 02:47:54PM -0500, Sam Hartman wrote:
> >
> >
> > Folks, while writing up my null target name mail, I realized there's
> > another question about support.
> >
> > TLS has an extension where a client can indicate what it believes the
> > server name is before the authentication.  This allows name-based
> > virtual hosting among other things.
> >
> > Right now, we don't support a similarconcept for GSS-EAP.
> >
> > An IDP actually would be in a technical position to support aliases for
the RP.
> > However, the IDP is in no position to actually know what the aliases
> > are.
> >
> > So, if we do want to have virtual hosting, we probably need to have
> > some way to indicate the server name to the RP.
> >
> > Do we need this?
> 
> Yes, I believe that you do.
> 
> Nico
> --
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

From [email-masked]  Tue Dec 14 14:04:24 2010
From: "Jim Schaad" <[email-masked]>
To: <[email-masked]>
Date: Tue, 14 Dec 2010 14:21:33 -0800
Subject: [abfab] Passing multiple SASL statements

At the f2f meeting, I said that I thought it was important that we have the
ability to pass multiple SASL statements as part of the AAA system.  I still
think this is a requirement.

A response was given from the chat room that this required that a
query/response be given as well.  I have been thinking on this both in this
context and in a different context and I have come to the conclusion that I
disagree with that statement.  It may be useful for a server to be able to
do a query for additional SASL statements but it is hardly required as there
are a number of ways this could be handled.  One way would be for the access
denied message to indicate what additional statements are required.

I can easily see situations where I cannot get all of the attributes needed
in a single SASL statement.  I can also see situations where I can know in
advance what statements are required.  This requires the ability to send
multiple statements but not a query/response ability.

That being said, I think that some type of query/response ability is
required in order to reduce the number of restarts of the protocol.  I don't
want to start it, get the denied, I need to have this as well three or four
times before finally getting access.  The computational and traffic loads
are going to be greater if one has to setup and tear down gss-api several
times.

Jim

From [email-masked]  Tue Dec 14 14:06:10 2010
From: Luke Howard <[email-masked]>
Date: Wed, 15 Dec 2010 09:07:33 +1100
To: Jim Schaad <[email-masked]>
Cc: [email-masked]
Subject: Re: [abfab] Passing multiple SASL statements

> I can easily see situations where I cannot get all of the attributes needed
> in a single SASL statement.  I can also see situations where I can 

You're talking about SAML, right?

You can have multiple SAML attribute statements in an assertion, does help?

-- Luke

From [email-masked]  Tue Dec 14 14:08:54 2010
Date: Tue, 14 Dec 2010 23:10:17 +0100
From: Leif Johansson <[email-masked]>
To: [email-masked]
Subject: Re: [abfab] Passing multiple SASL statements

On 12/14/2010 11:07 PM, Luke Howard wrote:
>> I can easily see situations where I cannot get all of the attributes needed
>> in a single SASL statement.  I can also see situations where I can 
> 
> You're talking about SAML, right?

That must be it. We were talking about SAML Response vs SAML Assertion.
I seem to recall that the room was in favour of using SAML Responses.
This was in the context of Josh's AAA draft.

	Cheers Leif

From [email-masked]  Tue Dec 14 14:12:09 2010
From: "Cantor, Scott E." <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 14 Dec 2010 22:13:31 +0000
Accept-Language: en-US
Subject: Re: [abfab] Passing multiple SASL statements

> At the f2f meeting, I said that I thought it was important that we have t=
he
> ability to pass multiple SASL statements as part of the AAA system.  I st=
ill
> think this is a requirement.

SASL, or SAML?

Assuming you mean the latter:

A SAML Response contains 0 to N Assertions.

A SAML Assertion is issued by exactly one authority, and can have any numbe=
r of Statements, but conventionally, just has one of any given type.

A SAML AttributeStatement has 1 to N Attributes.

So which are you proposing is needed?

> A response was given from the chat room that this required that a
> query/response be given as well.

I believe what I said was that a convenient way to carry multiple Assertion=
s within a single atomic structure defined by SAML is a Response. I didn't =
mean to imply that one couldn't frame multiple Assertions arbitrarily in so=
me other way, and I didn't mean to imply that using a Response implied a Qu=
ery or Request. It doesn't have to.

> I can easily see situations where I cannot get all of the attributes need=
ed
> in a single SASL statement.  I can also see situations where I can know i=
n
> advance what statements are required.  This requires the ability to send
> multiple statements but not a query/response ability.

The reality is that one channel exchanging data with one authority is not g=
oing to solve every problem anyway.

But, for clarification, I would pick a different word than Statement, that =
isn't the unit you want here.
=20
-- Scott

From [email-masked]  Tue Dec 14 14:19:24 2010
From: Sam Hartman <[email-masked]>
To: "Jim Schaad" <[email-masked]>
Date: Tue, 14 Dec 2010 17:20:49 -0500
Cc: [email-masked]
Subject: Re: [abfab] Passing multiple SAML statements

>>>>> "Jim" == Jim Schaad <[email-masked]> writes:

    Jim> At the f2f meeting, I said that I thought it was important that
    Jim> we have the ability to pass multiple SASL statements as part of
    Jim> the AAA system.  I still think this is a requirement.
Do you think multiple SAML responses are needed or  simply a single
 response containing potentially multiple assertions?

I'm in favor of multiple assertions in a response.
I think that supporting multiple responses provides significant trust
complexity, especially if the responses are from different parties.
This complexity is amplified when we try and provide access to
applications.
So, I'd prefer to avoid it.

    Jim> A response was given from the chat room that this required that
    Jim> a query/response be given as well.  I have been thinking on
    Jim> this both in this context and in a different context and I have
    Jim> come to the conclusion that I disagree with that statement.  

I also believe that supporting multiple assertions (or even multiple
responses) does not require a server query.

    Jim> It
    Jim> may be useful for a server to be able to do a query for
    Jim> additional SASL statements but it is hardly required as there
    Jim> are a number of ways this could be handled.  One way would be

This makes no sense at all.

The party sending the access-reject is the same party who would send the
SAML responses in the access-accept case.  It makes no sense for that
party to send an access-reject saying "here are other statements you
would need. I decided not to provide them so I denied your access."

From [email-masked]  Tue Dec 14 14:56:13 2010
From: "Jim Schaad" <[email-masked]>
To: "'Luke Howard'" <[email-masked]>
Date: Tue, 14 Dec 2010 15:13:17 -0800
Cc: [email-masked]
Subject: Re: [abfab] Passing multiple SASL statements

One of these days I will get back to using SAML for SAML.  I got confused
about 6 months ago and still have not managed to always come up with the
right one all of the time.

You can have multiple assertions in a single SAML statement, however you
might need assertions that are supplied by two different issuers.  In this
case you would need to have multiple SAML statements.  One would assume that
there would be a common assertion that is shared so that they could be
correlated.

Jim

> -----Original Message-----
> From: Luke Howard [mailto:[email-masked]]
> Sent: Tuesday, December 14, 2010 2:08 PM
> To: Jim Schaad
> Cc: [email-masked]
> Subject: Re: [abfab] Passing multiple SASL statements
> 
> > I can easily see situations where I cannot get all of the attributes
> > needed in a single SASL statement.  I can also see situations where I
> > can
> 
> You're talking about SAML, right?
> 
> You can have multiple SAML attribute statements in an assertion, does
help?
> 
> -- Luke

From [email-masked]  Tue Dec 14 15:01:25 2010
From: "Jim Schaad" <[email-masked]>
To: "'Cantor, Scott E.'" <[email-masked]>, <[email-masked]>
Date: Tue, 14 Dec 2010 15:18:31 -0800
Subject: Re: [abfab] Passing multiple SASL statements

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Cantor, Scott E.
> Sent: Tuesday, December 14, 2010 2:14 PM
> To: [email-masked]
> Subject: Re: [abfab] Passing multiple SASL statements
> 
> > At the f2f meeting, I said that I thought it was important that we
> > have the ability to pass multiple SASL statements as part of the AAA
> > system.  I still think this is a requirement.
> 
> SASL, or SAML?
> 
> Assuming you mean the latter:
> 
> A SAML Response contains 0 to N Assertions.
> 
> A SAML Assertion is issued by exactly one authority, and can have any
number
> of Statements, but conventionally, just has one of any given type.
> 
> A SAML AttributeStatement has 1 to N Attributes.
> 
> So which are you proposing is needed?
> 
> > A response was given from the chat room that this required that a
> > query/response be given as well.
> 
> I believe what I said was that a convenient way to carry multiple
Assertions
> within a single atomic structure defined by SAML is a Response. I didn't
mean
> to imply that one couldn't frame multiple Assertions arbitrarily in some
other
> way, and I didn't mean to imply that using a Response implied a Query or
> Request. It doesn't have to.

Then I managed to mis-hear what was said.  I was hearing that a
query/response was being suggested.  I am not sure that there would be any
benefit to using a response as a container rather than just allowing
multiple assertions to be transmitted individually.

> 
> > I can easily see situations where I cannot get all of the attributes
> > needed in a single SASL statement.  I can also see situations where I
> > can know in advance what statements are required.  This requires the
> > ability to send multiple statements but not a query/response ability.
> 
> The reality is that one channel exchanging data with one authority is not
going
> to solve every problem anyway.
> 
> But, for clarification, I would pick a different word than Statement, that
isn't
> the unit you want here.

You are correct.  I had my words backwards.  I meant to say multiple SAML
assertions.
> 
> -- Scott
> 
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

From [email-masked]  Tue Dec 14 15:07:48 2010
From: "Cantor, Scott E." <[email-masked]>
To: Jim Schaad <[email-masked]>, Luke Howard <[email-masked]>
Date: Tue, 14 Dec 2010 23:09:17 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [abfab] Passing multiple SASL statements

>You can have multiple assertions in a single SAML statement, however you
>might need assertions that are supplied by two different issuers.  In this
>case you would need to have multiple SAML statements.  One would assume
>that
>there would be a common assertion that is shared so that they could be
>correlated.

Your terms are off here, so it's very important to be clear. An assertion
has exactly one issuer, and you cannot combine statements from different
issuers in one assertion.

If you s/statement/Response, you'd have it, I think, but a Response also
comes from one Issuer. Given a profile allowing mixed issuers within the
Response's assertions, that's allowed, albeit complex.

-- Scott

From [email-masked]  Tue Dec 14 15:09:48 2010
From: "Cantor, Scott E." <[email-masked]>
To: Jim Schaad <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 14 Dec 2010 23:11:18 +0000
Accept-Language: en-US
Subject: Re: [abfab] Passing multiple SASL statements

>Then I managed to mis-hear what was said.  I was hearing that a
>query/response was being suggested.  I am not sure that there would be any
>benefit to using a response as a container rather than just allowing
>multiple assertions to be transmitted individually.

There may not be, and a Response has baggage of its own, it just depends
on the framing possible within the particular protocol.

For example, if a given framework allowed only a single value for some
attribute or property that was used to mean "SAML assertion", you'd have a
problem handling >1.

-- Scott

From [email-masked]  Tue Dec 14 15:12:34 2010
From: "Jim Schaad" <[email-masked]>
To: "'Sam Hartman'" <[email-masked]>
Date: Tue, 14 Dec 2010 15:29:45 -0800
Cc: [email-masked]
Subject: Re: [abfab] Passing multiple SAML statements

Sam,

I need to get my terms in agreement with others so that I can make sure we
are talking the same language.  This is part of the problem of not having
lived in the specifications for long enough but just dipping into them
occasionally as needed.

What I thought was a statement appears to be a SAML assertion.  That is an
atomic unit that is signed by a single entity and contains multiple (what I
thought of as an assertion) statements about an individual.

When I was dealing with the question of responses - I was only thinking of a
query/response protocol rather than just an xml data carrying unit.

> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]]
> Sent: Tuesday, December 14, 2010 2:21 PM
> To: Jim Schaad
> Cc: [email-masked]
> Subject: Re: [abfab] Passing multiple SAML statements
> 
> >>>>> "Jim" == Jim Schaad <[email-masked]> writes:
> 
>     Jim> At the f2f meeting, I said that I thought it was important that
>     Jim> we have the ability to pass multiple SASL statements as part of
>     Jim> the AAA system.  I still think this is a requirement.
> Do you think multiple SAML responses are needed or  simply a single
response
> containing potentially multiple assertions?

I believe that one needs to be able to get multiple SAML assertions - from
different entities - for some policies to be correctly enforced.  This is
because a single assertion issuer may not be authoritative for all
statements.

> 
> I'm in favor of multiple assertions in a response.
> I think that supporting multiple responses provides significant trust
complexity,
> especially if the responses are from different parties.
> This complexity is amplified when we try and provide access to
applications.
> So, I'd prefer to avoid it.

I don't see a great complexity being added unless that enforcement policy
needs it.  For most applications it is sufficient for a single entity to be
able to issue the statements.  However, I don't believe that it is
sufficient.  If one looks at the old X.509 world there is a distinction that
was made between identity certificates and attribute certificates for a
reason. 

> 
> 
> 
>     Jim> A response was given from the chat room that this required that
>     Jim> a query/response be given as well.  I have been thinking on
>     Jim> this both in this context and in a different context and I have
>     Jim> come to the conclusion that I disagree with that statement.
> 
> I also believe that supporting multiple assertions (or even multiple
> responses) does not require a server query.
> 
>     Jim> It
>     Jim> may be useful for a server to be able to do a query for
>     Jim> additional SASL statements but it is hardly required as there
>     Jim> are a number of ways this could be handled.  One way would be
> 
> This makes no sense at all.
> 
> The party sending the access-reject is the same party who would send the
> SAML responses in the access-accept case.  It makes no sense for that
party to
> send an access-reject saying "here are other statements you would need. I
> decided not to provide them so I denied your access."

If this is true then I have fundamentally mis-understood the entire model
and need to go back and re-read it.  I was assuming that what happens is
that I send a request to a service, supplying credentials in the form of
SAML assertions and that service will either accept or reject my request
based on the supplied credentials.  In that case the entity supplying the
service could say you are denied because you did not give me an X
credential, or just ask back for one using a query/response protocol either
to me or yet another party. 

Jim

From [email-masked]  Tue Dec 14 16:33:50 2010
From: Sam Hartman <[email-masked]>
To: "Jim Schaad" <[email-masked]>
Date: Tue, 14 Dec 2010 19:35:18 -0500
Cc: [email-masked]
Subject: Re: [abfab] Passing multiple SAML statements

Jim, I believe it will be quite challenging to support assertions from
multiple different issuers in the initial ABFAb authentication.

It sounds like you want to support this.  I'm going to ask you to work
through the details especially at the behavior of the GSS acceptor and
of the interactions with GSS name attributes.
Once you've worked through that  then I think we can evaluate the
complexity tradeoff.

I'm happy to help you understand the current state so you can understand
how it would need to change.

Does this sound fair?

--Sam

From [email-masked]  Tue Dec 14 16:54:54 2010
From: "Jim Schaad" <[email-masked]>
To: "'Sam Hartman'" <[email-masked]>
Date: Tue, 14 Dec 2010 17:12:06 -0800
Cc: [email-masked]
Subject: Re: [abfab] Passing multiple SAML statements

That sounds fair.

> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]]
> Sent: Tuesday, December 14, 2010 4:35 PM
> To: Jim Schaad
> Cc: [email-masked]
> Subject: Re: [abfab] Passing multiple SAML statements
> 
> Jim, I believe it will be quite challenging to support assertions from
multiple
> different issuers in the initial ABFAb authentication.
> 
> It sounds like you want to support this.  I'm going to ask you to work
through the
> details especially at the behavior of the GSS acceptor and of the
interactions
> with GSS name attributes.
> Once you've worked through that  then I think we can evaluate the
complexity
> tradeoff.
> 
> I'm happy to help you understand the current state so you can understand
how
> it would need to change.
> 
> Does this sound fair?
> 
> --Sam

From [email-masked]  Wed Dec 15 01:01:53 2010
From: Josh Howlett <[email-masked]>
To: Sam Hartman <[email-masked]>, Jim Schaad <[email-masked]>
Date: Wed, 15 Dec 2010 09:03:47 +0000
Accept-Language: en-GB, en-US
Cc: Josh Howlett <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] Passing multiple SAML statements

Sam,

I think Jim's requirements can be satisfied with the approach we discussed =
in private email a few days ago with Luke: SAML Requests and Responses tran=
sported in a distinct AAA transaction that follows the AAA transaction for =
the EAP authentication, routed using an NAI that names the subject and the =
realm. I think Luke confirmed that the GSS interactions wouldn't be prohibi=
tively difficult.

A SAML requester can trivially obtain assertions from N providers by invoki=
ng the AAA transaction N times.

We concluded that a RADIUS Access-Request that didn't contain any authentic=
ation data (it would only contain the User-Name and the SAML-Message attrib=
utes) *might* transgress the spirit of the RADIUS spec.

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

From [email-masked]  Wed Dec 15 01:21:19 2010
Date: Wed, 15 Dec 2010 10:22:58 +0100
From: Alan DeKok <[email-masked]>
To: Josh Howlett <[email-masked]>
Cc: Jim Schaad <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] Passing multiple SAML statements

Josh Howlett wrote:
> We concluded that a RADIUS Access-Request that didn't contain any authentication data (it would only contain the User-Name and the SAML-Message attributes) *might* transgress the spirit of the RADIUS spec.

  Yes.

  What *is* possible is to have an initial authentication, and then to
have the Access-Accept contain a State attribute.  Subsequent
*authorizations* can use that State, along with "Service-Type =
Authorize-Only", to get additional / different authorizations.

  This is deployed and is allowed by the specs, but isn't described in
detail anywhere.

  Alan DeKok.

From [email-masked]  Wed Dec 15 01:37:58 2010
From: Josh Howlett <[email-masked]>
To: Alan DeKok <[email-masked]>
Date: Wed, 15 Dec 2010 09:39:33 +0000
Accept-Language: en-GB, en-US
Cc: Josh Howlett <[email-masked]>, Jim Schaad <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] Passing multiple SAML statements

> > We concluded that a RADIUS Access-Request that didn't contain any
> > authentication data (it would only contain the User-Name and the SAML-
> > Message attributes) *might* transgress the spirit of the RADIUS spec.
>=20
>   Yes.
>=20
>   What *is* possible is to have an initial authentication, and then to
> have the Access-Accept contain a State attribute.  Subsequent
> *authorizations* can use that State, along with "Service-Type =3D
> Authorize-Only", to get additional / different authorizations.

And these subsequent authorisations are requested in a RADIUS Access-Reques=
t message?

Thanks, 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

From [email-masked]  Wed Dec 15 02:46:19 2010
Date: Wed, 15 Dec 2010 11:48:00 +0100
From: Alan DeKok <[email-masked]>
To: Josh Howlett <[email-masked]>
Cc: Jim Schaad <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] Passing multiple SAML statements

Josh Howlett wrote:
>>   What *is* possible is to have an initial authentication, and then to
>> have the Access-Accept contain a State attribute.  Subsequent
>> *authorizations* can use that State, along with "Service-Type =
>> Authorize-Only", to get additional / different authorizations.
> 
> And these subsequent authorisations are requested in a RADIUS Access-Request message?

  Yes.

  They should also include "session identification attributes", like
User-Name, and anything else that might seem useful...

  Alan DeKok.

From [email-masked]  Wed Dec 15 03:40:24 2010
From: Josh Howlett <[email-masked]>
To: Alan DeKok <[email-masked]>
Date: Wed, 15 Dec 2010 11:41:58 +0000
Accept-Language: en-GB, en-US
Cc: Josh Howlett <[email-masked]>, Jim Schaad <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] Passing multiple SAML statements

>   What *is* possible is to have an initial authentication, and then to
> have the Access-Accept contain a State attribute.  Subsequent
> *authorizations* can use that State, along with "Service-Type =3D
> Authorize-Only", to get additional / different authorizations.
>=20
>   This is deployed and is allowed by the specs, but isn't described in
> detail anywhere.

Is it described in at least /some/ level of detail somewhere, or should I g=
o read the FreeRADIUS source?

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

From [email-masked]  Wed Dec 15 03:51:53 2010
Date: Wed, 15 Dec 2010 12:53:34 +0100
From: Alan DeKok <[email-masked]>
To: Josh Howlett <[email-masked]>
Cc: Jim Schaad <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] Passing multiple SAML statements

Josh Howlett wrote:
>>   This is deployed and is allowed by the specs, but isn't described in
>> detail anywhere.
> 
> Is it described in at least /some/ level of detail somewhere, or should I go read the FreeRADIUS source?

  It's hinted at in various places.  RFC 5080, Section 2.1.1.  RFC 5176
Section 3.2 discusses it, but in the context of CoA packets.  RFC 5580
discusses it, too.

  There are no configuration examples available because it's not widely
used outside of large WiMAX and 3G systems.

  Alan DeKok.

From [email-masked]  Thu Dec 16 11:45:56 2010
From: Sam Hartman <[email-masked]>
To: [email-masked]
Date: Thu, 16 Dec 2010 14:47:24 -0500
Subject: [abfab] SAML attribute queries: AAA or SOAP

Josh has been pondering some of the longer-term scalability issues of
ABFAB and SAML.

In order for SAML communication to happen, the entities involved need
SAML metadata.  For example, an RP needs metadata in order to know how
to contact an IDP and in order to understand scope restrictions on
identifiers used by an IDP.
We'd been assuming that we would eventually need to build a protocol to
exchange SAML metadata in a scalable manner leveraging the AAA fabric.

However, Josh has recently been exploring the idea of simply using SAML
over the AAA fabric directly.

As Josh and Alan discussed earlier this week, RADIUS supports an
authorization-only service that can be used to request additional
authorization information.   It's my understanding that Diameter
applications can do something similar.

So, Josh is proposing that we permit sending SAML attribute queries over
AAA transport. An application would decide it needed attributes and this
would generate a authorization only request for these attributes; the
response would be processed.

Josh is hoping to get away without needing SAML metadata.

This is similar in motivation to a previous proposal we had: the
alternative security mechanism. In that proposal, we used AAA to set up
keys for SAML messages.  We dropped that proposal because other aspects
of the metadata that we'd need were not handled by that proposal and
because the scalable metadata protocol would be a better approach..

One question is to what extent does using AAA as a transport for SAML
messages actually address all the reasons we need metadata.  Another
question is is this actually easier to specify and implement than a
metadata distribution protocol.

I'm bringing this up now to get Scott, Leif and others into the
discussion.
I'm sure I'm leaving details out; in many cases it's because I don't
have them. We just went over the general proposal on a call this
morning.

Also, I'm not entirely sure that this is really an abfab issue rather
than a moonshot issue. I decided to post to the IETF list because it may
have some standardization implications and I think we'll get a broader
group here.

--Sam

From [email-masked]  Thu Dec 16 12:34:44 2010
From: Sam Hartman <[email-masked]>
To: Nicolas Williams <[email-masked]>
Date: Thu, 16 Dec 2010 15:36:16 -0500
Cc: [email-masked], [email-masked]
Subject: Re: [abfab] Should gss-eap support empty target_name

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

    Nicolas> If you just provide a flags field in the initial security
    Nicolas> context token and some framing in the first reply token,
    Nicolas> then I think you can revisit this issue later, if you ever
    Nicolas> need to.  But if it's as simple as I'm thinking it is, do
    Nicolas> it now.

My concern about complexity was avoiding the framing in the context
token.  Currently we have no framing except for the extension token.
Adding that involves either always having framing or deciding when not
to have framing as well as deciding what to do with tokens received in
the framing, etc.

However in the grand scheme of things that is not a huge cost.

--Sam

From [email-masked]  Thu Dec 16 12:50:11 2010
Date: Thu, 16 Dec 2010 14:51:48 -0600
From: Nicolas Williams <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [abfab] Should gss-eap support empty target_name

On Thu, Dec 16, 2010 at 03:36:16PM -0500, Sam Hartman wrote:
>     Nicolas> If you just provide a flags field in the initial security
>     Nicolas> context token and some framing in the first reply token,
>     Nicolas> then I think you can revisit this issue later, if you ever
>     Nicolas> need to.  But if it's as simple as I'm thinking it is, do
>     Nicolas> it now.
> 
> My concern about complexity was avoiding the framing in the context
> token.  Currently we have no framing except for the extension token.
> Adding that involves either always having framing or deciding when not
> to have framing as well as deciding what to do with tokens received in
> the framing, etc.
> 
> However in the grand scheme of things that is not a huge cost.

You're reminding me about the 640KB problem.  Why paint yourself into a
corner?  Just to save a few branches??  Economically, I don't see the
point.

Nico
-- 

From [email-masked]  Thu Dec 16 13:17:41 2010
Date: Thu, 16 Dec 2010 22:19:20 +0100
From: Leif Johansson <[email-masked]>
To: [email-masked]
Subject: Re: [abfab] SAML attribute queries: AAA or SOAP

With no chair hat on whatsoever ...

That depends on what you think you want metadata for. If you only think
about metadata as a way to provide location-identifier indepencence then
you may be right that SAML over AAA is good enough.

However SAML metadata gets you a bunch of things beyond a well known
protocol endpoint. One of them is key-management but other things might
also become important for abfab eventually such as contact information
and various UI hints.

	Cheers Leif

From [email-masked]  Thu Dec 16 13:17:41 2010
Date: Thu, 16 Dec 2010 22:19:20 +0100
From: Leif Johansson <[email-masked]>
To: [email-masked]
Subject: Re: [abfab] SAML attribute queries: AAA or SOAP

With no chair hat on whatsoever ...

> One question is to what extent does using AAA as a transport for SAML
> messages actually address all the reasons we need metadata.  Another
> question is is this actually easier to specify and implement than a
> metadata distribution protocol.

That depends on what you think you want metadata for. If you only think
about metadata as a way to provide location-identifier indepencence then
you may be right that SAML over AAA is good enough.

However SAML metadata gets you a bunch of things beyond a well known
protocol endpoint. One of them is key-management but other things might
also become important for abfab eventually such as contact information
and various UI hints.

	Cheers Leif

From [email-masked]  Thu Dec 16 13:21:35 2010
From: Sam Hartman <[email-masked]>
To: Leif Johansson <[email-masked]>
Date: Thu, 16 Dec 2010 16:23:05 -0500
Cc: [email-masked]
Subject: Re: [abfab] SAML attribute queries: AAA or SOAP

>>>>> "Leif" == Leif Johansson <[email-masked]> writes:

    Leif> With no chair hat on whatsoever ...

    >> One question is to what extent does using AAA as a transport for
    >> SAML messages actually address all the reasons we need metadata.
    >> Another question is is this actually easier to specify and
    >> implement than a metadata distribution protocol.

    Leif> That depends on what you think you want metadata for. If you
    Leif> only think about metadata as a way to provide
    Leif> location-identifier indepencence then you may be right that
    Leif> SAML over AAA is good enough.

    Leif> However SAML metadata gets you a bunch of things beyond a well
    Leif> known protocol endpoint. One of them is key-management but
    Leif> other things might also become important for abfab eventually
    Leif> such as contact information and various UI hints.

And this is the discussion I want to see happen here.
I'm not going to be much of a participant; I don't have the background.

From [email-masked]  Thu Dec 16 13:24:37 2010
From: "Cantor, Scott E." <[email-masked]>
To: Leif Johansson <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 16 Dec 2010 21:26:19 +0000
Accept-Language: en-US
Subject: Re: [abfab] SAML attribute queries: AAA or SOAP

> However SAML metadata gets you a bunch of things beyond a well known
> protocol endpoint. One of them is key-management but other things might
> also become important for abfab eventually such as contact information
> and various UI hints.

I think Moonshot at least has been on record looking for AAA alternatives t=
o metadata-based key management, so I doubt that's a selling point.

A lot of the typical uses probably go away if the AAA infrastructure handle=
s everything. Attribute policy might be an exception, but metadata isn't th=
e only way to drive that (and that's typically attribute *source* metadata,=
 and the usual complaints about using metadata relate to the relying party =
having to make it available to the IdP/AA, not the other way around. Even O=
penID doesn't pretend knowing the OP is somehow irrelevant.)

I suspect that this would be an adequate substitute for relying party metad=
ata, and that metadata for the other end would be needed less, and could st=
ill be provided without complicating things very much.

-- Scott

From [email-masked]  Thu Dec 16 13:25:11 2010
From: Sam Hartman <[email-masked]>
To: Nicolas Williams <[email-masked]>
Date: Thu, 16 Dec 2010 16:26:45 -0500
Cc: [email-masked], [email-masked]
Subject: Re: [abfab] Should gss-eap support empty target_name

Any opinions on whether we always frame or never frame?
Or should we just use an AVP structure for all tokens with a special AVP
for EAP tokens?
What's the behavior on receiving something unexpected?

--Sam

From [email-masked]  Thu Dec 16 13:28:39 2010
Date: Thu, 16 Dec 2010 15:30:16 -0600
From: Nicolas Williams <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked]
Subject: Re: [abfab] SAML attribute queries: AAA or SOAP

On Thu, Dec 16, 2010 at 02:47:24PM -0500, Sam Hartman wrote:
> One question is to what extent does using AAA as a transport for SAML
> messages actually address all the reasons we need metadata.  Another
> question is is this actually easier to specify and implement than a
> metadata distribution protocol.

You mention SOAP, but only in the subject line.  Would SOAP be the
alternative transport?  If so, given that you'll need AAA anyways, why
add one more protocol to this mix?  It certainly wouldn't make
implementation easier.

Nico
-- 

From [email-masked]  Thu Dec 16 13:34:10 2010
From: "Cantor, Scott E." <[email-masked]>
To: Nicolas Williams <[email-masked]>
Date: Thu, 16 Dec 2010 21:35:53 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [abfab] SAML attribute queries: AAA or SOAP

> You mention SOAP, but only in the subject line.  Would SOAP be the
> alternative transport?  If so, given that you'll need AAA anyways, why
> add one more protocol to this mix?  It certainly wouldn't make
> implementation easier.

One reason is that all existing SAML standards and code for queries is SOAP=
-based, and uses traditonal security mechanisms (signing, TLS). You can reu=
se that code and those services, with the attendant implications, or standa=
rdize and implement something new.

-- Scott

From [email-masked]  Thu Dec 16 13:34:43 2010
Date: Thu, 16 Dec 2010 22:36:23 +0100
From: Leif Johansson <[email-masked]>
To: "Cantor, Scott E." <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [abfab] SAML attribute queries: AAA or SOAP

On 12/16/2010 10:26 PM, Cantor, Scott E. wrote:
>> However SAML metadata gets you a bunch of things beyond a well known
>> protocol endpoint. One of them is key-management but other things might
>> also become important for abfab eventually such as contact information
>> and various UI hints.
> 
> I think Moonshot at least has been on record looking for AAA alternatives to metadata-based key management, so I doubt that's a selling point.
> 
> A lot of the typical uses probably go away if the AAA infrastructure handles everything. Attribute policy might be an exception, but metadata isn't the only way to drive that (and that's typically attribute *source* metadata, and the usual complaints about using metadata relate to the relying party having to make it available to the IdP/AA, not the other way around. Even OpenID doesn't pretend knowing the OP is somehow irrelevant.)
> 
> I suspect that this would be an adequate substitute for relying party metadata, and that metadata for the other end would be needed less, and could still be provided without complicating things very much.

I have a feeling som of the UI hints that people have been talking about
will turn out to be important for rendering something sensible to the
user in the login dialog.

I'm not sure where the complexity break-even point is for keeping
metadata in the mix though.

	Cheers Leif

From [email-masked]  Thu Dec 16 13:36:42 2010
From: "Cantor, Scott E." <[email-masked]>
To: Leif Johansson <[email-masked]>
Date: Thu, 16 Dec 2010 21:38:26 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [abfab] SAML attribute queries: AAA or SOAP

> I have a feeling som of the UI hints that people have been talking about
> will turn out to be important for rendering something sensible to the
> user in the login dialog.

Maybe, but I don't think there's the same discovery aspect here, and unless=
 there's a way to handle user consent in the flow, I don't know what you'd =
be presenting or for what purpose yet.

-- Scott

From [email-masked]  Thu Dec 16 13:47:59 2010
Date: Thu, 16 Dec 2010 15:49:22 -0600
From: Nicolas Williams <[email-masked]>
To: "Cantor, Scott E." <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [abfab] SAML attribute queries: AAA or SOAP

On Thu, Dec 16, 2010 at 09:35:53PM +0000, Cantor, Scott E. wrote:
> > You mention SOAP, but only in the subject line.  Would SOAP be the
> > alternative transport?  If so, given that you'll need AAA anyways, why
> > add one more protocol to this mix?  It certainly wouldn't make
> > implementation easier.
> 
> One reason is that all existing SAML standards and code for queries is
> SOAP-based, and uses traditonal security mechanisms (signing, TLS).
> You can reuse that code and those services, with the attendant
> implications, or standardize and implement something new.

I understand that that exists and is based on SOAP.  The question is
whether it can be avoided at the RP.  Using AAA as a transport for SAML
means it can be avoided at the RP.  To me that's a plus.

From [email-masked]  Thu Dec 16 13:48:59 2010
Date: Thu, 16 Dec 2010 15:47:40 -0600
From: Nicolas Williams <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [abfab] Should gss-eap support empty target_name

On Thu, Dec 16, 2010 at 04:26:45PM -0500, Sam Hartman wrote:
> Any opinions on whether we always frame or never frame?
> Or should we just use an AVP structure for all tokens with a special AVP
> for EAP tokens?
> What's the behavior on receiving something unexpected?

Good questions.  AVP/TLV works for me.  It can be optimized for the case
where the initiator sent an "empty" [*] initial context token, such that
in the case the reply is a naked initial EAP message.

The GSS-API does not allow empty tokens.  I'm not sure that a token
consisting only of the initial context token header is legal, so I
assume that you'll need at least a one-byte initial context token.

Given the above assumption, I'd say: make the initial context token
consist of a 32 bit long bit string, each bit being a flag acting as an
attribute name, and follow it with length-value pairs, one per-flag
set and in the flags' numerical order.  The reply token would be a
naked EAP message only when the initiator set no flags, else it would be
length-value pairs corresponding to those flags that were set, in the
same order, followed by a naked EAP message.

Seems simple to me...

Most if not all of the GSS context flags can be hardwired.  For example
you could always get sequence numbers in per-message tokens so replay
and OOS detection is always available, and confidentiality protection is
always available if the enctype supports it, with the enctype implied by
the mechanism OID.  But in the future we might get new flags worth
negotiating without having to add a new mechanism OID.  For this reason,
and to support target_name == GSS_C_NO_NAME, I strongly encourage you to
add this minimal level of faming.

Nico
-- 

From [email-masked]  Thu Dec 16 14:10:10 2010
Date: Thu, 16 Dec 2010 23:11:50 +0100
From: Leif Johansson <[email-masked]>
To: "Cantor, Scott E." <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [abfab] SAML attribute queries: AAA or SOAP

On 12/16/2010 10:38 PM, Cantor, Scott E. wrote:
>> I have a feeling som of the UI hints that people have been talking about
>> will turn out to be important for rendering something sensible to the
>> user in the login dialog.
> 
> Maybe, but I don't think there's the same discovery aspect here, and unless there's a way to handle user consent in the flow, I don't know what you'd be presenting or for what purpose yet.
> 
> -- Scott
> 

I was thinking that since the IdP can't provide its own look and feel
it would need a way to inform the client on what logo and contact URLs
to display at least.

	Cheers

From [email-masked]  Thu Dec 16 14:37:58 2010
From: Sam Hartman <[email-masked]>
To: "Cantor\, Scott E." <[email-masked]>
Date: Thu, 16 Dec 2010 17:39:27 -0500
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [abfab] SAML attribute queries: AAA or SOAP

One thing that running SAML over AAA does require is a real solution for
the AAA MTU problem.
We cannot both use attribute query as our response for RADIUS MTU issues
and also claim we run attribute queries over RADIUS.

--Sam

From [email-masked]  Thu Dec 16 14:39:19 2010
From: Sam Hartman <[email-masked]>
To: Nicolas Williams <[email-masked]>
Date: Thu, 16 Dec 2010 17:40:52 -0500
Cc: [email-masked]
Subject: Re: [abfab] SAML attribute queries: AAA or SOAP

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

    Nicolas> On Thu, Dec 16, 2010 at 02:47:24PM -0500, Sam Hartman wrote:
    >> One question is to what extent does using AAA as a transport for
    >> SAML messages actually address all the reasons we need metadata.
    >> Another question is is this actually easier to specify and
    >> implement than a metadata distribution protocol.

    Nicolas> You mention SOAP, but only in the subject line.  Would SOAP
    Nicolas> be the alternative transport?  If so, given that you'll
    Nicolas> need AAA anyways, why add one more protocol to this mix?
    Nicolas> It certainly wouldn't make implementation easier.

SOAP is the transport.
However most if not all the SAML libraries can already deal with that.

From [email-masked]  Thu Dec 16 14:39:36 2010
Date: Thu, 16 Dec 2010 16:41:11 -0600
From: Nicolas Williams <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [abfab] SAML attribute queries: AAA or SOAP

On Thu, Dec 16, 2010 at 05:39:27PM -0500, Sam Hartman wrote:
> One thing that running SAML over AAA does require is a real solution for
> the AAA MTU problem.
> We cannot both use attribute query as our response for RADIUS MTU issues
> and also claim we run attribute queries over RADIUS.

Right.  I figured you were going there.  Fragmentation is not pretty.

From [email-masked]  Thu Dec 16 14:42:37 2010
From: Sam Hartman <[email-masked]>
To: Nicolas Williams <[email-masked]>
Date: Thu, 16 Dec 2010 17:44:10 -0500
Cc: [email-masked], [email-masked]
Subject: Re: [abfab] Should gss-eap support empty target_name

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

    Nicolas> Given the above assumption, I'd say: make the initial
    Nicolas> context token consist of a 32 bit long bit string, each bit
    Nicolas> being a flag acting as an attribute name, and follow it
    Nicolas> with length-value pairs, one per-flag set and in the flags'
    Nicolas> numerical order.  The reply token would be a naked EAP
    Nicolas> message only when the initiator set no flags, else it would
    Nicolas> be length-value pairs corresponding to those flags that
    Nicolas> were set, in the same order, followed by a naked EAP
    Nicolas> message.

    Nicolas> Seems simple to me...

This does not seem very simple to me.  If we do something in this space
my preference is to use our existing extension token framing (see mail
from Luke--roughly, attribute IP, length, value for everything) for all
tokens.

--Sam

From [email-masked]  Thu Dec 16 14:54:11 2010
Date: Thu, 16 Dec 2010 16:54:04 -0600
From: Nicolas Williams <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [abfab] Should gss-eap support empty target_name

On Thu, Dec 16, 2010 at 05:44:10PM -0500, Sam Hartman wrote:
>     Nicolas> Seems simple to me...
> 
> This does not seem very simple to me.  If we do something in this space
> my preference is to use our existing extension token framing (see mail
> from Luke--roughly, attribute IP, length, value for everything) for all
> tokens.

It's all the same to me.

From [email-masked]  Thu Dec 16 15:14:12 2010
Date: Thu, 16 Dec 2010 17:15:22 -0600
From: Nicolas Williams <[email-masked]>
To: Martin Rex <[email-masked]>
Cc: [email-masked]
Subject: Re: [abfab] Should gss-eap support empty target_name

On Fri, Dec 17, 2010 at 12:09:31AM +0100, Martin Rex wrote:
> Nicolas Williams wrote:
> > 
> > On Thu, Dec 16, 2010 at 04:26:45PM -0500, Sam Hartman wrote:
> > > Any opinions on whether we always frame or never frame?
> > > Or should we just use an AVP structure for all tokens with a special AVP
> > > for EAP tokens?
> > > What's the behavior on receiving something unexpected?
> > 
> > Good questions.  AVP/TLV works for me.  It can be optimized for the case
> > where the initiator sent an "empty" [*] initial context token, such that
> > in the case the reply is a naked initial EAP message.
> > 
> > The GSS-API does not allow empty tokens.  I'm not sure that a token
> > consisting only of the initial context token header is legal, so I
> > assume that you'll need at least a one-byte initial context token.
> 
> The initial context token, per GSS-API standard, is the only token
> where the generic framing (including the mechanism OID) is _mandatory_.

For standard mechanisms, yes, which this would be.  But can there be no
bytes following that header?  I'm not sure.  Since this mechanism is
based on EAP, and EAP is initiated by the other party, in this case the
initial context token need not bear any data at all other than that
mechanism OID header.

Nico
-- 

From [email-masked]  Fri Dec 17 02:03:16 2010
From: Josh Howlett <[email-masked]>
To: "Cantor, Scott E." <[email-masked]>, Leif Johansson <[email-masked]>
Date: Fri, 17 Dec 2010 10:04:57 +0000
Accept-Language: en-GB, en-US
Cc: Josh Howlett <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] SAML attribute queries: AAA or SOAP

> > I have a feeling som of the UI hints that people have been talking about
> > will turn out to be important for rendering something sensible to the
> > user in the login dialog.
>=20
> Maybe, but I don't think there's the same discovery aspect here

Right.

I am sympathetic to Leif's proposition that a trusted container could poten=
tially still be useful in a number of ways, even if we're not using it for =
the normal reasons of publishing endpoint locations and keys, but I think t=
hat Nico's argument is more compelling: metadata-less operation makes ABFAB=
 much simpler.

I definitely don't think that ABFAB should prohibit the use of SOAP. I thin=
k that ABFAB should have some opinions about how SOAP-based communications =
can be used within the architecture, and perhaps even how the metadata that=
 supports those communications comes to be resolved and trusted.

However, it's a really non-trivial exercise to analyse the various approach=
es for doing this, and their respective trade-offs; and so I think at this =
stage it would be helpful to get agreement on what should constitute the se=
t of 'base' ABFAB technologies.=20

So, should SOAP be in this base set? As Sam suggests, I think that depends =
on whether we find a compelling answer to the AAA MTU issue. One possible a=
nswer is Diameter. Another possible answer is to seek to increase the RADIU=
S MTU. Another possibility it to learn to live with it, which is grim but n=
ot untenable: if we're not signing the SAML PDUs (relying on AAA integrity =
protection), 4kb of compressed XML is a still a handy amount of data.

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

From [email-masked]  Fri Dec 17 02:44:51 2010
Date: Fri, 17 Dec 2010 11:46:45 +0100
From: Eliot Lear <[email-masked]>
To: "Cantor, Scott E." <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [abfab] SAML attribute queries: AAA or SOAP

Hi,

On 12/16/10 10:38 PM, Cantor, Scott E. wrote:
>> I have a feeling som of the UI hints that people have been talking about
>> will turn out to be important for rendering something sensible to the
>> user in the login dialog.
> Maybe, but I don't think there's the same discovery aspect here, and unless there's a way to handle user consent in the flow, I don't know what you'd be presenting or for what purpose yet.
>
Right.

Metadata covers a whole raft of possibilities.  Precisely what are we
talking about?  are we talking about specific end point information? 
Are we talking about branding images?  Are we talking about
transaction-related data?

Thanks,

Eliot

From [email-masked]  Fri Dec 17 02:46:07 2010
Date: Fri, 17 Dec 2010 11:48:00 +0100
From: Eliot Lear <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [abfab] SAML attribute queries: AAA or SOAP

On 12/16/10 11:39 PM, Sam Hartman wrote:
> One thing that running SAML over AAA does require is a real solution for
> the AAA MTU problem.
> We cannot both use attribute query as our response for RADIUS MTU issues
> and also claim we run attribute queries over RADIUS.

Is this problem limited to Radius/UDP?

Eliot

From [email-masked]  Fri Dec 17 02:51:00 2010
Date: Fri, 17 Dec 2010 11:52:44 +0100
From: Alan DeKok <[email-masked]>
To: Eliot Lear <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [abfab] SAML attribute queries: AAA or SOAP

Eliot Lear wrote:
>> We cannot both use attribute query as our response for RADIUS MTU issues
>> and also claim we run attribute queries over RADIUS.
> 
> Is this problem limited to Radius/UDP?

  It's a general problem in RADIUS.  No other transport has been
defined, though others are being worked on (TCP, TLS, DTLS)

  There have been discussions about updating the MTU limits, but it will
take time before it's standardized and deployed.

  Alan DeKok.

From [email-masked]  Fri Dec 17 02:56:05 2010
From: Josh Howlett <[email-masked]>
To: Alan DeKok <[email-masked]>, Eliot Lear <[email-masked]>
Date: Fri, 17 Dec 2010 10:57:46 +0000
Accept-Language: en-GB, en-US
Cc: Josh Howlett <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] SAML attribute queries: AAA or SOAP

>   There have been discussions about updating the MTU limits, but it
> will take time before it's standardized and deployed.

Perhaps this is a naive question, but why would it need to take much time t=
o standardise? It's just a matter of picking a number 4=3D<64kb, right?

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

From [email-masked]  Fri Dec 17 03:00:57 2010
Date: Fri, 17 Dec 2010 12:02:42 +0100
From: Alan DeKok <[email-masked]>
To: Josh Howlett <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [abfab] SAML attribute queries: AAA or SOAP

Josh Howlett wrote:
>>   There have been discussions about updating the MTU limits, but it
>> will take time before it's standardized and deployed.
> 
> Perhaps this is a naive question, but why would it need to take much time to standardise? It's just a matter of picking a number 4=<64kb, right?

  What is the impact of changing it?  On the network, servers, clients,
etc.  Does anyone know?

  Who has the time to write the document, shepherd it, get reviewers, etc?

  Even high priority specifications can take months to years to get
published.

  Alan DeKok.

From [email-masked]  Fri Dec 17 03:01:25 2010
Date: Fri, 17 Dec 2010 12:03:19 +0100
From: Eliot Lear <[email-masked]>
To: Josh Howlett <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [abfab] SAML attribute queries: AAA or SOAP

I

On 12/17/10 11:57 AM, Josh Howlett wrote:
>>   There have been discussions about updating the MTU limits, but it
>> will take time before it's standardized and deployed.
> Perhaps this is a naive question, but why would it need to take much time to standardise? It's just a matter of picking a number 4=<64kb, right?

I probably wouldn't screw around with UDP, and if we're doing TCP, then
we need to do it over TLS/SSL.  I'm sure there's a draft out there
somewhere...

"Bueller?  Bueller?"

Eliot

From [email-masked]  Fri Dec 17 03:10:10 2010
Date: Fri, 17 Dec 2010 12:11:55 +0100
From: Alan DeKok <[email-masked]>
To: Eliot Lear <[email-masked]>
Cc: Josh Howlett <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] SAML attribute queries: AAA or SOAP

Eliot Lear wrote:
> I probably wouldn't screw around with UDP, and if we're doing TCP, then
> we need to do it over TLS/SSL.  I'm sure there's a draft out there
> somewhere...

  http://tools.ietf.org/html/draft-ietf-radext-radsec-07

  Multiple interoperable implementations, too.

  Alan DeKok.

From [email-masked]  Fri Dec 17 04:49:20 2010
Date: Fri, 17 Dec 2010 13:50:10 +0100
From: =?ISO-8859-1?Q?Gabriel_L=F3pez?= <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: [abfab] SAML attribute queries: AAA or SOAP

     Hi,

     If you suppose AAA will provide the trust infrastructure (no 
PKI-like infrastructures) then you should make use of SAML/RADIUS. You 
should not sign or cypher SAML assertions, so you can encapsulate SAML 
over RADIUS (fragmentation/RadSec/Diameter).
     But if you suppose there also could be a underlaying PKI-like 
infrastructure to manage trust (what I think is the most realistic 
scenario) then you should provide both alternatives: to encapsulate SAML 
assertions over RADIUS and to allow service providers to request end 
user attributes latter by means of SOAP bindings.

     The question is why do not provide both alternatives?

     Best regards, Gabi.

El 17/12/10 11:04, Josh Howlett escribi�:
>>> I have a feeling som of the UI hints that people have been talking about
>>> will turn out to be important for rendering something sensible to the
>>> user in the login dialog.
>> Maybe, but I don't think there's the same discovery aspect here
> Right.
>
> I am sympathetic to Leif's proposition that a trusted container could potentially still be useful in a number of ways, even if we're not using it for the normal reasons of publishing endpoint locations and keys, but I think that Nico's argument is more compelling: metadata-less operation makes ABFAB much simpler.
>
> I definitely don't think that ABFAB should prohibit the use of SOAP. I think that ABFAB should have some opinions about how SOAP-based communications can be used within the architecture, and perhaps even how the metadata that supports those communications comes to be resolved and trusted.
>
> However, it's a really non-trivial exercise to analyse the various approaches for doing this, and their respective trade-offs; and so I think at this stage it would be helpful to get agreement on what should constitute the set of 'base' ABFAB technologies.
>
> So, should SOAP be in this base set? As Sam suggests, I think that depends on whether we find a compelling answer to the AAA MTU issue. One possible answer is Diameter. Another possible answer is to seek to increase the RADIUS MTU. Another possibility it to learn to live with it, which is grim but not untenable: if we're not signing the SAML PDUs (relying on AAA integrity protection), 4kb of compressed XML is a still a handy amount of data.
>
> Josh.
>
> JANET(UK) is a trading name of The JNT Association, a company limited
> by guarantee which is registered in England under No. 2881024
> and whose Registered Office is at Lumen House, Library Avenue,
> Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG
>
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

-- 
----------------------------------------------------------------
Gabriel L�pez Mill�n
Departamento de Ingenier�a de la Informaci�n y las Comunicaciones
University of Murcia
Spain
Tel: +34 868888504
Fax: +34 868884151
email: [email-masked]

From [email-masked]  Thu Dec 16 15:07:49 2010
From: Martin Rex <[email-masked]>
To: [email-masked] (Nicolas Williams)
Date: Fri, 17 Dec 2010 00:09:31 +0100 (MET)
Cc: [email-masked], [email-masked]
Subject: Re: [abfab] Should gss-eap support empty target_name
Reply-To: [email-masked]

Nicolas Williams wrote:
> 
> On Thu, Dec 16, 2010 at 04:26:45PM -0500, Sam Hartman wrote:
> > Any opinions on whether we always frame or never frame?
> > Or should we just use an AVP structure for all tokens with a special AVP
> > for EAP tokens?
> > What's the behavior on receiving something unexpected?
> 
> Good questions.  AVP/TLV works for me.  It can be optimized for the case
> where the initiator sent an "empty" [*] initial context token, such that
> in the case the reply is a naked initial EAP message.
> 
> The GSS-API does not allow empty tokens.  I'm not sure that a token
> consisting only of the initial context token header is legal, so I
> assume that you'll need at least a one-byte initial context token.

The initial context token, per GSS-API standard, is the only token
where the generic framing (including the mechanism OID) is _mandatory_.
(so that the acceptor can figure out whether it is interoperable
with the initiator and any intermediate glue mech layers can correctly
dispatch the initial token to the correct mechanism implementation,
creating a gsssapi security context handle for all further processing
of tokens.
 
-Martin

From [email-masked]  Thu Dec 16 15:43:09 2010
From: Martin Rex <[email-masked]>
To: [email-masked] (Nicolas Williams)
Date: Fri, 17 Dec 2010 00:44:50 +0100 (MET)
Cc: [email-masked], [email-masked]
Subject: Re: [abfab] Should gss-eap support empty target_name
Reply-To: [email-masked]

Nicolas Williams wrote:
> 
> On Fri, Dec 17, 2010 at 12:09:31AM +0100, Martin Rex wrote:
> > Nicolas Williams wrote:
> > > 
> > > On Thu, Dec 16, 2010 at 04:26:45PM -0500, Sam Hartman wrote:
> > > > Any opinions on whether we always frame or never frame?
> > > > Or should we just use an AVP structure for all tokens with a special AVP
> > > > for EAP tokens?
> > > > What's the behavior on receiving something unexpected?
> > > 
> > > Good questions.  AVP/TLV works for me.  It can be optimized for the case
> > > where the initiator sent an "empty" [*] initial context token, such that
> > > in the case the reply is a naked initial EAP message.
> > > 
> > > The GSS-API does not allow empty tokens.  I'm not sure that a token
> > > consisting only of the initial context token header is legal, so I
> > > assume that you'll need at least a one-byte initial context token.
> > 
> > The initial context token, per GSS-API standard, is the only token
> > where the generic framing (including the mechanism OID) is _mandatory_.
> 
> For standard mechanisms, yes, which this would be.  But can there be no
> bytes following that header?  I'm not sure.  Since this mechanism is
> based on EAP, and EAP is initiated by the other party, in this case the
> initial context token need not bear any data at all other than that
> mechanism OID header.

The contents of the token following the generic framing is defined
by the mechanism identified by the mechanism OID in the generic framing.

The currently existing prohibition of empty token exists only towards
the gssapi-caller.  The exact contents of the inner token is
defined by the mechanism (specification) and could even be empty.
(a zero-length inner token might incur additional code changes
to some glue layers, but that area is not currently standardized.

Using _very_few_ bytes for the initial inner token to avoid unexpected
complexity for existing glue layers should be OK.

-Martin 

From [email-masked]  Fri Dec 17 06:23:01 2010
From: Sam Hartman <[email-masked]>
To: Eliot Lear <[email-masked]>
Date: Fri, 17 Dec 2010 09:24:26 -0500
Cc: Josh Howlett <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] SAML attribute queries: AAA or SOAP

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

    Eliot> I
    Eliot> On 12/17/10 11:57 AM, Josh Howlett wrote:
    >>> There have been discussions about updating the MTU limits, but
    >>> it will take time before it's standardized and deployed.
    >> Perhaps this is a naive question, but why would it need to take
    >> much time to standardise? It's just a matter of picking a number
    >> 4=<64kb, right?

    Eliot> I probably wouldn't screw around with UDP, and if we're doing
    Eliot> TCP, then we need to do it over TLS/SSL.  I'm sure there's a
    Eliot> draft out there somewhere...

We have a preliminary radsec (RADIUS over TLS) implementation we're
using for Moonshot.
However even that implementation has the 4k limit as an implementation
artifact.
Presumably it would not be hugely difficult to change in that
implementation.

--Sam

From [email-masked]  Fri Dec 17 07:17:36 2010
From: Sam Hartman <[email-masked]>
To: Gabriel =?iso-8859-1?Q?L=F3pez?= <[email-masked]>
Date: Fri, 17 Dec 2010 10:19:09 -0500
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [abfab] SAML attribute queries: AAA or SOAP

>>>>> "Gabriel" == Gabriel L�pez <[email-masked]> writes:

    Gabriel>     Hi,

    Gabriel>     If you suppose AAA will provide the trust
    Gabriel> infrastructure (no PKI-like infrastructures) then you
    Gabriel> should make use of SAML/RADIUS. You should not sign or
    Gabriel> cypher SAML assertions, so you can encapsulate SAML over
    Gabriel> RADIUS (fragmentation/RadSec/Diameter).  But if you suppose
    Gabriel> there also could be a underlaying PKI-like infrastructure
    Gabriel> to manage trust (what I think is the most realistic
    Gabriel> scenario) then you should provide both alternatives: to
    Gabriel> encapsulate SAML assertions over RADIUS and to allow
    Gabriel> service providers to request end user attributes latter by
    Gabriel> means of SOAP bindings.

    Gabriel>     The question is why do not provide both alternatives?

At one level, it would be difficult for us to take away the option of
using SOAP.  We'd have to go out of our way to tell people not to do it,
everyone would disagree with the proposal because there's no point in
prohibiting SOAP, etc.

However, at another level, there is a serious question of whether it
makes sense to spend effort on both alternatives.  For example, if you
are going to transition from AAA to SOAP, you want to have a mechanism
where the AAA server can issue an initial assertion with a subject that
the IDP can consume. For pseudunomymous operation, that requires
standardization.

Also, if SOAP is going to be in the mix, then focusing on making SAML
metadata scale is important.

--Sam

From [email-masked]  Fri Dec 17 08:05:15 2010
From: Josh Howlett <[email-masked]>
To: =?iso-8859-1?Q?Gabriel_L=F3pez?= <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 17 Dec 2010 16:06:56 +0000
Accept-Language: en-GB, en-US
Cc: Josh Howlett <[email-masked]>
Subject: Re: [abfab] SAML attribute queries: AAA or SOAP

Hi Gabi,

>      But if you suppose there also could be a underlaying PKI-like
> infrastructure to manage trust (what I think is the most realistic
> scenario) then you should provide both alternatives: to encapsulate
> SAML
> assertions over RADIUS and to allow service providers to request end
> user attributes latter by means of SOAP bindings.
>=20
>      The question is why do not provide both alternatives?

"PKI-like" is a complex set of possibilities. I'd rather not deal with that=
, if we don't have to.

(Although, as Sam says, this doesn't preclude Abfab entities from also usin=
g SOAP if they also want to do that).

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

From [email-masked]  Sun Dec 19 14:36:09 2010
From: "Diego R. Lopez" <[email-masked]>
To: Josh Howlett <[email-masked]>
Date: Sun, 19 Dec 2010 23:37:57 +0100
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [abfab] SAML attribute queries: AAA or SOAP

On 17 Dec 2010, at 11:04, Josh Howlett wrote:
> So, should SOAP be in this base set? As Sam suggests, I think that  
> depends on whether we find a compelling answer to the AAA MTU issue.  
> One possible answer is Diameter. Another possible answer is to seek  
> to increase the RADIUS MTU. Another possibility it to learn to live  
> with it, which is grim but not untenable: if we're not signing the  
> SAML PDUs (relying on AAA integrity protection), 4kb of compressed  
> XML is a still a handy amount of data.
>
Has anyone thought on the possibility of a different, more compact,  
coding for security assertions, much in the same spirit of the  
different RDF coding schemas? Not sure if such a coding could be  
called SAML anyway...

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez

Red.es - RedIRIS
The Spanish NREN

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

From [email-masked]  Tue Dec 21 10:29:16 2010
Date: Tue, 21 Dec 2010 19:31:21 +0100
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: [email-masked]
Subject: [abfab] draft-lear-abfab-arch-01 posted

This is a multi-part message in MIME format.
--------------070700020707060602060109
Content-Type: multipart/alternative;
 boundary="------------030607040507060301010806"

--------------030607040507060301010806
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Hi everyone,

We give to you the holiday present of reading ;-)  The authors have
updated The ABFAB Architecture Draft.  It contains a number of changes
since -00:

    * A high level step by step description of the process.
    * A "swimming lane" diagram visually demonstrating that process.
    * A discussion about channel binding and appropriate EAP methods.
    * A discussion about discovery.

This document is not complete, and will need to be a "living document"
as decisions are made in this working group.  There are still a number
of XXXs in it, that indicate where at least some work is needed.  It
would not be fair to say that the authors agree on everything that the
document contains, but rather we agree that it's important to show at
least one view and receive comment on direction at this point.

As to this author, please do not be alarmed if I don't respond quickly. 
I will be off from tomorrow until the 4th, and I wish you happy holidays
if you also are taking time off (and even if you are not).

Eliot

--------------030607040507060301010806
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#ffffff">
    Hi everyone,<br>
    <br>
    We give to you the holiday present of reading ;-)  The authors have
    updated The ABFAB Architecture Draft.  It contains a number of
    changes since -00:<br>
    <ul>
      <li>A high level step by step description of the process.</li>
      <li>A "swimming lane" diagram visually demonstrating that process.</li>
      <li>A discussion about channel binding and appropriate EAP
        methods.</li>
      <li>A discussion about discovery.</li>
    </ul>
    This document is not complete, and will need to be a "living
    document" as decisions are made in this working group.  There are
    still a number of XXXs in it, that indicate where at least some work
    is needed.  It would not be fair to say that the authors agree on
    everything that the document contains, but rather we agree that it's
    important to show at least one view and receive comment on direction
    at this point.<br>
    <br>
    As to this author, please do not be alarmed if I don't respond
    quickly.  I will be off from tomorrow until the 4th, and I wish you
    happy holidays if you also are taking time off (and even if you are
    not).<br>
    <br>
    Eliot<br>
  </body>
</html>

--------------030607040507060301010806--

--------------070700020707060602060109
Content-Type: message/rfc822;
 name="Attached Message"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Attached Message"

From: IETF I-D Submission Tool <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: New Version Notification for draft-lear-abfab-arch-01 
Date: Tue, 21 Dec 2010 10:22:19 -0800 (PST)

A new version of I-D, draft-lear-abfab-arch-01.txt has been successfully submitted by Eliot Lear and posted to the IETF repository.

Filename:	 draft-lear-abfab-arch
Revision:	 01
Title:		 Application Bridging for Federated Access Beyond Web (ABFAB) Architecture
Creation_date:	 2010-12-21
WG ID:		 Independent Submission
Number_of_pages: 29

Abstract:
Over the last decade a substantial amount of work has occurred in the
space of federated authentication and authorization.  Most of this
effort has focused on two common use cases: network and web-based
access, with few common building blocks within the architecture.
This memo describes an architecture that makes use of extensions to
the commonly used mechanisms for both federated and non-federated
authentication and authorization, including Radius/Diameter, GSS/GS2,
and SAML, to primarily address non-web based authentication, in a
that will scale to large numbers of federations.

The IETF Secretariat.

--------------070700020707060602060109--