To: [email-masked]
Date: Thu, 11 Feb 2010 21:39:55 -0000

> 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
To: [email-masked]
> 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
To: [email-masked]
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

From [email-masked]  Tue Jan  4 12:15:57 2011
Date: Tue, 04 Jan 2011 21:17:56 +0100
From: Leif Johansson <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: Andy Adamson <[email-masked]>
Subject: [abfab] session in Prague

Lacking sufficient data to say otherwize, I'm leaning towards
requesting a 2.5h session for Prague with the same conflict-
avoidance as for Beijing.

I know we ended early in Beijing but we hope to have Andy
from netapp come and talk about the federated-NFSv4 usecase.

Does anyone have another opinion?

	Cheers Leif

From [email-masked]  Tue Jan  4 12:42:33 2011
From: Josh Howlett <[email-masked]>
To: Leif Johansson <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 4 Jan 2011 20:44:32 +0000
Accept-Language: en-GB, en-US
Cc: Josh Howlett <[email-masked]>, Andy Adamson <[email-masked]>
Subject: Re: [abfab] session in Prague

> I know we ended early in Beijing=20

I thought we finished precisely on time thanks to some expert chairing :-)

> Does anyone have another opinion?

I think the Architecture draft could /potentially/ eat a lot of time. Not b=
ecause it says anything contentious, but because it necessarily covers a lo=
t of ground at speed; it might take time to fine-tune the content, technica=
l depth and dovetailing of concepts. I think 2.5 hours sounds about right, =
but it would be interesting to hear opinions from folks who have read the e=
xisting Architecture draft (draft-lear-abfab-arch-01), and how confused or =
educated that experience has left them.

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 Oxford, Didcot, Oxfordshire. OX11 0SG

From [email-masked]  Tue Jan  4 12:54:06 2011
From: Sam Hartman <[email-masked]>
To: Josh Howlett <[email-masked]>
Date: Tue, 04 Jan 2011 15:55:21 -0500
Cc: Andy Adamson <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] session in Prague

Yeah, I'm sort of wondering whether we want two sessions, not whether we
want a shorter session.
I don't think I have a sufficient case to argue for two sessions though,
so going with the chairs' 2.5 hour request seems good.

I suspect there will be a number of technical details that will eat up
time and I suspect we could definitely have a long discussion of the
architecture draft.
Speaking of which, please read and comment on the new architecture
draft!

From [email-masked]  Tue Jan  4 13:04:38 2011
Date: Tue, 04 Jan 2011 22:06:39 +0100
From: Leif Johansson <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: Josh Howlett <[email-masked]>, Andy Adamson <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] session in Prague

On 01/04/2011 09:55 PM, Sam Hartman wrote:
> Yeah, I'm sort of wondering whether we want two sessions, not whether we
> want a shorter session.
> I don't think I have a sufficient case to argue for two sessions though,
> so going with the chairs' 2.5 hour request seems good.

It is so requested. I'm not sure if the scheduling has an early bird
special but at least we won't be last :)

> 
> I suspect there will be a number of technical details that will eat up
> time and I suspect we could definitely have a long discussion of the
> architecture draft.
> Speaking of which, please read and comment on the new architecture
> draft!

Indeed. We the chairs want those reviews and document updates to start
coming in now!

	Cheers Leif

From [email-masked]  Thu Jan  6 15:22:08 2011
Date: Fri, 07 Jan 2011 00:24:09 +0100
From: Leif Johansson <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [abfab] tracker?

We have a tracker (http://trac.tools.ietf.org/wg/abfab/trac/report). Is
it worth the effort to create issues for some of the stuff that we've
been discussing on the list?

	Cheers Leif

From [email-masked]  Mon Jan 10 03:29:43 2011
Date: Mon, 10 Jan 2011 12:31:54 +0100
From: Klaas Wierenga <[email-masked]>
To: [email-masked]
Subject: Re: [abfab] draft-lear-abfab-arch-01 posted

On 12/21/10 7:31 PM, Eliot Lear wrote:

Hi Eliot, all,

Thanks for this great stab at an architecture document! I have read the
document and have a bunch of remarks, questions etc. Some of those are a
matter of taste I guess, so feel free to ignore (with arguments ;-)

I looked at the document from different angles: overall organization,
addressing of the key issues and specific content. In general I have
assumed that readers of this document are probably intimately familiar
with only part of the used components, so it is better to err at the
more explanation rather than less side.

Overall organization
- --------------------
I see roughly an organization along the lines of:

- - introduction
- - problem description
- - design goals
- - component choices
- - architecture description
- - deployment considerations

However, in the text the various parts are not always well separated. As
an example, in the introduction (p6) the steps in the AuthN/AuthZ
exchange are very much focused on the particular component choices that
have been made, whereas those have not been introduced yet. And also,
1.3 is about the use of RADIUS, whereas in my mind there is no reason to
specifically address RADIUS in the introduction and not SAML, GSS-API etc.
I would like to have the separation between problem, design goals,
implementation choices etc. much more clear because that allows us to
have a 'cleaner' discussion.
In particular, I would prefer to see an abstract description of the
paragraphs of chapter 3 (which I think do an excellent job of stating
the components) and have them instantiated in Chapter 3.

Adressing of the key issues
- ---------------------------
The one issue that is imo only very limited addressed is that of
multiple federations. Will the NAI also serve for federation selection?
Does the principal need to be made aware of what federations are
vaialble for a particular service? Does the IdP get to choose what
federation a users is 'wielding'? depending on the answer to these
questions, can we implement that in the current frameworks? Are we going
to address the multiple federation problem? If not, how can that bite us
later?

3.1 states that statements about the subject by the IdP are transported
through AAA, is this meant to state that they will be transported *only*
through AAA, or can they also be transported outside AAA (f.e. using SOAP)

Detailed comments
- -----------------
1, p4 capitalize RADIUS (and throughout the doc)

1, p4: should "different roles" and "various authentication mechanisms"
be bullit points too?

1, p4 "but particulary acute for the latter ans": ans -> as

1, p4: the paragraph starting with "Similarly" starts with talking about
IdP selection and switches to federation selection. Which one (or both)
is intended?

1, p5: the paragraph starting with "Figure 1 also shows...", I don't
believe a policy is agreed upon by "some sort of administrative
management", I think the adminstartive processes are rather to implement
the policies that have been agreed upon oob.

1, p5: "real world entity", is this in this example not just a "natural
person" instead? The "often" leaves imo enough space to also include
non-human.

1, p6: so we assume different adminstrative domains but the same federation?

1, p6: steps are too implementation specific

1, p7 step 10: does the IdP authenticate or authorize the principal to
the RP? How about "Once the IdP made a decision of whether and how to
authorize the principal to use the service offered by the RP it will
assert this to the RP"

1.2 p8: how does the no sharing of long term private keys follow from
the need for multiple authentication protocols?

1.2 p8: "large number of IdPs, RPs, users" ... and federations?

1.2 p9: "The system will build upon.." -> "The system will build as much
as possible build upon..."

1.3 p9: This paragraph here makes only sense for those of us entrenched
in SAML federations, people coming from the AAA side may equally be
interested in a paragraph about SAML here. I propose moving this to
chapter 3.

3.1 p12 2nd paragraph: "is authorized to make assertions" -> "is
authorized to make assertions about the principal and to that particular RP"

3.1 p12 2nd paragraph: "any old provider" -> "any RP"

3.1 p12 Federation Dynamic Referral: the identity of the principal is
unknown, but the realm, isn't it? Is that not sufficient for authorizing
an IdP?

3.1 p12 Federation Dynamic Referral: What is the difference between the
proxy mentioned here and the one in Federation Proxy (next paragraph)?

3.1 p12 "The astute reader...", do you want to say something about
RadSec here?

3.1 p13 last paragraph: So does this mean that all statements are
transported through AAA, i.e. no room for SOAP interactions?

3.2 p13 "Experience has taught us...." -> "Experience has taught ...."

3.2 p13 "Experience has taught....": The authentication framework must
also allow for the selection of authentication mechanisms per
application, i.e. for certain applications u/p may be enough while for
others hardware tokens are needed. I don't want to be forced to wield a
cumbersome authentication method for low value transactions.

3.3 p14 "GSS-API is specified...": What is the relevance of mentioning
the sub-operations of the initial context exchange?

3.5 p16: I don't immediately see how to improve figure 2, but I think it
is not easy to understand

4 p17 It seems that part of this discussion belongs higher up in the
document (design goals?) and part is implementation choices

4.1 p17: explain better what is confusing about the mutual
authentication terminology

4.1 p17 "If a target name is supplied...": can the initiator only supply
a target name if "the appropriate cryptographic exchanges took place"?
Is it not possible that the initiator just states the target name as
supplied by the acceptor and uses information from the IdP to validate
this name?

4.2 p18 first paragraph: the sentence starting with "Even when it is
checked" is not a well-formed sentence, and I don't understand what it
should read.

4.2 p19: I don't really understand the whiteboard example, how is the
user able to validate the content that is being displayed? What if some
users get (slightly) different content than others?

4.2 p19 last paragraph: i think if you explain GSS-API CB you also need
to explain EAP CB

4.3 p19 "Using host based service...": Why does ABFAB need to adopt this
approach?

4.3 p19 "Host-based service names...": I think a few more sentences of
explanation would help.

Hope this is of use,

Klaas

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

From [email-masked]  Mon Jan 10 10:25:43 2011
From: Sam Hartman <[email-masked]>
To: Klaas Wierenga <[email-masked]>
Date: Mon, 10 Jan 2011 13:27:50 -0500
Cc: [email-masked]
Subject: Re: [abfab] draft-lear-abfab-arch-01 posted

Klaas, thanks so much for your comments.
I'm responding as an individual not on behalf of the authors as a group.

I agree that we need to do a better job of discussing federation
selection; the current text does not do much about that.  This is
definitely a good comment and something for us to work on.

You ask whether we intend to preclude SOAP. I think that's for you to
tell us: we've had a WG discussion on this topic and I think we have
enough of a discussion to approach a consensus. My reading is that we
are going to focus on AAA transport but nothing will preclude soap.
However it would be useful to get a consensus call from the chairs on
this.

I agree that the specific protocol flows could be moved later in the
document and that would improve things.
I think it's a little complicated where you want this information: there
is some value in having the  diagrams fairly early.

You propose introducing more abstraction: having an abstract discussion
of the aspects of the system and then discussing specific technology
choices. Definitely for the application integration, where we've
acknowledged in our charter that other options are possible, we should
do this. Also, we should separate the abstract discussion of AAA from
RADIUS and Diameter.
However, the use of AAA, EAP, and to some extent SAML is baked in at a
fairly deep level.
So, we're not obligated to treat things abstractly.
We can if it makes the document flow better. However sometimes it is
easier to understand one concrete system than a bunch of abstractions.
So, can we explore how valuable that will actually be?

3.3 p14 "GSS-API is specified...": What is the relevance of mentioning
the sub-operations of the initial context exchange?

No, not really.
I thought it might, but it didn't end up being useful.

4 p17 It seems that part of this discussion belongs higher up in the
document (design goals?) and part is implementation choices

It's hard to discuss this abstractly. I don't think we have enough
community experience for that discussion nor do I think we understand
what this would mean abstractly well enough to have this discussion
before the discussions of concrete technologies.
So, I'm sympathetic to the concern, but I'm not sure I know how to do
what you ask.
If you want to throw something together or have a chat, we could do
that.

4.1 p17: explain better what is confusing about the mutual
authentication terminology

It's that to some people mutual authentication implies that the client's
identity is being released.
In GSS, that's not true.

4.2 p18 first paragraph: the sentence starting with "Even when it is
checked" is not a well-formed sentence, and I don't understand what it
should read.

Ah, a typeo. s:if the trust:the trust
4.2 p19: I don't really understand the whiteboard example, how is the
user able to validate the content that is being displayed? What if some
users get (slightly) different content than others?

Note here we're talking about a physical electronic LCD whiteboard in a
room, not some shared conference whiteboard software.Typically a
presenter can validate the content of their own presentation.  How do we
deal with attacks that give different users different content?  I claim
that an attack that presents different content to people in the same
physical room looking at the same LCD is outside of the scope of
ABFAB:-)
If we make the context clear--that we're talking about a networked
LCD--is this example more clear?
4.2 p19 last paragraph: i think if you explain GSS-API CB you also need
to explain EAP CB

I agree that this document needs  to discuss EAP channel binding. We
propose to do that in the unwritten section 6.1 as part of the
deployment discussion.
I guess we could briefly discuss in section 3 as well.
4.3 p19 "Using host based service...": Why does ABFAB need to adopt this
approach?

We need to adopt this approach if we want ABFAB to work with IMAP, SMTP,
LDAP, SSH, NFS or a variety of other protocols that use this naming
approach.  We could alternatively update all those specifications and
update all the implementations that use generic frameworks such as SSPI
or Cyrus SASL.  This is a case where following the existing standards
makes deploymentand implementation easier.
Can you suggest additional text for the last paragraph of this section
to better clarify?

From [email-masked]  Mon Jan 10 11:15:36 2011
From: Sam Hartman <[email-masked]>
To: [email-masked],[email-masked]
Date: Mon, 10 Jan 2011 14:17:48 -0500
Subject: [abfab] Multiple attribute providers in an authentication

Background: there was a discussion between authors of the abfab
architecture proposal about multiple attribute providers.
The idea is that you have an identity provider that is producing a set
of attributes about a subject. In the case of ABFAB we're mostly
thinking of a SAML IDP for this particular example.

The IDP  has some attributes it may be in a position to assert.
But the IDP may also want to gather attributes from other  sources and
pass those along.

One option it has is to simply pass the attributes along as if it issued
them itself.  That option isn't really interesting from a protocol
standpoint because it is indistinguishable from the IDP actually issuing
the attribute itself.  That is probably a fine thing to do in certain
deployments but we don't need to spend a lot of time on it.

Another option is that the IDP can go actually get a SAML assertion (or
attribute certificate or the like) and include that in what is sent to
the RP.

At first glance, the protocol implications of doing this look
simple. You just stick the assertion in the existing bag of bits and
move on.

however, it's not that simple because of semantics.

Today in ABFAB, we haven't done a great job of describing what the trust
semantics of the attribute in draft-ietf-abfab-aaa-saml are. However
what has been going through at least Josh and my mind is that the RP
SHOULD assume that the AAA framework provides an integrity protected
channel for that SAML message. The message is actually issued by the IDP
corresponding to the NAI used to make the access request. In addition,
for the SAML assertions sent from the IDP to the RP, the RP SHOULD
assume that the IDP is asserting those attributes about the subject.
That is, the RP need not perform any validation of the SAML
assertion. The RP still needs to validate whether the IDP is permitted
to make the claims it does.
There's no requirement that these SAML assertions be signed.
The IDP MAY sign the assertion; the RP MAY consider any signatures that
are present. However in the interoperable case, any signatures that are
present are ignored.

If there are multiple assertions from the same IDP it seems reasonable
to treat them all the same.

Things get a lot more messy  when assertions from multiple IDPs are
included.
What does it mean to include them in the AAA transport?  I can think of
several trust models that are appropriate depending on deployment:

* The IDP corresponding to the subject's NAI has validated these
  additional assertions and wishes to assert that the attributes can be
  trusted. "If you trust me then you should trust these." Here, the
  assertions are being included either for convenience of packaging the
  attributes into some form the RP can process or because it is possible
  that the RP may be able to validate some signature and trust the
  attribute source more than the IDP.

* The subject IDP has performed SAML validation on the
  assertions. However the IDP is making no claims about how trusted the
  attributes included in the additional assertions are. Even if the IDP
  would be permitted to make a claim made in an additional assertion,
  the RP needs to make an independent policy decision about whether the
  actual issuer should be permitted to make that claim.

* Here are some assertions for the RP's convenience. The IDP makes no
  claims about them; not even the implied claim that they have not been
  modified in transit. They better be signed, the RP better have
  metadata for their issuer, and the RP is more or less on its own.

Another source of complexity surrounds how an IDP links an assertion to
a subject. What confidence is the RP asserting that the additional
assertion describes the same principal as the access-accept message.

Another potential source of complexity is how does the IDP know what
information to gather? Does the IDP just know somehow? Does the RP pass
information back?

How does the RP make the policy decisions it needs to make? How does it
get metadata that is needed?

I think this sort of issue will also have impacts for kitten, because
we'll need to describe it in the naming extensions interface. It seems
like ABFAB is not going to be the only group facing these sorts of
discussions; Kerberos is in the middle of a similar discussion right
now.

From [email-masked]  Mon Jan 10 11:53:40 2011
Date: Mon, 10 Jan 2011 20:55:57 +0100
From: Eliot Lear <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [abfab] Multiple attribute providers in an authentication

This is a multi-part message in MIME format.
--------------080403070403000002060300
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Sam,

Thanks for taking the time to describe the problem. 

On 1/10/11 8:17 PM, Sam Hartman wrote:
> Background: there was a discussion between authors of the abfab
> architecture proposal about multiple attribute providers.
> The idea is that you have an identity provider that is producing a set
> of attributes about a subject. In the case of ABFAB we're mostly
> thinking of a SAML IDP for this particular example.
>
> The IDP  has some attributes it may be in a position to assert.
> But the IDP may also want to gather attributes from other  sources and
> pass those along.
>
> One option it has is to simply pass the attributes along as if it issued
> them itself.  That option isn't really interesting from a protocol
> standpoint because it is indistinguishable from the IDP actually issuing
> the attribute itself.  That is probably a fine thing to do in certain
> deployments but we don't need to spend a lot of time on it.
>
> Another option is that the IDP can go actually get a SAML assertion (or
> attribute certificate or the like) and include that in what is sent to
> the RP.
>
> At first glance, the protocol implications of doing this look
> simple. You just stick the assertion in the existing bag of bits and
> move on.
>
> however, it's not that simple because of semantics.
>
> Today in ABFAB, we haven't done a great job of describing what the trust
> semantics of the attribute in draft-ietf-abfab-aaa-saml are. However
> what has been going through at least Josh and my mind is that the RP
> SHOULD assume that the AAA framework provides an integrity protected
> channel for that SAML message. The message is actually issued by the IDP
> corresponding to the NAI used to make the access request. In addition,
> for the SAML assertions sent from the IDP to the RP, the RP SHOULD
> assume that the IDP is asserting those attributes about the subject.
> That is, the RP need not perform any validation of the SAML
> assertion. The RP still needs to validate whether the IDP is permitted
> to make the claims it does.
> There's no requirement that these SAML assertions be signed.
> The IDP MAY sign the assertion; the RP MAY consider any signatures that
> are present. However in the interoperable case, any signatures that are
> present are ignored.

You mean is that the security model you have in mind does not require
that SAML assertions be signed?  We may have an additional software
layering problem- specifically, if they are present, and you're using a
SAML library to parse the messages, from a practical standpoint, an
error may be returned.

However, I think what you're alluding to is that the lack of a signature
itself is *part* of the problem of returning attributes from 3rd
parties, since the associated connectivity of the AAA transport is
providing authenticity and *not *the signature.

> [snip]

> Another source of complexity surrounds how an IDP links an assertion to
> a subject. What confidence is the RP asserting that the additional
> assertion describes the same principal as the access-accept message.

On this point - the IdP either is or is not authoritative for knowing at
the very least where the information is going to come from.  The only
question here is whether or not it is willing to vouch for the
information itself.
> Another potential source of complexity is how does the IDP know what
> information to gather? Does the IDP just know somehow? Does the RP pass
> information back?
And this is a generic problem with attribute providers.  The general
answer is either that the principal provides a pointer, or it finds the
information through external means.  Again, the only issues in this case
are whether the IdP is providing some sort of surety, and whether it can
be assumed that there is a trust relationship between the RP and the
attribute provider.  That latter one is a much bigger deal, IMHO!

Regards,

Eliot

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    Sam,<br>
    <br>
    Thanks for taking the time to describe the problem.  <br>
    <br>
    On 1/10/11 8:17 PM, Sam Hartman wrote:
    <blockquote cite="mid:[email-masked]" type="cite">
      <pre wrap="">
Background: there was a discussion between authors of the abfab
architecture proposal about multiple attribute providers.
The idea is that you have an identity provider that is producing a set
of attributes about a subject. In the case of ABFAB we're mostly
thinking of a SAML IDP for this particular example.

The IDP  has some attributes it may be in a position to assert.
But the IDP may also want to gather attributes from other  sources and
pass those along.

One option it has is to simply pass the attributes along as if it issued
them itself.  That option isn't really interesting from a protocol
standpoint because it is indistinguishable from the IDP actually issuing
the attribute itself.  That is probably a fine thing to do in certain
deployments but we don't need to spend a lot of time on it.

Another option is that the IDP can go actually get a SAML assertion (or
attribute certificate or the like) and include that in what is sent to
the RP.

At first glance, the protocol implications of doing this look
simple. You just stick the assertion in the existing bag of bits and
move on.

however, it's not that simple because of semantics.

Today in ABFAB, we haven't done a great job of describing what the trust
semantics of the attribute in draft-ietf-abfab-aaa-saml are. However
what has been going through at least Josh and my mind is that the RP
SHOULD assume that the AAA framework provides an integrity protected
channel for that SAML message. The message is actually issued by the IDP
corresponding to the NAI used to make the access request. In addition,
for the SAML assertions sent from the IDP to the RP, the RP SHOULD
assume that the IDP is asserting those attributes about the subject.
That is, the RP need not perform any validation of the SAML
assertion. The RP still needs to validate whether the IDP is permitted
to make the claims it does.
There's no requirement that these SAML assertions be signed.
The IDP MAY sign the assertion; the RP MAY consider any signatures that
are present. However in the interoperable case, any signatures that are
present are ignored.
</pre>
    </blockquote>
    <br>
    You mean is that the security model you have in mind does not
    require that SAML assertions be signed?  We may have an additional
    software layering problem- specifically, if they are present, and
    you're using a SAML library to parse the messages, from a practical
    standpoint, an error may be returned.<br>
    <br>
    However, I think what you're alluding to is that the lack of a
    signature itself is <b>part</b> of the problem of returning
    attributes from 3rd parties, since the associated connectivity of
    the AAA transport is providing authenticity and <b>not </b>the
    signature.<br>
    <br>
    <br>
    <blockquote cite="mid:[email-masked]" type="cite">
      <pre wrap="">[snip]
</pre>
    </blockquote>
    <br>
    <blockquote cite="mid:[email-masked]" type="cite">
      <pre wrap="">Another source of complexity surrounds how an IDP links an assertion to
a subject. What confidence is the RP asserting that the additional
assertion describes the same principal as the access-accept message.
</pre>
    </blockquote>
    <br>
    On this point - the IdP either is or is not authoritative for
    knowing at the very least where the information is going to come
    from.  The only question here is whether or not it is willing to
    vouch for the information itself.<br>
    <blockquote cite="mid:[email-masked]" type="cite">
      <pre wrap="">
Another potential source of complexity is how does the IDP know what
information to gather? Does the IDP just know somehow? Does the RP pass
information back?
</pre>
    </blockquote>
    And this is a generic problem with attribute providers.  The general
    answer is either that the principal provides a pointer, or it finds
    the information through external means.  Again, the only issues in
    this case are whether the IdP is providing some sort of surety, and
    whether it can be assumed that there is a trust relationship between
    the RP and the attribute provider.  That latter one is a much bigger
    deal, IMHO!<br>
    <br>
    Regards,<br>
    <br>
    Eliot<br>
  </body>
</html>

--------------080403070403000002060300--

From [email-masked]  Mon Jan 10 12:16:54 2011
From: "Cantor, Scott E." <[email-masked]>
To: Eliot Lear <[email-masked]>, Sam Hartman <[email-masked]>
Date: Mon, 10 Jan 2011 20:18:46 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] Multiple attribute providers in an authentication

From [email-masked]  Mon Jan 10 12:20:58 2011
From: Sam Hartman <[email-masked]>
To: Eliot Lear <[email-masked]>
Date: Mon, 10 Jan 2011 15:23:10 -0500
Cc: [email-masked], [email-masked]
Subject: Re: [abfab] Multiple attribute providers in an authentication

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

    Eliot> Sam, Thanks for taking the time to describe the problem.

You are welcome.
I realized that I did not explicitly say it, but I think all these
complexities are tractable.
We will have to do work in order to support this use case.
I think that work is not in scope for what we're signed up to do now,
although if someone stepped forward and wanted to  do the work, it could
happen sooner.

I think that some of this may require some work in kitten.
>     Today in ABFAB, we haven't done a great job of describing
> what the trust semantics of the attribute in
> draft-ietf-abfab-aaa-saml are. However what has been going
> through at least Josh and my mind is that the RP SHOULD
> assume that the AAA framework provides an integrity protected
> channel for that SAML message. The message is actually issued
> by the IDP corresponding to the NAI used to make the access
> request. In addition, for the SAML assertions sent from the
> IDP to the RP, the RP SHOULD assume that the IDP is asserting
> those attributes about the subject.  That is, the RP need not
> perform any validation of the SAML assertion. The RP still
> needs to validate whether the IDP is permitted to make the
> claims it does.  There's no requirement that these SAML
> assertions be signed.  The IDP MAY sign the assertion; the RP
> MAY consider any signatures that are present. However in the
> interoperable case, any signatures that are present are
> ignored.

    Eliot> You mean is that the security model you have in mind does not
    Eliot> require that SAML assertions be signed?  We may have an
    Eliot> additional software layering problem- specifically, if they
    Eliot> are present, and you're using a SAML library to parse the
    Eliot> messages, from a practical standpoint, an error may be
    Eliot> returned.

Perhaps.
With Shibboleth we certainly are no longer having issues with this.
I'd be interested in hearing from other SAML implementeors.

Note that you are equally likely to have trouble if the message is
signed and you don't have metadata.  So, you're going to have a better
user experience if your SAML library does not require signatures.

    Eliot> However, I think what you're alluding to is that the lack of
    Eliot> a signature itself is part of the problem of returning
    Eliot> attributes from 3rd parties, since the associated
    Eliot> connectivity of the AAA transport is providing authenticity
    Eliot> and not the signature.

No; you can always (as the issuer at least) add signatures.
Supporting a case where the third party attributes are just carried and
the RP is responsible for validation is fairly easy at the protocol
level. It probably requires a different AAA attribute that doesn't imply
the contents should be trusted. That is, the RP is free to ignore
signatures on assertions in the current attribute, but would need to
validate assertions from third parties. However that's one new AAA
attribute, which is fairly simple.
My personal opinion is that it's also fairly useless.
We're assuming that the RP and IDP don't have any requirement for a
trust relationship other than through the AAA fabric. Why is it more
reasonable to assume a trust relationship with a third party.
There are some situations where this model is exactly what you need.

Complexity comes in if you want to offload more trust to the IDP.

    Eliot>     [snip]

>     Another source of complexity surrounds how an IDP links
> an assertion to a subject. What confidence is the RP
> asserting that the additional assertion describes the same
> principal as the access-accept message.

    Eliot> On this point - the IdP either is or is not authoritative for
    Eliot> knowing at the very least where the information is going to
    Eliot> come from.  

I agree with this sentence. I don't understand how it fits into the
 quoted paragraph above.

    Eliot> The only question here is whether or not it is
    Eliot> willing to vouch for the information itself.

I agree that's a question.
I'm again not sure that it fits into the question of subject linkage,
except that one hopes the subject linkage is fairly good if the IDP does
vouch for the information.

>     Another potential source of complexity is how does the
> IDP know what information to gather? Does the IDP just know
> somehow? Does the RP pass information back?

    Eliot> And this is a generic problem with attribute providers.  The
    Eliot> general answer is either that the principal provides a
    Eliot> pointer, or it finds the information through external means.

Sure.  But we need to provide protocols and APIs to actually convey that
throughout the system.  It's real engineering that needs doing for
things to work, but again is certainly something we can do.

    Eliot>     Eliot> Again, the only issues in this case are whether the IdP is
    Eliot> providing some sort of surety, and whether it can be assumed
    Eliot> that there is a trust relationship between the RP and the
    Eliot> attribute provider.  That latter one is a much bigger deal,
    Eliot> IMHO!

I'm definitely missing how these relate to what information the RP
wants.

From [email-masked]  Mon Jan 10 13:25:40 2011
Date: Mon, 10 Jan 2011 22:27:58 +0100
From: Eliot Lear <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [abfab] Multiple attribute providers in an authentication

Hi Sam,

Thanks for your response.  Let me add that this is really not a big
issue with me for now.  I see some very interesting use cases that
relate to liability concerns around certain attributes, and I consider
this conversation useful just to the point of knowing whether we are
able to accomplish the task of having attribute providers later, if and
when demand warrants.

Just on one point:

>>     Another source of complexity surrounds how an IDP links
>> an assertion to a subject. What confidence is the RP
>> asserting that the additional assertion describes the same
>> principal as the access-accept message.
>
>     Eliot> On this point - the IdP either is or is not authoritative for
>     Eliot> knowing at the very least where the information is going to
>     Eliot> come from.  
>
> I agree with this sentence. I don't understand how it fits into the
>  quoted paragraph above.

I may have misunderstood what you originally wrote.

Perhaps what you are saying is that if there is absolutely no
requirement that the IdP trust the attribute provider at all, that it
simply passes bits, then there is a risk that the information returned
might not be related to the principal.  I would suggest that it is
incumbent on the attribute provider to at least make an assurance that
it won't happen, because you're right- the RP cannot be assured
otherwise because it may not have sufficient information or even
authorization to reference the principal to the RP.

One other challenge here would be to consider whether it is permissible
that the unique index or name of the principal in the context of the
attribute provider could leak to the RP.  If that name is covered by a
signature, it cannot easily be removed.

Eliot

From [email-masked]  Mon Jan 10 13:35:10 2011
Date: Mon, 10 Jan 2011 22:37:17 +0100
From: Klaas Wierenga <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked]
Subject: Re: [abfab] draft-lear-abfab-arch-01 posted

On 1/10/11 7:27 PM, Sam Hartman wrote:

Hi Sam,

> Klaas, thanks so much for your comments.
> I'm responding as an individual not on behalf of the authors as a group.
> 
> I agree that we need to do a better job of discussing federation
> selection; the current text does not do much about that.  This is
> definitely a good comment and something for us to work on.
> 
> You ask whether we intend to preclude SOAP. I think that's for you to
> tell us: we've had a WG discussion on this topic and I think we have
> enough of a discussion to approach a consensus. My reading is that we
> are going to focus on AAA transport but nothing will preclude soap.
> However it would be useful to get a consensus call from the chairs on
> this.

sure, I was wondering if it was your intent to put a stake in the ground
in this doc or not.

> 
> I agree that the specific protocol flows could be moved later in the
> document and that would improve things.
> I think it's a little complicated where you want this information: there
> is some value in having the  diagrams fairly early.

true... perhaps kick of 3 with it and then start explaining it as you go
in 3?

> 
> You propose introducing more abstraction: having an abstract discussion
> of the aspects of the system and then discussing specific technology
> choices. Definitely for the application integration, where we've
> acknowledged in our charter that other options are possible, we should
> do this. Also, we should separate the abstract discussion of AAA from
> RADIUS and Diameter.
> However, the use of AAA, EAP, and to some extent SAML is baked in at a
> fairly deep level.
> So, we're not obligated to treat things abstractly.

No, I understand what you say, I was pondering the same before I typed
my comment. But I think it would be good for the reader to understand
what *functionality* we need to provide versus *how* we provide that
functionality. I like the separation of concerns in 3, perhaps good to
state them in the introduction and link them to the technology choice we
made without further explanation in this chapter?

> We can if it makes the document flow better. However sometimes it is
> easier to understand one concrete system than a bunch of abstractions.
> So, can we explore how valuable that will actually be?

sure, this was really a discussion topic.

> 
> 
> 3.3 p14 "GSS-API is specified...": What is the relevance of mentioning
> the sub-operations of the initial context exchange?
> 
> 
> No, not really.
> I thought it might, but it didn't end up being useful.
> 
> 
> 4 p17 It seems that part of this discussion belongs higher up in the
> document (design goals?) and part is implementation choices
> 
> It's hard to discuss this abstractly. I don't think we have enough
> community experience for that discussion nor do I think we understand
> what this would mean abstractly well enough to have this discussion
> before the discussions of concrete technologies.
> So, I'm sympathetic to the concern, but I'm not sure I know how to do
> what you ask.
> If you want to throw something together or have a chat, we could do
> that.

hmm yes, I'll have a look and see if I can come up with a proposal

> 
> 4.1 p17: explain better what is confusing about the mutual
> authentication terminology
> 
> It's that to some people mutual authentication implies that the client's
> identity is being released.
> In GSS, that's not true.

ok, I think it is fine to just say that then.

> 
> 
> 4.2 p18 first paragraph: the sentence starting with "Even when it is
> checked" is not a well-formed sentence, and I don't understand what it
> should read.
> 
> Ah, a typeo. s:if the trust:the trust
> 4.2 p19: I don't really understand the whiteboard example, how is the
> user able to validate the content that is being displayed? What if some
> users get (slightly) different content than others?
> 
> Note here we're talking about a physical electronic LCD whiteboard in a
> room, not some shared conference whiteboard software.Typically a
> presenter can validate the content of their own presentation.  How do we
> deal with attacks that give different users different content?  I claim
> that an attack that presents different content to people in the same
> physical room looking at the same LCD is outside of the scope of
> ABFAB:-)
> If we make the context clear--that we're talking about a networked
> LCD--is this example more clear?

absolutely! I was indeed thinking of a conference WB

> 4.2 p19 last paragraph: i think if you explain GSS-API CB you also need
> to explain EAP CB
> 
> I agree that this document needs  to discuss EAP channel binding. We
> propose to do that in the unwritten section 6.1 as part of the
> deployment discussion.
> I guess we could briefly discuss in section 3 as well.
> 4.3 p19 "Using host based service...": Why does ABFAB need to adopt this
> approach?
> 
> 
> We need to adopt this approach if we want ABFAB to work with IMAP, SMTP,
> LDAP, SSH, NFS or a variety of other protocols that use this naming
> approach.  We could alternatively update all those specifications and
> update all the implementations that use generic frameworks such as SSPI
> or Cyrus SASL.  This is a case where following the existing standards
> makes deploymentand implementation easier.

right, that makes sense, and should be stated

> Can you suggest additional text for the last paragraph of this section
> to better clarify?

I'll try

Klaas

From [email-masked]  Mon Jan 10 15:51:50 2011
From: Sam Hartman <[email-masked]>
To: Eliot Lear <[email-masked]>
Date: Mon, 10 Jan 2011 18:54:03 -0500
Cc: [email-masked], [email-masked]
Subject: Re: [abfab] Multiple attribute providers in an authentication

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

    Eliot> Perhaps what you are saying is that if there is absolutely no
    Eliot> requirement that the IdP trust the attribute provider at all,
    Eliot> that it simply passes bits, then there is a risk that the
    Eliot> information returned might not be related to the principal.
    Eliot> I would suggest that it is incumbent on the attribute
    Eliot> provider to at least make an assurance that it won't happen,
    Eliot> because you're right- the RP cannot be assured otherwise
    Eliot> because it may not have sufficient information or even
    Eliot> authorization to reference the principal to the RP.

That's one case.
Another case is where say you are linking principals based on names and
you have two principals with the same name. E.G. I want to provide an
assertion about credit availability. My credit score attribute provider
can linke based on SSN (in the US) or name.
The IDP doesn't have the SSN, so it has to ask about the name.
What happens if the linking is off.

    Eliot> One other challenge here would be to consider whether it is
    Eliot> permissible that the unique index or name of the principal in
    Eliot> the context of the attribute provider could leak to the RP.
    Eliot> If that name is covered by a signature, it cannot easily be
    Eliot> removed.

O, thanks for enumerating this one!

From [email-masked]  Mon Jan 10 23:59:15 2011
Date: Tue, 11 Jan 2011 09:01:27 +0100
From: =?ISO-8859-1?Q?Gabriel_L=F3pez?= <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [abfab] Multiple attribute providers in an authentication

El 10/01/11 20:17, Sam Hartman escribi�:
>
> Things get a lot more messy  when assertions from multiple IDPs are
> included.
> What does it mean to include them in the AAA transport?  I can think of
> several trust models that are appropriate depending on deployment:
>
> * The IDP corresponding to the subject's NAI has validated these
>    additional assertions and wishes to assert that the attributes can be
>    trusted. "If you trust me then you should trust these." Here, the
>    assertions are being included either for convenience of packaging the
>    attributes into some form the RP can process or because it is possible
>    that the RP may be able to validate some signature and trust the
>    attribute source more than the IDP.
It should require a trust relationship between attribute providers and 
idp, in order to validate attribute assertions before to sent them all 
together to the RP. I just want to remark the requirement of this trust 
relationship.
> * The subject IDP has performed SAML validation on the
>    assertions. However the IDP is making no claims about how trusted the
>    attributes included in the additional assertions are. Even if the IDP
>    would be permitted to make a claim made in an additional assertion,
>    the RP needs to make an independent policy decision about whether the
>    actual issuer should be permitted to make that claim.
>
you could include here XACML
> * Here are some assertions for the RP's convenience. The IDP makes no
>    claims about them; not even the implied claim that they have not been
>    modified in transit. They better be signed, the RP better have
>    metadata for their issuer, and the RP is more or less on its own.
I'm not sure to understand this point. Do you need the trust 
relationship between RP and idP?
> Another source of complexity surrounds how an IDP links an assertion to
> a subject. What confidence is the RP asserting that the additional
> assertion describes the same principal as the access-accept message.
>
> Another potential source of complexity is how does the IDP know what
> information to gather? Does the IDP just know somehow? Does the RP pass
> information back?
The RP could request specific attributes in a SAML Attribute Query. 
Beside, idP/attribute provider could decide what attributes be disclosed 
to the RP, by means of attribute release policies (XACML?)

regards, Gabi.
> How does the RP make the policy decisions it needs to make? How does it
> get metadata that is needed?
>
> I think this sort of issue will also have impacts for kitten, because
> we'll need to describe it in the naming extensions interface. It seems
> like ABFAB is not going to be the only group facing these sorts of
> discussions; Kerberos is in the middle of a similar discussion right
> now.
>
> _______________________________________________
> 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]  Wed Jan 12 07:15:19 2011
From: Sam Hartman <[email-masked]>
To: [email-masked]
Date: Wed, 12 Jan 2011 10:17:27 -0500
Subject: [abfab] We might want two sessions

I think we have a lot of things on the agenda next time:

* Architecture doc
* I just sat in on a call and I believe there will be a proposed use
* case doc
* gss main spec
* Gss naming spec
* The AAA SAML doc
* Discussion of where our dependencies are
** naming exts from kitten
** channel binding from EMU

We didn't even get to the gss naming document last time, and we had more
SAML discussion than we really had time for.

It's also fairly likely that we're going to have some implementation
meetings shortly before the IETF, so we will hopefully have a lot of
progress and thus issues to bring up at IETF.

I wonder whether 3 or 4 hours might make more sense.  I think we could
find easy points for session breaks.

From [email-masked]  Wed Jan 12 07:29:33 2011
From: Josh Howlett <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Wed, 12 Jan 2011 15:31:43 +0000
Accept-Language: en-GB, en-US
Cc: Josh Howlett <[email-masked]>
Subject: [abfab] FYI: Project Moonshot meeting, 24-25 March, Prague

Project Moonshot, which is building an Abfab implementation, is planning to=
 have its second meeting on 24-25 March in Prague, immediately preceding IE=
TF 80. We will be discussing our implementation on Thursday, and testing it=
 on Friday.

There will not be any Abfab standardisation-related discussion, although we=
 will bring any issues that arise during our discussions to the Abfab WG me=
eting where they are relevant.

This is an open meeting. However, space is limited and so please let me kno=
w if you would like to attend.

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 Oxford, Didcot, Oxfordshire. OX11 0SG

From [email-masked]  Thu Jan 13 00:01:41 2011
Date: Thu, 13 Jan 2011 09:03:57 +0100
From: Leif Johansson <[email-masked]>
To: [email-masked]
Subject: Re: [abfab] We might want two sessions

On 01/12/2011 04:17 PM, Sam Hartman wrote:
> 
> 
> I think we have a lot of things on the agenda next time:
> 
> * Architecture doc
> * I just sat in on a call and I believe there will be a proposed use
> * case doc
> * gss main spec
> * Gss naming spec
> * The AAA SAML doc
> * Discussion of where our dependencies are
> ** naming exts from kitten
> ** channel binding from EMU

Less urgent but still worth considering:

- - diameter spec (we will probably have a candidate)
- - presentation on the nfsv4/pnfs use case

> 
> We didn't even get to the gss naming document last time, and we had more
> SAML discussion than we really had time for.
> 
> It's also fairly likely that we're going to have some implementation
> meetings shortly before the IETF, so we will hopefully have a lot of
> progress and thus issues to bring up at IETF.
> 
> 
> I wonder whether 3 or 4 hours might make more sense.  I think we could
> find easy points for session breaks.

We could try to go for 2 x 2 hours but I need to know that people will
show up even if this means one of the sessions is on Friday!

The yang group had good experience with having 2 sessions with the more
generally accessible topics on the first "mid-week" session and a Friday
session with topics that required more deep insight and active
participation.

How does that sound?

	Cheers Leif

From [email-masked]  Thu Jan 13 07:09:36 2011
From: Sam Hartman <[email-masked]>
To: Leif Johansson <[email-masked]>
Date: Thu, 13 Jan 2011 10:11:50 -0500
Cc: [email-masked]
Subject: Re: [abfab] We might want two sessions

I would not explicitly ask for a Friday session, but yes you might well
get it.  It is going to be a lot for people who fly in the week before
for the project moonshot meeting.  However, I'll certainly be there on
Friday.

From [email-masked]  Fri Jan 14 04:11:37 2011
Date: Fri, 14 Jan 2011 13:13:57 +0100
From: Leif Johansson <[email-masked]>
To: [email-masked]
Subject: Re: [abfab] We might want two sessions

On 01/13/2011 04:11 PM, Sam Hartman wrote:
> I would not explicitly ask for a Friday session, but yes you might well
> get it.  It is going to be a lot for people who fly in the week before
> for the project moonshot meeting.  However, I'll certainly be there on
> Friday.

Yeah you can't ask for session-times, only request conflict avoidance
but I was thinking that we should _assume_ that a second session winds
up on the Friday.

	MVH leifj

From [email-masked]  Fri Jan 14 06:05:03 2011
Date: Fri, 14 Jan 2011 15:07:21 +0100
From: Leif Johansson <[email-masked]>
To: [email-masked]
Subject: Re: [abfab] We might want two sessions

On 01/14/2011 01:13 PM, Leif Johansson wrote:
> On 01/13/2011 04:11 PM, Sam Hartman wrote:
>> I would not explicitly ask for a Friday session, but yes you might well
>> get it.  It is going to be a lot for people who fly in the week before
>> for the project moonshot meeting.  However, I'll certainly be there on
>> Friday.
> 
> Yeah you can't ask for session-times, only request conflict avoidance
> but I was thinking that we should _assume_ that a second session winds
> up on the Friday.

Since I've not heard any protests I've changed our request to 2 x 2h

	Cheers Leif

From [email-masked]  Fri Jan 14 06:23:34 2011
Date: Fri, 14 Jan 2011 15:25:52 +0100
From: Klaas Wierenga <[email-masked]>
To: [email-masked]
Subject: Re: [abfab] We might want two sessions

On 1/14/11 3:07 PM, Leif Johansson wrote:
> On 01/14/2011 01:13 PM, Leif Johansson wrote:
>> On 01/13/2011 04:11 PM, Sam Hartman wrote:
>>> I would not explicitly ask for a Friday session, but yes you might well
>>> get it.  It is going to be a lot for people who fly in the week before
>>> for the project moonshot meeting.  However, I'll certainly be there on
>>> Friday.
> 
>> Yeah you can't ask for session-times, only request conflict avoidance
>> but I was thinking that we should _assume_ that a second session winds
>> up on the Friday.
> 
> Since I've not heard any protests I've changed our request to 2 x 2h

and in case we get a Friday slot, those that don't show up have to buy
cookies for the next meeting ;-)

Klaas

From [email-masked]  Fri Jan 14 06:27:57 2011
Date: Fri, 14 Jan 2011 15:30:17 +0100
From: Leif Johansson <[email-masked]>
To: [email-masked]
Subject: Re: [abfab] We might want two sessions

On 01/14/2011 03:25 PM, Klaas Wierenga wrote:
> On 1/14/11 3:07 PM, Leif Johansson wrote:
>> On 01/14/2011 01:13 PM, Leif Johansson wrote:
>>> On 01/13/2011 04:11 PM, Sam Hartman wrote:
>>>> I would not explicitly ask for a Friday session, but yes you might well
>>>> get it.  It is going to be a lot for people who fly in the week before
>>>> for the project moonshot meeting.  However, I'll certainly be there on
>>>> Friday.
> 
>>> Yeah you can't ask for session-times, only request conflict avoidance
>>> but I was thinking that we should _assume_ that a second session winds
>>> up on the Friday.
> 
>> Since I've not heard any protests I've changed our request to 2 x 2h
> 
> and in case we get a Friday slot, those that don't show up have to buy
> cookies for the next meeting ;-)

and we will make sure ekr is there to eat them!

From [email-masked]  Fri Jan 14 06:49:24 2011
From: Josh Howlett <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Fri, 14 Jan 2011 14:51:46 +0000
Accept-Language: en-GB, en-US
Cc: Josh Howlett <[email-masked]>
Subject: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml

Discussions at IETF79 and on this list have indicated some agreement around=
 the following:

 - that the attribute should be scoped explicitly for SAML Request/Response=
 messages, rather than SAML constructs in general. I'm not unhappy about th=
is, as it makes the attribute's internal format (even) simpler and avoids t=
he need for an IANA registry of message types. I've also been unable to fin=
d any compelling reason why a RADIUS server might want care about the type =
of SAML construct contained within the attribute, particularly if it's eith=
er going to be a Request or Response message.

 - the document needs to discuss how the attribute can be used with RADIUS =
transport for exchanges that are not necessarily associated with an EAP aut=
hentication exchange; for example, to support SAML attribute requests at so=
me arbitrary time after authentication; or attribute requests to an attribu=
te authority that is not the Identity Provider. (This may turn the document=
 into more of a 'binding' specification (in SAML sense), than simply an att=
ribute specification, but I'm not sure if that matters or not).

Comments welcome. I hope to crank out an 01 sometime next week.

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 Oxford, Didcot, Oxfordshire. OX11 0SG

From [email-masked]  Fri Jan 14 06:58:13 2011
From: Josh Howlett <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Fri, 14 Jan 2011 15:00:33 +0000
Accept-Language: en-GB, en-US
Cc: Josh Howlett <[email-masked]>
Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml

> Discussions at IETF79 and on this list have indicated some agreement
> around the following:

I forgot to mention that we were also going to constrain the attribute for =
RDAIUS-based transport, and have a second document dealing with Diameter.

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 Oxford, Didcot, Oxfordshire. OX11 0SG

From [email-masked]  Fri Jan 14 07:13:28 2011
From: Sam Hartman <[email-masked]>
To: Josh Howlett <[email-masked]>
Date: Fri, 14 Jan 2011 10:15:39 -0500
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml

>>>>> "Josh" == Josh Howlett <[email-masked]> writes:
    Josh>  - the document needs to discuss how the attribute can be used
    Josh> with RADIUS transport for exchanges that are not necessarily
    Josh> associated with an EAP authentication exchange; for example,
    Josh> to support SAML attribute requests at some arbitrary time
    Josh> after authentication; 

Sounds good

    Josh> or attribute requests to an attribute
    Josh> authority that is not the Identity Provider. 

I'm nervous about this for the trust model issues I brought up.
I could see using the same attribute in the cases where the trust model
is going to be the same.
However I definitely think we want a different attribute if we want
different processing semantics in the RP.

One particularly thorny issue will be what the IDP should do with a
request for an attribute from a different provider that it could satisfy
but not under the trust model the RP was hoping for.

    Josh> (This may turn
    Josh> the document into more of a 'binding' specification (in SAML
    Josh> sense), than simply an attribute specification, but I'm not
    Josh> sure if that matters or not).

I think ending up with a binding is very good.

    Josh> Comments welcome. I hope to crank out an 01 sometime next
    Josh> week.

    Josh> Josh.

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

    Josh> _______________________________________________ abfab mailing
    Josh> list [email-masked]
    Josh> https://www.ietf.org/mailman/listinfo/abfab

From [email-masked]  Fri Jan 14 08:25:21 2011
From: Josh Howlett <[email-masked]>
To: Sam Hartman <[email-masked]>
Date: Fri, 14 Jan 2011 16:27:42 +0000
Accept-Language: en-GB, en-US
Cc: Josh Howlett <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml

>     Josh> or attribute requests to an attribute
>     Josh> authority that is not the Identity Provider.
>=20
> I'm nervous about this for the trust model issues I brought up.
> I could see using the same attribute in the cases where the trust model
> is going to be the same.
> However I definitely think we want a different attribute if we want
> different processing semantics in the RP.

I don't follow this. Why can't we put these semantics to the SAML layer?

> One particularly thorny issue will be what the IDP should do with a
> request for an attribute from a different provider that it could
> satisfy
> but not under the trust model the RP was hoping for.

I agree its thorny, but is this actually a use-case that we care about? I w=
ould prefer to punt it to the business layer.
=20
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 Oxford, Didcot, Oxfordshire. OX11 0SG

From [email-masked]  Fri Jan 14 08:30:34 2011
From: Sam Hartman <[email-masked]>
To: Josh Howlett <[email-masked]>
Date: Fri, 14 Jan 2011 11:32:48 -0500
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml

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

    Josh> or attribute requests to an attribute authority that is not
    Josh> the Identity Provider.
    >> 
    >> I'm nervous about this for the trust model issues I brought up.
    >> I could see using the same attribute in the cases where the trust
    >> model is going to be the same.  However I definitely think we
    >> want a different attribute if we want different processing
    >> semantics in the RP.

    Josh> I don't follow this. Why can't we put these semantics to the
    Josh> SAML layer?

I think that both the RP and intermediates need to understand what trust
model the IDP is using--at least to the extent that they need to
understand what claims about the attributes the IDP is making.
See the three trust models in my last mail.

I want this document to either have a single trust model or to explain
how an RP and intermediate determines the trust model.
I guess that could be SAML layer if there is a good mechanism for that.

    >> One particularly thorny issue will be what the IDP should do with
    >> a request for an attribute from a different provider that it
    >> could satisfy but not under the trust model the RP was hoping
    >> for.

    Josh> I agree its thorny, but is this actually a use-case that we
    Josh> care about? I would prefer to punt it to the business layer.
 
    Josh> Josh.

Explain what it would mean to punt on this; I'm confused as to how we
could do that if multiple trust models are in play.

From [email-masked]  Fri Jan 14 08:54:58 2011
From: "Cantor, Scott E." <[email-masked]>
To: Sam Hartman <[email-masked]>, Josh Howlett <[email-masked]>
Date: Fri, 14 Jan 2011 16:57:24 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml

> I want this document to either have a single trust model or to explain
> how an RP and intermediate determines the trust model.
> I guess that could be SAML layer if there is a good mechanism for that.

There are no standards I'm aware of in any domain for addressing attribute-=
related trust distinctions. That's left to applications at the moment.

> Explain what it would mean to punt on this; I'm confused as to how we
> could do that if multiple trust models are in play.

It's assumed that deployers are making decisions about how to use attribute=
s based on their OOB information about where they come from and what's been=
 guaranteed about them. That extends to using them as input to other attrib=
ute sources.

The filtering process, for example, imposes whatever rules might exist abou=
t who can assert particular attributes based on the assumptions the applica=
tion wants to make about them.

-- Scott

From [email-masked]  Fri Jan 14 09:43:35 2011
From: Sam Hartman <[email-masked]>
To: "Cantor\, Scott E." <[email-masked]>
Date: Fri, 14 Jan 2011 12:45:50 -0500
Cc: Josh Howlett <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml

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

    >> Explain what it would mean to punt on this; I'm confused as to
    >> how we could do that if multiple trust models are in play.

    Cantor,> It's assumed that deployers are making decisions about how
    Cantor,> to use attributes based on their OOB information about
    Cantor,> where they come from and what's been guaranteed about
    Cantor,> them. That extends to using them as input to other
    Cantor,> attribute sources.

Right.  I don't think we can do this and build an interoperable secure
standard.  I think that the question about whether an RP that trusts the
IDP should rely on the attribute or not needs to be answered in-band.

--Sam

From [email-masked]  Fri Jan 14 10:38:53 2011
From: "Cantor, Scott E." <[email-masked]>
To: Sam Hartman <[email-masked]>
Date: Fri, 14 Jan 2011 18:41:16 +0000
Accept-Language: en-US
Cc: Josh Howlett <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml

> Right.  I don't think we can do this and build an interoperable secure
> standard.  I think that the question about whether an RP that trusts the
> IDP should rely on the attribute or not needs to be answered in-band.

But by that measure, LDAP isn't an interoperable secure standard either.
=20
-- Scott

From [email-masked]  Fri Jan 14 12:10:44 2011
From: Sam Hartman <[email-masked]>
To: "Cantor\, Scott E." <[email-masked]>
Date: Fri, 14 Jan 2011 15:12:55 -0500
Cc: Josh Howlett <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml

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

    >> Right.  I don't think we can do this and build an interoperable
    >> secure standard.  I think that the question about whether an RP
    >> that trusts the IDP should rely on the attribute or not needs to
    >> be answered in-band.

    Cantor,> But by that measure, LDAP isn't an interoperable secure
    Cantor,> standard either.
I'm not sure I see what you're getting at.
I'd certainly expect a schema or derictory organization to indicate if
    information was being stored in the directory that the directory
    itself was not vouching for.

Actually we have been somewhat explicit about some of this.
For example, in the case of NSS (ldap nis etc) we've at least implicitly
said that a client can trust account information from a directory.

However in the case of PKI-related attributes we've not made this trust
assumption.  If I find a certificate in a directory I'm still expected
to perform cert validation according to the PKIX specs.

We're explicitly saying with draft-ietf-saml-aaa that a RP SHOULD trust
the information and not perform validation for the authentication
response.  We need to do that in order to get interoperability.  Once
we've done that, we need to make it clear when that doesn't hold.

--Sam

From [email-masked]  Fri Jan 14 12:24:28 2011
From: "Cantor, Scott E." <[email-masked]>
To: Sam Hartman <[email-masked]>
Date: Fri, 14 Jan 2011 20:26:51 +0000
Accept-Language: en-US
Cc: Josh Howlett <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml

>   I'd certainly expect a schema or derictory organization to indicate if
>     information was being stored in the directory that the directory
>     itself was not vouching for.

How would that indication be done?

That doesn't match the reality. Many directory attributes contain a lot of =
ambiguity about who is actually in control of the values. This doesn't beco=
me in issue because you switch the encoding from ASN.1 to XML.

> Actually we have been somewhat explicit about some of this.
> For example, in the case of NSS (ldap nis etc) we've at least implicitly
> said that a client can trust account information from a directory.

That's an application choice, then, I guess by assuming away the possibilit=
y of referrals and multiple domains of authority. Federated applications ca=
n't ignore these issues, though, and currently they don't get this for free=
 from the infrastructure. If you want to go there, this all gets much harde=
r.

> However in the case of PKI-related attributes we've not made this trust
> assumption.  If I find a certificate in a directory I'm still expected
> to perform cert validation according to the PKIX specs.

Validating the certificate often results in an implicit acceptance of the i=
nformation in it as being vouched for by the issuer, though. That's no diff=
erent than authenticating the LDAP server or the IdP. But it isn't really e=
xplicit in the standards, any more than it is with LDAP or SAML. In PKI, it=
's the CPS and what not that are supposed to address it (and that's not mac=
hine-level).

> We're explicitly saying with draft-ietf-saml-aaa that a RP SHOULD trust
> the information and not perform validation for the authentication
> response.  We need to do that in order to get interoperability.  Once
> we've done that, we need to make it clear when that doesn't hold.

I think you're talking about two different kinds of trust here. The SHOULD =
in the draft AFAIK is referring to the technical trust that it was duly iss=
ued by the issuer and hasn't been tampered with.

It wasn't AFAIK meant to say anything about the "truth" of the contents.

One point that does come up in SAML is that you can have conditions that li=
mit the validity. I'm not sure if that aspect of validation has been assume=
d away or not, but it's not critical to this particular thread right now.

-- Scott

From [email-masked]  Fri Jan 14 12:33:34 2011
From: "Cantor, Scott E." <[email-masked]>
To: Sam Hartman <[email-masked]>
Date: Fri, 14 Jan 2011 20:36:00 +0000
Accept-Language: en-US
Cc: Josh Howlett <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml

BTW, I don't want to make it sound like the standard attitude in an SP is "=
I have no idea if the IdP is actually right about this information". Obviou=
sly that's nonsensical. Just the opposite, people writing apps assume that =
if the IdP is "trusted", it's trusted to say what it's saying, and you (hop=
efully) have filters at your disposal to implement exceptions to that. Impl=
ementations without such filtering support obviously are leaving that probl=
em to the app.

-- Scott

From [email-masked]  Fri Jan 14 12:45:29 2011
From: Sam Hartman <[email-masked]>
To: "Cantor\, Scott E." <[email-masked]>
Date: Fri, 14 Jan 2011 15:47:44 -0500
Cc: Josh Howlett <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml

Let me try and be explicit about what I'm wanting.

We're saying that when you receive a SAML authentication response  from
this AAA attribute  you SHOULD NOT call a saml validation routine.
You MUST still decide what statements you will allow the IDP to make,
but AAA is handling the technical trust.

I pointed to a couple of trust model earlier in the week.
They effect two decisions the SP needs to make:

1)  does it call SAML validation and if so, what does it do with a
failure result

2)  When evaluating whether the issuer is permitted to make the
statement being claimed, does it use its rules for the IDP or for the
actual issuer. I.E. does it assume that the IDP has vouched for the
statement or simply passed it along.

These are both technical decisions that affect interoperability and
security.  My claim is that to produce a technical specification that
meets the requirements of RFC 2026 without known technical omissions we
need to tell implementations what to do in these cases.

I agree with you that various levels of ambiguity have been used with
regard to these sorts of issues in other standards, and we have not been
perfect.  However I do think we have considered these sorts of
issues. Often, the answer we've given is "that decision belongs at the
next layer." I don't think we can do that here, although I'd be
interested in evaluating a proposal to do so if someone made one. I
would not support a proposal that required per-IDP configuration.

--Sam

From [email-masked]  Fri Jan 14 12:58:27 2011
From: "Cantor, Scott E." <[email-masked]>
To: Sam Hartman <[email-masked]>
Date: Fri, 14 Jan 2011 21:00:52 +0000
Accept-Language: en-US
Cc: Josh Howlett <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml

> 2)  When evaluating whether the issuer is permitted to make the
> statement being claimed, does it use its rules for the IDP or for the
> actual issuer. I.E. does it assume that the IDP has vouched for the
> statement or simply passed it along.

Well, if by IdP you mean the identity intrinsically associated with the AAA=
 server, then I guess I would have to say that it's reasonable to say that =
you get that technical trust from the AAA layer, but that any other asserti=
ons from other issuers should be signed and verified independently (meaning=
 the rules would be based on the actual issuer).

In practice, I don't think IdP-side aggregation works all that well and the=
 most common SAML profiles basically preclude it unless the IdP reissues th=
e data itself, so I tend to focus on doing it at the SP. But  then I write =
SPs, so that's a bias. I think when we do things like re-issue data at the =
IdP end, there's not usually any kind of indicator to the SP that this was =
done, because the whole point is often to hide it.

> These are both technical decisions that affect interoperability and
> security.  My claim is that to produce a technical specification that
> meets the requirements of RFC 2026 without known technical omissions we
> need to tell implementations what to do in these cases.

I agree with you that there should be a clear statement about the validity =
assumptions one should make about any additional assertions, because normal=
ly there is no such assumption...you always validate any assertions you get=
. Trying to dodge that requirement (or optimize it out) introduces the need=
 to be explicit.

> I agree with you that various levels of ambiguity have been used with
> regard to these sorts of issues in other standards, and we have not been
> perfect.  However I do think we have considered these sorts of
> issues. Often, the answer we've given is "that decision belongs at the
> next layer." I don't think we can do that here, although I'd be
> interested in evaluating a proposal to do so if someone made one. I
> would not support a proposal that required per-IDP configuration.

I think I understand you to be saying that you're solely concerned about th=
e technical trust component, and not the business level aspect of the truth=
 of the data or the right of the issuer to speak on what it says. If that's=
 the case, I agree with you, and it should not require explicit configurati=
on per source to control whether validation is done.

We do, as I mentioned briefly, need to discuss SAML conditions, though, eve=
n in the case of the assertions from the single IdP. *Something* has to eva=
luate them, or they have to be precluded by profile from appearing.

-- Scott

From [email-masked]  Mon Jan 17 01:05:15 2011
Date: Mon, 17 Jan 2011 10:07:43 +0100
From: Leif Johansson <[email-masked]>
To: [email-masked]
Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml

(no chair hat on for this)

> In practice, I don't think IdP-side aggregation works all that well and the most common SAML profiles basically preclude it unless the IdP reissues the data itself, so I tend to focus on doing it at the SP. But  then I write SPs, so that's a bias. I think when we do things like re-issue data at the IdP end, there's not usually any kind of indicator to the SP that this was done, because the whole point is often to hide it.
> 

There is a bit of operational experience from so call hub-and-spoke
federations to support this. In the federation operators community
we've seen example of, ahem, inventiveness at the SAML layer to
work around problems introduced by IdP aggregation.

Control question for Sam and Scott: is it possible (and reasonably
easy) to do SP-centric attribute aggregation for abfab, by which I
mean having the SP issue additional attribute queries to IdPs within
the AAA-centric trust model proposed by Sam and Josh?

	Cheers Leif

From [email-masked]  Mon Jan 17 06:09:19 2011
From: Josh Howlett <[email-masked]>
To: Leif Johansson <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 17 Jan 2011 14:12:09 +0000
Accept-Language: en-GB, en-US
Cc: Josh Howlett <[email-masked]>
Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml

> Control question for Sam and Scott: is it possible (and reasonably
> easy) to do SP-centric attribute aggregation for abfab, by which I
> mean having the SP issue additional attribute queries to IdPs within
> the AAA-centric trust model proposed by Sam and Josh?

Yes, possible and easy (assuming, obviously, we can assume that the SPs and=
 IdP have a common identifier for the subject).

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 Oxford, Didcot, Oxfordshire. OX11 0SG

From [email-masked]  Mon Jan 17 06:22:32 2011
Date: Mon, 17 Jan 2011 15:25:00 +0100
From: Leif Johansson <[email-masked]>
To: Josh Howlett <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml

On 01/17/2011 03:12 PM, Josh Howlett wrote:
>> Control question for Sam and Scott: is it possible (and reasonably
>> easy) to do SP-centric attribute aggregation for abfab, by which I
>> mean having the SP issue additional attribute queries to IdPs within
>> the AAA-centric trust model proposed by Sam and Josh?
> 
> Yes, possible and easy (assuming, obviously, we can assume that the SPs and IdP have a common identifier for the subject).

Right, that is always an issue but it is one I'm (no chair again) ok to
live with...

	Cheers Leif

From [email-masked]  Mon Jan 17 06:55:32 2011
From: Josh Howlett <[email-masked]>
To: "Cantor, Scott E." <[email-masked]>, Sam Hartman <[email-masked]>
Date: Mon, 17 Jan 2011 14:58:21 +0000
Accept-Language: en-GB, en-US
Cc: Josh Howlett <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml

Scott wrote:=20
> In practice, I don't think IdP-side aggregation works all that well and
> the most common SAML profiles basically preclude it unless the IdP
> reissues the data itself, so I tend to focus on doing it at the SP. But
> then I write SPs, so that's a bias.

I also prefer SP-side aggregation. I'm personally okay with IdP-side aggreg=
ation within ABFAB scope, if we can do without authentication of aggregated=
 issuers (i.e. an aggregated issuer is analogous to an IdP-local LDAP direc=
tory).

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 Oxford, Didcot, Oxfordshire. OX11 0SG

From [email-masked]  Mon Jan 17 07:22:20 2011
Date: Mon, 17 Jan 2011 16:24:52 +0100
From: Klaas Wierenga <[email-masked]>
To: [email-masked]
Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml

On 1/17/11 3:12 PM, Josh Howlett wrote:
>> Control question for Sam and Scott: is it possible (and reasonably
>> easy) to do SP-centric attribute aggregation for abfab, by which I
>> mean having the SP issue additional attribute queries to IdPs within
>> the AAA-centric trust model proposed by Sam and Josh?
> 
> Yes, possible and easy (assuming, obviously, we can assume that the SPs and IdP have a common identifier for the subject).

can the SP only get attributes through the IdP?

Klaas

From [email-masked]  Mon Jan 17 07:28:24 2011
Date: Mon, 17 Jan 2011 16:30:54 +0100
From: Leif Johansson <[email-masked]>
To: [email-masked]
Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml

On 01/17/2011 04:24 PM, Klaas Wierenga wrote:
> On 1/17/11 3:12 PM, Josh Howlett wrote:
>>> Control question for Sam and Scott: is it possible (and reasonably
>>> easy) to do SP-centric attribute aggregation for abfab, by which I
>>> mean having the SP issue additional attribute queries to IdPs within
>>> the AAA-centric trust model proposed by Sam and Josh?
> 
>> Yes, possible and easy (assuming, obviously, we can assume that the SPs and IdP have a common identifier for the subject).
> 
> can the SP only get attributes through the IdP?

An AA is an IdP too...

From [email-masked]  Mon Jan 17 07:34:19 2011
From: Josh Howlett <[email-masked]>
To: Klaas Wierenga <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 17 Jan 2011 15:37:09 +0000
Accept-Language: en-GB, en-US
Cc: Josh Howlett <[email-masked]>
Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml

> >> Control question for Sam and Scott: is it possible (and reasonably
> >> easy) to do SP-centric attribute aggregation for abfab, by which I
> >> mean having the SP issue additional attribute queries to IdPs within
> >> the AAA-centric trust model proposed by Sam and Josh?
> >
> > Yes, possible and easy (assuming, obviously, we can assume that the
> > SPs and IdP have a common identifier for the subject).
>=20
> can the SP only get attributes through the IdP?

Sorry, can you clarify the question? (I thought I answered that in my respo=
nse)

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 Oxford, Didcot, Oxfordshire. OX11 0SG

From [email-masked]  Mon Jan 17 08:04:26 2011
Date: Mon, 17 Jan 2011 17:06:59 +0100
From: Klaas Wierenga <[email-masked]>
To: Josh Howlett <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml

On 1/17/11 4:37 PM, Josh Howlett wrote:
>>>> Control question for Sam and Scott: is it possible (and reasonably
>>>> easy) to do SP-centric attribute aggregation for abfab, by which I
>>>> mean having the SP issue additional attribute queries to IdPs within
>>>> the AAA-centric trust model proposed by Sam and Josh?
>>>
>>> Yes, possible and easy (assuming, obviously, we can assume that the
>>> SPs and IdP have a common identifier for the subject).
>>
>> can the SP only get attributes through the IdP?
> 
> Sorry, can you clarify the question? (I thought I answered that in my response)

well, you state that the IdP and the SP need to have an identifier in
common for the subject. I was thinking about an attribute authority
different from the "original" IdP. So let's say I authenticate to my
school and the SP goes on and gets some aditional attributes from the
ministry of education... That is covered by Leif's statement "An AA is
an IdP too...", but I want to make sure that the trust model allows for
that kind of scenario's.

Klaas

From [email-masked]  Mon Jan 17 10:10:32 2011
From: Josh Howlett <[email-masked]>
To: Klaas Wierenga <[email-masked]>
Date: Mon, 17 Jan 2011 18:13:22 +0000
Accept-Language: en-GB, en-US
Cc: Josh Howlett <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml

> well, you state that the IdP and the SP need to have an identifier in
> common for the subject. I was thinking about an attribute authority
> different from the "original" IdP. So let's say I authenticate to my
> school and the SP goes on and gets some aditional attributes from the
> ministry of education... That is covered by Leif's statement "An AA is
> an IdP too...", but I want to make sure that the trust model allows for
> that kind of scenario's.

Yes, it does.

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 Oxford, Didcot, Oxfordshire. OX11 0SG

From [email-masked]  Tue Jan 18 07:32:44 2011
From: Sam Hartman <[email-masked]>
To: Josh Howlett <[email-masked]>
Date: Tue, 18 Jan 2011 10:35:18 -0500
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml

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

    >> Control question for Sam and Scott: is it possible (and
    >> reasonably easy) to do SP-centric attribute aggregation for
    >> abfab, by which I mean having the SP issue additional attribute
    >> queries to IdPs within the AAA-centric trust model proposed by
    >> Sam and Josh?

    Josh> Yes, possible and easy (assuming, obviously, we can assume
    Josh> that the SPs and IdP have a common identifier for the
    Josh> subject).

Josh, I suspect you are right, but the details are not clear to me.
How does the SP address the request to a particular AA?

From [email-masked]  Tue Jan 18 08:06:04 2011
From: Josh Howlett <[email-masked]>
To: Sam Hartman <[email-masked]>
Date: Tue, 18 Jan 2011 16:08:56 +0000
Accept-Language: en-GB, en-US
Cc: Howlett <[email-masked]>, "[email-masked]" <[email-masked]>, Josh
Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml

>     >> Control question for Sam and Scott: is it possible (and
>     >> reasonably easy) to do SP-centric attribute aggregation for
>     >> abfab, by which I mean having the SP issue additional attribute
>     >> queries to IdPs within the AAA-centric trust model proposed by
>     >> Sam and Josh?
>=20
>     Josh> Yes, possible and easy (assuming, obviously, we can assume
>     Josh> that the SPs and IdP have a common identifier for the
>     Josh> subject).
>=20
> Josh, I suspect you are right, but the details are not clear to me.

Nor me in truth; I suspect that I am about to discover it was inadvisable o=
f me to claim 'easy' :-)

> How does the SP address the request to a particular AA?

The model that I have in mind is that we specify a set of standard endpoint=
 locator names for different type of Issuer roles. These can be used, in co=
njunction with the NAI realm of the Issuer, to construct a complete NAI.

e.g. say we specify the "saml-20-aa" name to mean a SAML 2.0 attribute auth=
ority. An SP wanting to route a message to this actor to example.com prefix=
es the realm of the intended Issuer with this, thus "saml-20-aa.example.com=
". The AAA SAML attribute within this request message contains a SAML Reque=
st message containing the identifier for the subject.=20

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 Oxford, Didcot, Oxfordshire. OX11 0SG

From [email-masked]  Tue Jan 18 08:15:20 2011
Date: Tue, 18 Jan 2011 17:17:55 +0100
From: Klaas Wierenga <[email-masked]>
To: [email-masked]
Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml

On 1/18/11 5:08 PM, Josh Howlett wrote:
>>     >> Control question for Sam and Scott: is it possible (and
>>     >> reasonably easy) to do SP-centric attribute aggregation for
>>     >> abfab, by which I mean having the SP issue additional attribute
>>     >> queries to IdPs within the AAA-centric trust model proposed by
>>     >> Sam and Josh?
>>
>>     Josh> Yes, possible and easy (assuming, obviously, we can assume
>>     Josh> that the SPs and IdP have a common identifier for the
>>     Josh> subject).
>>
>> Josh, I suspect you are right, but the details are not clear to me.
> 
> Nor me in truth; I suspect that I am about to discover it was inadvisable of me to claim 'easy' :-)
> 
>> How does the SP address the request to a particular AA?
> 
> The model that I have in mind is that we specify a set of standard endpoint locator names for different type of Issuer roles. These can be used, in conjunction with the NAI realm of the Issuer, to construct a complete NAI.
> 
> e.g. say we specify the "saml-20-aa" name to mean a SAML 2.0 attribute authority. An SP wanting to route a message to this actor to example.com prefixes the realm of the intended Issuer with this, thus "saml-20-aa.example.com". The AAA SAML attribute within this request message contains a SAML Request message containing the identifier for the subject. 

ehrm, that means there can only be one AA per realm?

Klaas

> 
> 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 Oxford, Didcot, Oxfordshire. OX11 0SG
> 
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

From [email-masked]  Tue Jan 18 08:18:18 2011
From: Josh Howlett <[email-masked]>
To: Klaas Wierenga <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 18 Jan 2011 16:21:12 +0000
Accept-Language: en-GB, en-US
Cc: Josh Howlett <[email-masked]>
Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml

> > e.g. say we specify the "saml-20-aa" name to mean a SAML 2.0
> attribute authority. An SP wanting to route a message to this actor to
> example.com prefixes the realm of the intended Issuer with this, thus
> "saml-20-aa.example.com". The AAA SAML attribute within this request
> message contains a SAML Request message containing the identifier for
> the subject.
>=20
> ehrm, that means there can only be one AA per realm?

If that matters, I think you could have multiple AAs and disambiguate by ex=
tending the naming semantics of the NAI.

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 Oxford, Didcot, Oxfordshire. OX11 0SG

From [email-masked]  Tue Jan 18 08:18:26 2011
From: Sam Hartman <[email-masked]>
To: Josh Howlett <[email-masked]>
Date: Tue, 18 Jan 2011 11:20:54 -0500
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml

Hmm.  OK. This sounds like it is taking the authorization-only service a
bit further than I thought it worked today.
Interesting though.

From [email-masked]  Tue Jan 18 10:01:07 2011
Date: Tue, 18 Jan 2011 12:03:42 -0600
From: Tom Scavo <[email-masked]>
To: Josh Howlett <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, [email-masked]
Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml

On Tue, Jan 18, 2011 at 10:08 AM, Josh Howlett <[email-masked]> wrote:
>> =A0 =A0 >> Control question for Sam and Scott: is it possible (and
>> =A0 =A0 >> reasonably easy) to do SP-centric attribute aggregation for
>> =A0 =A0 >> abfab, by which I mean having the SP issue additional attribu=
te
>> =A0 =A0 >> queries to IdPs within the AAA-centric trust model proposed b=
y
>> =A0 =A0 >> Sam and Josh?
>>
>> =A0 =A0 Josh> Yes, possible and easy (assuming, obviously, we can assume
>> =A0 =A0 Josh> that the SPs and IdP have a common identifier for the
>> =A0 =A0 Josh> subject).
>>
>> Josh, I suspect you are right, but the details are not clear to me.
>
> Nor me in truth; I suspect that I am about to discover it was inadvisable=
 of me to claim 'easy' :-)

It depends on the trust relationship the SP has with the various AAs
in question, but in general, this is a hard problem. How does the SP
prove to the AA that the user is present and actively involved in the
transaction? The AA would have to have a fairly liberal attribute
release policy to hand out user attributes to the SP without some form
of user consent.

Tom

From [email-masked]  Tue Jan 18 10:55:51 2011
From: Josh Howlett <[email-masked]>
To: Tom Scavo <[email-masked]>
Date: Tue, 18 Jan 2011 18:58:42 +0000
Accept-Language: en-GB, en-US
Cc: Josh Howlett <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml

Tom,

> It depends on the trust relationship the SP has with the various AAs
> in question, but in general, this is a hard problem. How does the SP
> prove to the AA that the user is present and actively involved in the
> transaction? The AA would have to have a fairly liberal attribute
> release policy to hand out user attributes to the SP without some form
> of user consent.

Right, this is an important point. I don't think consent is a showstopper i=
n the sense that one can reasonably choose to not care about consent in man=
y scenarios. However, I agree that it would be very desirable to have a str=
ong story for consent.

ABFAB *may* provide a better approach for consent than that which can be ac=
hieved through the conventional HTTP-based bindings, because the architectu=
re posits an agent (the EAP peer) on the subject's host which could communi=
cate directly with any Issuer known by the subject (e.g. the AA uses some k=
ind of RPC to request user interaction through this agent). We have previou=
sly considered the agent as primarily a means of managing user interaction =
for identity selection, but it doesn't seem unreasonable to extend this to =
consent management.

I think we have previously concluded that it would be reasonable to apply t=
his kind of approach, but there isn't a concrete proposal on the table at t=
he moment. Suggestions 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 Oxford, Didcot, Oxfordshire. OX11 0SG

From [email-masked]  Wed Jan 19 15:15:46 2011
From: "Jim Schaad" <[email-masked]>
To: "'Sam Hartman'" <[email-masked]>, "'Klaas Wierenga'" <[email-masked]>
Date: Wed, 19 Jan 2011 15:36:39 -0800
Cc: [email-masked]
Subject: Re: [abfab] draft-lear-abfab-arch-01 posted

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Sam Hartman
> Sent: Monday, January 10, 2011 10:28 AM
> To: Klaas Wierenga
> Cc: [email-masked]
> Subject: Re: [abfab] draft-lear-abfab-arch-01 posted
> 
> Klaas, thanks so much for your comments.
> I'm responding as an individual not on behalf of the authors as a group.
> 
> I agree that we need to do a better job of discussing federation
selection;
> the current text does not do much about that.  This is definitely a good
> comment and something for us to work on.
> 
> You ask whether we intend to preclude SOAP. I think that's for you to tell
us:
> we've had a WG discussion on this topic and I think we have enough of a
> discussion to approach a consensus. My reading is that we are going to
focus
> on AAA transport but nothing will preclude soap.
> However it would be useful to get a consensus call from the chairs on
this.'

Are we looking at SOAP as a message format or at SOAP as a transport ?  I
don't think that they are necessarily the same thing.

> 
> I agree that the specific protocol flows could be moved later in the
document
> and that would improve things.
> I think it's a little complicated where you want this information: there
is some
> value in having the  diagrams fairly early.

I am in favor of having some diagrams really early in the processes.  I
think this really helps to get understanding setup early.  But I tend to be
a very pictorial person.

> 
> You propose introducing more abstraction: having an abstract discussion of
> the aspects of the system and then discussing specific technology choices.
> Definitely for the application integration, where we've acknowledged in
our
> charter that other options are possible, we should do this. Also, we
should
> separate the abstract discussion of AAA from RADIUS and Diameter.
> However, the use of AAA, EAP, and to some extent SAML is baked in at a
> fairly deep level.
> So, we're not obligated to treat things abstractly.
> We can if it makes the document flow better. However sometimes it is
easier
> to understand one concrete system than a bunch of abstractions.
> So, can we explore how valuable that will actually be?
> 
> 
> 3.3 p14 "GSS-API is specified...": What is the relevance of mentioning the
> sub-operations of the initial context exchange?
> 
> 
> No, not really.
> I thought it might, but it didn't end up being useful.
> 
> 
> 4 p17 It seems that part of this discussion belongs higher up in the
document
> (design goals?) and part is implementation choices
> 
> It's hard to discuss this abstractly. I don't think we have enough
community
> experience for that discussion nor do I think we understand what this
would
> mean abstractly well enough to have this discussion before the discussions
of
> concrete technologies.
> So, I'm sympathetic to the concern, but I'm not sure I know how to do what
> you ask.
> If you want to throw something together or have a chat, we could do that.
> 
> 4.1 p17: explain better what is confusing about the mutual authentication
> terminology
> 
> It's that to some people mutual authentication implies that the client's
> identity is being released.
> In GSS, that's not true.
> 
> 
> 4.2 p18 first paragraph: the sentence starting with "Even when it is
checked"
> is not a well-formed sentence, and I don't understand what it should read.
> 
> Ah, a typeo. s:if the trust:the trust
> 4.2 p19: I don't really understand the whiteboard example, how is the user
> able to validate the content that is being displayed? What if some users
get
> (slightly) different content than others?
> 
> Note here we're talking about a physical electronic LCD whiteboard in a
> room, not some shared conference whiteboard software.Typically a
> presenter can validate the content of their own presentation.  How do we
> deal with attacks that give different users different content?  I claim
that an
> attack that presents different content to people in the same physical room
> looking at the same LCD is outside of the scope of
> ABFAB:-)
> If we make the context clear--that we're talking about a networked LCD--is
> this example more clear?
> 4.2 p19 last paragraph: i think if you explain GSS-API CB you also need to
> explain EAP CB
> 
> I agree that this document needs  to discuss EAP channel binding. We
> propose to do that in the unwritten section 6.1 as part of the deployment
> discussion.
> I guess we could briefly discuss in section 3 as well.

The discussion may also need to include problems with matching names.  If
you have a TLS DNS name and you have some type of Kerbros realm name - they
may not be the same name but still be the same entity.

> 4.3 p19 "Using host based service...": Why does ABFAB need to adopt this
> approach?
> 
> 
> We need to adopt this approach if we want ABFAB to work with IMAP, SMTP,
> LDAP, SSH, NFS or a variety of other protocols that use this naming
approach.
> We could alternatively update all those specifications and update all the
> implementations that use generic frameworks such as SSPI or Cyrus SASL.
> This is a case where following the existing standards makes deploymentand
> implementation easier.
> Can you suggest additional text for the last paragraph of this section to
better
> clarify?
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

From [email-masked]  Wed Jan 19 15:30:02 2011
From: Sam Hartman <[email-masked]>
To: "Jim Schaad" <[email-masked]>
Date: Wed, 19 Jan 2011 18:32:34 -0500
Cc: [email-masked]
Subject: Re: [abfab] draft-lear-abfab-arch-01 posted

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

We're talking about various SAML exchanges defined to support SOAP over
HTTP.  Basically, when we've been talking about SOAP we're using that as
shorthand for the SAML profiles for an SP talking to an IDP that exist
today.

We're arguing about the balance between our AAA transport and the
existing transport and what should be used when why by whom.

From [email-masked]  Wed Jan 19 16:31:46 2011
From: "Jim Schaad" <[email-masked]>
To: "'Sam Hartman'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Wed, 19 Jan 2011 16:06:01 -0800
Subject: Re: [abfab] Multiple attribute providers in an authentication

Sam 

Comments in line.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Sam Hartman
> Sent: Monday, January 10, 2011 11:18 AM
> To: [email-masked]; [email-masked]
> Subject: [abfab] Multiple attribute providers in an authentication
> 
> 
> Background: there was a discussion between authors of the abfab
> architecture proposal about multiple attribute providers.
> The idea is that you have an identity provider that is producing a set of
> attributes about a subject. In the case of ABFAB we're mostly thinking of
a
> SAML IDP for this particular example.
> 
> The IDP  has some attributes it may be in a position to assert.
> But the IDP may also want to gather attributes from other  sources and
pass
> those along.
> 
> One option it has is to simply pass the attributes along as if it issued
them
> itself.  That option isn't really interesting from a protocol standpoint
because
> it is indistinguishable from the IDP actually issuing the attribute
itself.  That is
> probably a fine thing to do in certain deployments but we don't need to
> spend a lot of time on it.
> 
> Another option is that the IDP can go actually get a SAML assertion (or
> attribute certificate or the like) and include that in what is sent to the
RP.
> 
> At first glance, the protocol implications of doing this look simple. You
just
> stick the assertion in the existing bag of bits and move on.
> 
> however, it's not that simple because of semantics.
> 
> Today in ABFAB, we haven't done a great job of describing what the trust
> semantics of the attribute in draft-ietf-abfab-aaa-saml are. However what
> has been going through at least Josh and my mind is that the RP SHOULD
> assume that the AAA framework provides an integrity protected channel for
> that SAML message. The message is actually issued by the IDP corresponding
> to the NAI used to make the access request. In addition, for the SAML
> assertions sent from the IDP to the RP, the RP SHOULD assume that the IDP
> is asserting those attributes about the subject.

Would you consider it to be permissible for an intermediate to re-write the
assertions to change the framework they are being made in from the IdP's
home network to the federation network's framework?   This would say that
they may not have quite the same degree of integrity protection as might be
initially assumed.  

> That is, the RP need not perform any validation of the SAML assertion. The
> RP still needs to validate whether the IDP is permitted to make the claims
it
> does.
> There's no requirement that these SAML assertions be signed.
> The IDP MAY sign the assertion; the RP MAY consider any signatures that
are
> present. However in the interoperable case, any signatures that are
present
> are ignored.
> 
> If there are multiple assertions from the same IDP it seems reasonable to
> treat them all the same.
> 
> Things get a lot more messy  when assertions from multiple IDPs are
> included.

Are you saying that the principal has multiple names or that they are
multiple assertions being made about a single name?  

> What does it mean to include them in the AAA transport?  I can think of
> several trust models that are appropriate depending on deployment:
> 
> * The IDP corresponding to the subject's NAI has validated these
>   additional assertions and wishes to assert that the attributes can be
>   trusted. "If you trust me then you should trust these." Here, the
>   assertions are being included either for convenience of packaging the
>   attributes into some form the RP can process or because it is possible
>   that the RP may be able to validate some signature and trust the
>   attribute source more than the IDP.
> 
> * The subject IDP has performed SAML validation on the
>   assertions. However the IDP is making no claims about how trusted the
>   attributes included in the additional assertions are. Even if the IDP
>   would be permitted to make a claim made in an additional assertion,
>   the RP needs to make an independent policy decision about whether the
>   actual issuer should be permitted to make that claim.
> 
> * Here are some assertions for the RP's convenience. The IDP makes no
>   claims about them; not even the implied claim that they have not been
>   modified in transit. They better be signed, the RP better have
>   metadata for their issuer, and the RP is more or less on its own.
> 
> Another source of complexity surrounds how an IDP links an assertion to a
> subject. What confidence is the RP asserting that the additional assertion
> describes the same principal as the access-accept message.
> 
> Another potential source of complexity is how does the IDP know what
> information to gather? Does the IDP just know somehow? Does the RP pass
> information back?

What happens if the naming space of the claims is different between the IDP
and the RP?

What happens if the additional attributes need to come from a completely
different fourth realm?  
I.e. my name comes from the country of issue, the RP is a bank and the
attributes need to come from a university?

> 
> How does the RP make the policy decisions it needs to make? How does it
> get metadata that is needed?
> 
> I think this sort of issue will also have impacts for kitten, because
we'll need
> to describe it in the naming extensions interface. It seems like ABFAB is
not
> going to be the only group facing these sorts of discussions; Kerberos is
in the
> middle of a similar discussion right now.

I completely agree this is  a hard problem that we need to start writing
down, if not answers then at least boundaries of the problem.

Jim

> 
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

From [email-masked]  Wed Jan 19 16:32:10 2011
From: "Jim Schaad" <[email-masked]>
To: "'Josh Howlett'" <[email-masked]>, "'Klaas Wierenga'" <[email-masked]>, <[email-masked]>
Date: Wed, 19 Jan 2011 16:52:46 -0800
Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Josh Howlett
> Sent: Tuesday, January 18, 2011 8:21 AM
> To: Klaas Wierenga; [email-masked]
> Cc: Josh Howlett
> Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml
> 
> > > e.g. say we specify the "saml-20-aa" name to mean a SAML 2.0
> > attribute authority. An SP wanting to route a message to this actor to
> > example.com prefixes the realm of the intended Issuer with this, thus
> > "saml-20-aa.example.com". The AAA SAML attribute within this request
> > message contains a SAML Request message containing the identifier for
> > the subject.
> >
> > ehrm, that means there can only be one AA per realm?
> 
> If that matters, I think you could have multiple AAs and disambiguate by
> extending the naming semantics of the NAI.

But the different AAs may be authorative for different statements for the
same individuals.  This does not help.

Jim

> 
> 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 Oxford,
Didcot,
> Oxfordshire. OX11 0SG
> 
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

From [email-masked]  Wed Jan 19 16:32:13 2011
From: "Jim Schaad" <[email-masked]>
To: <[email-masked]>
Date: Wed, 19 Jan 2011 16:52:46 -0800
Subject: [abfab] Comments on draft-lear-abfab-arch-01

Let's see how far I can demonstrate my lack of understanding.  It seems to
me to be a good way to figure out if there are problems with the document.
The mailing list may have addressed some of these issues, I am just now
catching up on it.

Jim

In section 1.1
Current:
Some deployments may be required to deploy message routing intermediaries
Suggested:
Some instantiations may be required to deploy message routing intermediaries

The expansion of NAI needs to be moved forward in the document.

In step 2
A couple of questions come to mind here - which authentication mechanism are
selecting?  The End Host to IdP or the End Host to the Relying Part?
Are there any options here or is there only a single possibility?

In Step 3
For various reasons, I think one will want to establish a secure link to
from the Client Application to the RP either before - or as - it is
supplying the NAI to the RP.
It might however been that you are really only saying that you are sending
the realm portion of the NAI to the RP.  That would be a different story,
but you may still want to get some type of secure link.

Note to self - in step 5 what is the security on the RP claim of identity

In Step 7
You say that it happens between the endpoints - but the endpoints are not
defined in this case.  I believe you actually mean the IdP and the Principal
but there are other endpoints it could be.

In Step 8
I have a complete lack of understanding of the last sentence of this
section.    I don't have any idea of how this statement follows from the
preceding.  I can see it as saying that the IdP will know that the Principal
and it are authenticated to the same RP.

Section 3.1
- in Paragraph 3 - It specifies that we are going to put the NAI in the
GSS_C_NT_USER_NAME field of GSS-API, is it going to be the responsibility of
the GSS-API layer to fragment the realm portion of name from the full NAI
depending on if it is talking to the RP or the IdP?

There is no mention in this section that there may be multiple IdPs for a
single realm that could be used by the RP and the selection of which IdP it
wants to use is going to be based on the set of attributes that the RP needs
or a level of authentication that is required by the RP (see    [sp800-63-1]
NIST SP 800-63-1 "Electronic Authentication Guideline", December 2008 as
examples).

Section 3.2
Has the sentences " Aside from a valuable secret being exposed, a
   synchronization problem can also often develop.  Since there is no
   single authentication mechanism that will be used everywhere there is
   another associated requirement:"
I have a couple of issues here.  First there is a problem which is stated -
i.e. synchronization - but the next sentence does not appear to expand on
the problem but rather deals with a different issue.  I would like to have
the first thought finished before going onto the second one.  I think this
paragraph is supposed to be talking about issues that we have been taught -
but the word Since does not convey this is a separate issue we have dealing
with.

In the sentence "through the   authenticator (i.e., service provider)" -
s/service provider/relying party/

Section 3.5
In this picture - I believe that it would be more accurate to have the EAP
stream go directly through the Federation layer - this would not be routed
as it is E2E.  Also it might make sense to have it wrap through the Server
Side box.

Section 4.3
Given that you have stated that we are going to use the Kerberos realm
naming, on which I have no opinion, I think that there should be some text
about how the end host is going to make a decision that it is talking to the
correct RP to begin with.  It does not have any pre-existing security
relationship with the realm of the RP.

Additional Issues:

1.  The document is currently written in terms of dealing with an Identity
provider, and I can understand why that is so as without an identity not
much will happen.  However it seems to me that there is also a desire to be
able to talk to an attribute service in much the same way.  However it is
not clear that there is a need for the End Host to talk to the attribute
provider - that communication should be thought of as passing between the
IdP, the RP and the AtP.  The IdP may need to get a different or better
identity proof as part of that conversation.

2.  I am not sure if there needs to be a discussion on what needs to be a
part of a federation agreement.  One of the issues that I can see as being
troublesome as it does not seem to be vastly expandable is the question of
what makes for an equivalent statement.  Is it to be expected that the SASL
statements are going to be made in terms of the federation agreement
attributes, or does there need to be available to the RP some type of
mapping statement?

From [email-masked]  Wed Jan 19 17:15:35 2011
From: Sam Hartman <[email-masked]>
To: "Jim Schaad" <[email-masked]>
Date: Wed, 19 Jan 2011 20:18:07 -0500
Cc: [email-masked], [email-masked]
Subject: Re: [abfab] Multiple attribute providers in an authentication

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

    Jim> Would you consider it to be permissible for an intermediate to
    Jim> re-write the assertions to change the framework they are being
    Jim> made in from the IdP's home network to the federation network's
    Jim> framework?  This would say that they may not have quite the
    Jim> same degree of integrity protection as might be initially
    Jim> assumed.

AAA integrity is hop-by-hop.
I don't think we'll have technical mechanisms in some deployments to
prevent this.
In some cases (draft-howlett-radsec-kmp springs to mind) it might be
fairly tricky to do that.
I don't think we've discussed the role of intermediates much.
I can think of several models including:

* Intermediates are good and need to be permitted to muck about.
* When intermediates can muck about it's OK for them to do so.
* Intermediates must not muck about; future deployment and other
 mechanisms may restrict their ability to do so more than is restricted
 today.

We have not discussed  a lot what the answer is.

In some of the work Josh and I did we ran into a number of cases where
having the intermediates be able to examine the information passing
through has been quite valuable.
(We typically found that out when we designed a mechanism to
short-circuit some intermediate and then ended up adding a lot of
complexity to get the intermediate some information.)

Similarly in discussions at the Kerberos Consortium conference this
fall, several people believed that having an organizational policy
intermediate near the RP would be valuable. (In that community they
believed a KDC would be a great place to put such an intermediate.)

    >> That is, the RP need not perform any validation of the SAML
    >> assertion. The RP still needs to validate whether the IDP is
    >> permitted to make the claims
    Jim> it
    >> does.  There's no requirement that these SAML assertions be
    >> signed.  The IDP MAY sign the assertion; the RP MAY consider any
    >> signatures that
    Jim> are
    >> present. However in the interoperable case, any signatures that
    >> are
    Jim> present
    >> are ignored.
    >> 
    >> If there are multiple assertions from the same IDP it seems
    >> reasonable to treat them all the same.
    >> 
    >> Things get a lot more messy when assertions from multiple IDPs
    >> are included.

    Jim> Are you saying that the principal has multiple names or that
    Jim> they are multiple assertions being made about a single name?

Both.
I'm assuming all the assertions are about the same subject/principal,
but that entity may be known by multiple names.
Someone needs to actually make sure that all the assertions are about
the same subject.
That is quite tricky.

    >> Another source of complexity surrounds how an IDP links an
    >> assertion to a subject. What confidence is the RP asserting that
    >> the additional assertion describes the same principal as the
    >> access-accept message.
    >> 
    >> Another potential source of complexity is how does the IDP know
    >> what information to gather? Does the IDP just know somehow? Does
    >> the RP pass information back?

    Jim> What happens if the naming space of the claims is different
    Jim> between the IDP and the RP?

To the extent that problem exists, I think it is independent of whether
multiple attribute provders or one attribute provider is involved.  I
think we're defining the use of NAIs as a way to have a common name
space between the RP and the first IDP.
That is, the AAA federation substrate for abfab needs to provide some
naming services to guarantee that we have a common namespace between the
RP and IDP.

    Jim> What happens if the additional attributes need to come from a
    Jim> completely different fourth realm?  I.e. my name comes from the
    Jim> country of issue, the RP is a bank and the attributes need to
    Jim> come from a university?

*this* is the first point I was getting at in the paragraph from my
 original message.
I consider this situation complicated.
    Jim> I completely agree this is a hard problem that we need to start
    Jim> writing down, if not answers then at least boundaries of the
    Jim> problem.

Yes.  I and as I understand it Moonshot don't need to solve this problem
to make forward progress.  I think building some walls around the
problem and starting to understand where it is is valuable.  However
until someone steps forward and wants to spend (or fund) significant
cycles on this, I don't think we will solve it.

From [email-masked]  Wed Jan 19 17:16:50 2011
From: Sam Hartman <[email-masked]>
To: "Jim Schaad" <[email-masked]>
Date: Wed, 19 Jan 2011 20:19:25 -0500
Cc: 'Josh Howlett' <[email-masked]>, [email-masked]
Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml

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

    >> -----Original Message----- From: [email-masked]
    >> [mailto:[email-masked]] On Behalf Of Josh Howlett Sent:
    >> Tuesday, January 18, 2011 8:21 AM To: Klaas Wierenga;
    >> [email-masked] Cc: Josh Howlett Subject: Re: [abfab] Proposed
    >> changes to draft-ieft-abfab-aaa-saml
    >> 
    >> > > e.g. say we specify the "saml-20-aa" name to mean a SAML 2.0
    >> > attribute authority. An SP wanting to route a message to this
    >> actor to > example.com prefixes the realm of the intended Issuer
    >> with this, thus > "saml-20-aa.example.com". The AAA SAML
    >> attribute within this request > message contains a SAML Request
    >> message containing the identifier for > the subject.
    >> >
    >> > ehrm, that means there can only be one AA per realm?
    >> 
    >> If that matters, I think you could have multiple AAs and
    >> disambiguate by extending the naming semantics of the NAI.

    Jim> But the different AAs may be authorative for different
    Jim> statements for the same individuals.  This does not help.

I think Josh was proposing ways of naming AAs.

Why does that not help?

From [email-masked]  Wed Jan 19 17:31:27 2011
From: Sam Hartman <[email-masked]>
To: "Jim Schaad" <[email-masked]>
Date: Wed, 19 Jan 2011 20:34:00 -0500
Cc: [email-masked]
Subject: Re: [abfab] Comments on draft-lear-abfab-arch-01

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

    Jim> In step 2 A couple of questions come to mind here - which
    Jim> authentication mechanism are selecting?  The End Host to IdP or
    Jim> the End Host to the Relying Part?  Are there any options here
    Jim> or is there only a single possibility?

There is no authentication of the end-host to the RP.
The end-host authenticates to the IDP.
There is a key confirmation step where the end-host and RP prove they
have the same session key.
In some sense, that performs an authentication function; it definitely
binds the RP->IDP authentication with the end-host->IDP authentication.

    Jim> In Step 3 For various reasons, I think one will want to
    Jim> establish a secure link to from the Client Application to the
    Jim> RP either before - or as - it is supplying the NAI to the RP.
    Jim> It might however been that you are really only saying that you
    Jim> are sending the realm portion of the NAI to the RP.  That would
    Jim> be a different story, but you may still want to get some type
    Jim> of secure link.

You're typically only sending the realm portion if your EAP method uses
privacy identifiers (the good ones do).

A secure link to the RP at this stage is out of scope for a GSS
substrate for abfab in my opinion.
It adds a lot of mess, and there are better ways of doing most of what
you are probably trying to do.

Also, note that since the end-host has no credential for the RP, and
this is a huge feature of the architecture, your options are limited.

    Jim> Section 3.1 - in Paragraph 3 - It specifies that we are going
    Jim> to put the NAI in the GSS_C_NT_USER_NAME field of GSS-API, is
    Jim> it going to be the responsibility of the GSS-API layer to
    Jim> fragment the realm portion of name from the full NAI depending
    Jim> on if it is talking to the RP or the IdP?

Um.
I think you're a bit confused about what role GSS-API fills here.
The NAI is an input to the GSS-API, which locally on the end-host feeds
it to a specific EAP method.
That method will hide it if that method hides identity.

    Jim> There is no mention in this section that there may be multiple
    Jim> IdPs for a single realm that could be used by the RP and the
    Jim> selection of which IdP it wants to use is going to be based on
    Jim> the set of attributes that the RP needs or a level of
    Jim> authentication that is required by the RP (see [sp800-63-1]
    Jim> NIST SP 800-63-1 "Electronic Authentication Guideline",
    Jim> December 2008 as examples).

True, basically because there's no existing protocol mechanism to
accomplish the end-host finding out what the RP wants.
This is kind of a GSS failing; there is some Microsoft work that could
expand GSS in some ways.
Abfab can take advantage of this whenever GSS gains the feature.

I think I have an action item to discuss federation and IDP selection
(although someone else may have the action item for IDP selection--can't
remember).  However it's more going to be about future extensions and
directions for expansion.

    Jim> Section 3.2 Has the sentences " Aside from a valuable secret
    Jim> being exposed, a synchronization problem can also often
    Jim> develop.  Since there is no single authentication mechanism
    Jim> that will be used everywhere there is another associated
    Jim> requirement:" I have a couple of issues here.  First there is a
    Jim> problem which is stated - i.e. synchronization - but the next
    Jim> sentence does not appear to expand on the problem but rather
    Jim> deals with a different issue.  I would like to have the first
    Jim> thought finished before going onto the second one.  I think
    Jim> this paragraph is supposed to be talking about issues that we
    Jim> have been taught - but the word Since does not convey this is a
    Jim> separate issue we have dealing with.

Help with wording would be greatly appreciated here.

    Jim> In the sentence "through the authenticator (i.e., service
    Jim> provider)" - s/service provider/relying party/

    Jim> Section 3.5 In this picture - I believe that it would be more
    Jim> accurate to have the EAP stream go directly through the
    Jim> Federation layer - this would not be routed as it is E2E.  

No, I think the EAP stream is routed.

Just as TLS is routed over IP.

    Jim> Section 4.3 Given that you have stated that we are going to use
    Jim> the Kerberos realm naming, on which I have no opinion, I think
    Jim> that there should be some text about how the end host is going
    Jim> to make a decision that it is talking to the correct RP to
    Jim> begin with.  It does not have any pre-existing security
    Jim> relationship with the realm of the RP.

It kind of needs to trust the RP for some of this.
It needs to derive a name for the RP from input it gets from the user
or a trusted referral.
Then, the IDP and some proxy goo is responsible for making sure that the
RP it is talking to is the RP it names.

    Jim> Additional Issues:

    Jim> 1.  The document is currently written in terms of dealing with
    Jim> an Identity provider, and I can understand why that is so as
    Jim> without an identity not much will happen.  However it seems to
    Jim> me that there is also a desire to be able to talk to an
    Jim> attribute service in much the same way.  However it is not
    Jim> clear that there is a need for the End Host to talk to the
    Jim> attribute provider - that communication should be thought of as
    Jim> passing between the IdP, the RP and the AtP.  The IdP may need
    Jim> to get a different or better identity proof as part of that
    Jim> conversation.

Hmm.

    Jim> 2.  I am not sure if there needs to be a discussion on what
    Jim> needs to be a part of a federation agreement.  One of the
    Jim> issues that I can see as being troublesome as it does not seem
    Jim> to be vastly expandable is the question of what makes for an
    Jim> equivalent statement.  Is it to be expected that the SASL
    Jim> statements are going to be made in terms of the federation
    Jim> agreement attributes, or does there need to be available to the
    Jim> RP some type of mapping statement?

I hope we can avoid discussions of what goes in a federation agreement.

From [email-masked]  Wed Jan 19 17:32:10 2011
From: "Jim Schaad" <[email-masked]>
To: "'Sam Hartman'" <[email-masked]>
Date: Wed, 19 Jan 2011 17:53:11 -0800
Cc: [email-masked]
Subject: Re: [abfab] draft-lear-abfab-arch-01 posted

> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]]
> Sent: Wednesday, January 19, 2011 3:33 PM
> To: Jim Schaad
> Cc: 'Klaas Wierenga'; [email-masked]
> Subject: Re: [abfab] draft-lear-abfab-arch-01 posted
> 
> >>>>> "Jim" == Jim Schaad <[email-masked]> writes:
> 
> We're talking about various SAML exchanges defined to support SOAP over
> HTTP.  Basically, when we've been talking about SOAP we're using that as
> shorthand for the SAML profiles for an SP talking to an IDP that exist
today.
> 
> We're arguing about the balance between our AAA transport and the
> existing transport and what should be used when why by whom.

I agree that SOAP over HTTP is the most common, but it is not the only
binding that exists.  It would be potentially useful for me to be able to
send SOAP messages over DIAMETER at some point in the future.  So for me the
distinction between the message format and the transport is a useful
distinction.

Jim

From [email-masked]  Wed Jan 19 17:34:15 2011
From: Sam Hartman <[email-masked]>
To: "Jim Schaad" <[email-masked]>
Date: Wed, 19 Jan 2011 20:36:50 -0500
Cc: [email-masked]
Subject: Re: [abfab] draft-lear-abfab-arch-01 posted

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

    >> -----Original Message----- From: Sam Hartman
    >> [mailto:[email-masked]] Sent: Wednesday, January
    >> 19, 2011 3:33 PM To: Jim Schaad Cc: 'Klaas Wierenga';
    >> [email-masked] Subject: Re: [abfab] draft-lear-abfab-arch-01
    >> posted
    >> 
    >> >>>>> "Jim" == Jim Schaad <[email-masked]> writes:
    >> 
    >> We're talking about various SAML exchanges defined to support
    >> SOAP over HTTP.  Basically, when we've been talking about SOAP
    >> we're using that as shorthand for the SAML profiles for an SP
    >> talking to an IDP that exist
    Jim> today.
    >> 
    >> We're arguing about the balance between our AAA transport and the
    >> existing transport and what should be used when why by whom.

    Jim> I agree that SOAP over HTTP is the most common, but it is not
    Jim> the only binding that exists.  It would be potentially useful
    Jim> for me to be able to send SOAP messages over DIAMETER at some
    Jim> point in the future.  So for me the distinction between the
    Jim> message format and the transport is a useful distinction.

I'm not aware of a SAML binding for SOAP over diameter.
As far as ABFAB is concerned the real question is whether ABFAB is
defining the transport or whether you are using an existing SAML
binding.

--Sam

From [email-masked]  Wed Jan 19 17:57:50 2011
From: "Jim Schaad" <[email-masked]>
To: "'Sam Hartman'" <[email-masked]>
Date: Wed, 19 Jan 2011 18:18:42 -0800
Cc: 'Josh Howlett' <[email-masked]>, [email-masked]
Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml

> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]]
> Sent: Wednesday, January 19, 2011 5:19 PM
> To: Jim Schaad
> Cc: 'Josh Howlett'; 'Klaas Wierenga'; [email-masked]
> Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml
> 
> >>>>> "Jim" == Jim Schaad <[email-masked]> writes:
> 
>     >> -----Original Message----- From: [email-masked]
>     >> [mailto:[email-masked]] On Behalf Of Josh Howlett Sent:
>     >> Tuesday, January 18, 2011 8:21 AM To: Klaas Wierenga;
>     >> [email-masked] Cc: Josh Howlett Subject: Re: [abfab] Proposed
>     >> changes to draft-ieft-abfab-aaa-saml
>     >>
>     >> > > e.g. say we specify the "saml-20-aa" name to mean a SAML 2.0
>     >> > attribute authority. An SP wanting to route a message to this
>     >> actor to > example.com prefixes the realm of the intended Issuer
>     >> with this, thus > "saml-20-aa.example.com". The AAA SAML
>     >> attribute within this request > message contains a SAML Request
>     >> message containing the identifier for > the subject.
>     >> >
>     >> > ehrm, that means there can only be one AA per realm?
>     >>
>     >> If that matters, I think you could have multiple AAs and
>     >> disambiguate by extending the naming semantics of the NAI.
> 
>     Jim> But the different AAs may be authorative for different
>     Jim> statements for the same individuals.  This does not help.
> 
> I think Josh was proposing ways of naming AAs.
> 
> Why does that not help?

I thought that he was given an example of  uniform name of an attribute
authority, as  oppose to suggesting that there might be different names.
But that also implies that you need to be able to query as to which of the
different authorities you need to query in order to get the attributes you
care about.  Even more issues of attribute name and quality matching to be
dealt with.

Jim

From [email-masked]  Thu Jan 20 01:59:42 2011
From: Josh Howlett <[email-masked]>
To: Jim Schaad <[email-masked]>, 'Sam Hartman' <[email-masked]>
Date: Thu, 20 Jan 2011 10:02:32 +0000
Accept-Language: en-GB, en-US
Cc: Josh Howlett <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] draft-lear-abfab-arch-01 posted

> > We're arguing about the balance between our AAA transport and the
> > existing transport and what should be used when why by whom.
>=20
> I agree that SOAP over HTTP is the most common, but it is not the only
> binding that exists.  It would be potentially useful for me to be able
> to send SOAP messages over DIAMETER at some point in the future.  So for
> me the distinction between the message format and the transport is a usef=
ul
> distinction.

Jim, I don't believe that Abfab itself requires SOAP messaging. But what's =
your use-case?

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 Oxford, Didcot, Oxfordshire. OX11 0SG

From [email-masked]  Thu Jan 20 02:12:43 2011
From: Josh Howlett <[email-masked]>
To: Jim Schaad <[email-masked]>, 'Sam Hartman' <[email-masked]>
Date: Thu, 20 Jan 2011 10:15:36 +0000
Accept-Language: en-GB, en-US
Cc: Josh Howlett <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] Proposed changes to draft-ieft-abfab-aaa-saml

> I thought that he was given an example of  uniform name of an attribute
> authority, as  oppose to suggesting that there might be different
> names.
> But that also implies that you need to be able to query as to which of
> the different authorities you need to query in order to get the attributes
> you care about.  Even more issues of attribute name and quality matching =
to
> be dealt with.

Yes, but I don't think that this is any different in Abfab from the multipl=
e AA case with contemporary technologies; and today this is generally consi=
dered a deployment issue. So I think we can choose to either apply the same=
 deployment strategies used today, or define a standard way of doing it.

I'm personally fairly agnostic about this, although I get a sense from the =
list and private communications that there is interest in defining a standa=
rd approach for this.

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 Oxford, Didcot, Oxfordshire. OX11 0SG

From [email-masked]  Thu Jan 20 08:14:26 2011
From: "Jim Schaad" <[email-masked]>
To: "'Sam Hartman'" <[email-masked]>
Date: Thu, 20 Jan 2011 08:35:31 -0800
Cc: [email-masked]
Subject: Re: [abfab] Comments on draft-lear-abfab-arch-01

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Sam Hartman
> Sent: Wednesday, January 19, 2011 5:34 PM
> To: Jim Schaad
> Cc: [email-masked]
> Subject: Re: [abfab] Comments on draft-lear-abfab-arch-01
> 
> >>>>> "Jim" == Jim Schaad <[email-masked]> writes:
> 
>     Jim> In step 2 A couple of questions come to mind here - which
>     Jim> authentication mechanism are selecting?  The End Host to IdP or
>     Jim> the End Host to the Relying Part?  Are there any options here
>     Jim> or is there only a single possibility?
> 
> There is no authentication of the end-host to the RP.
> The end-host authenticates to the IDP.
> There is a key confirmation step where the end-host and RP prove they have
> the same session key.
> In some sense, that performs an authentication function; it definitely
binds
> the RP->IDP authentication with the end-host->IDP authentication.

I was expecting to see some degree of authentication of the RP to the
end-host before the process started.   If this is not the case then all of
the name matching logic is going to occur in the IDP and none of it in the
end-host which has the best guess as to who it thinks it should be talking
to.

Are you referring to a step where the end-host and RP prove they have the
same session key to each other, or are they trying to prove this to a third
party?  I can figure out that the first occurs but not the second.
Currently the only check that is performed is that the name is the same.  If
we are clobbering the name with the key, then it is vital that the end-host
and the RP agree on the name form of the RP before they are clobbered and
given to the IDP.

You did not address the question of a single possibility - the current text
says it is a selection step, but if the selection is done by the
specification then this is not really a selection that is part of the
exchange.

> 
>     Jim> In Step 3 For various reasons, I think one will want to
>     Jim> establish a secure link to from the Client Application to the
>     Jim> RP either before - or as - it is supplying the NAI to the RP.
>     Jim> It might however been that you are really only saying that you
>     Jim> are sending the realm portion of the NAI to the RP.  That would
>     Jim> be a different story, but you may still want to get some type
>     Jim> of secure link.
> 
> You're typically only sending the realm portion if your EAP method uses
> privacy identifiers (the good ones do).
> 
> A secure link to the RP at this stage is out of scope for a GSS substrate
for
> abfab in my opinion.
> It adds a lot of mess, and there are better ways of doing most of what you
> are probably trying to do.
> 
> Also, note that since the end-host has no credential for the RP, and this
is a
> huge feature of the architecture, your options are limited.

So we are not even planning to say that we are going to be using TLS here.
However it would still be possible to do some type of leap-of-faith
credential here where we can get a secure link - which I think you are
really planning to do since you talked about comparing the keys using the
IDP as an arbiter.

> 
>     Jim> Section 3.1 - in Paragraph 3 - It specifies that we are going
>     Jim> to put the NAI in the GSS_C_NT_USER_NAME field of GSS-API, is
>     Jim> it going to be the responsibility of the GSS-API layer to
>     Jim> fragment the realm portion of name from the full NAI depending
>     Jim> on if it is talking to the RP or the IdP?
> 
> Um.
> I think you're a bit confused about what role GSS-API fills here.
> The NAI is an input to the GSS-API, which locally on the end-host feeds it
to a
> specific EAP method.
> That method will hide it if that method hides identity.

Ok - then I am confused.  Are we talking about having a single GSS-API
method which is going to coordinate both of the secure links we are looking
at, or are there going to be two different GSS-API methods, or is the
end-host to RP link not going to be covered by GSS-API?  My assumption was
the first  - that is a single GSS-API method was going to have to do the
secure link from the end-host to the RP as well as the EAP conversation to
the IDP.  In this case the question does make sense as the name being sent
over EAP is different than that being sent to the RP, but both are coming
out a single common GSS-API method

> 
>     Jim> There is no mention in this section that there may be multiple
>     Jim> IdPs for a single realm that could be used by the RP and the
>     Jim> selection of which IdP it wants to use is going to be based on
>     Jim> the set of attributes that the RP needs or a level of
>     Jim> authentication that is required by the RP (see [sp800-63-1]
>     Jim> NIST SP 800-63-1 "Electronic Authentication Guideline",
>     Jim> December 2008 as examples).
> 
> True, basically because there's no existing protocol mechanism to
accomplish
> the end-host finding out what the RP wants.
> This is kind of a GSS failing; there is some Microsoft work that could
expand
> GSS in some ways.
> Abfab can take advantage of this whenever GSS gains the feature.
> 
> I think I have an action item to discuss federation and IDP selection
(although
> someone else may have the action item for IDP selection--can't remember).
> However it's more going to be about future extensions and directions for
> expansion.

It's a hard problem - as long as that is discussed we can probably punt for
now.

> 
> 
>     Jim> Section 3.2 Has the sentences " Aside from a valuable secret
>     Jim> being exposed, a synchronization problem can also often
>     Jim> develop.  Since there is no single authentication mechanism
>     Jim> that will be used everywhere there is another associated
>     Jim> requirement:" I have a couple of issues here.  First there is a
>     Jim> problem which is stated - i.e. synchronization - but the next
>     Jim> sentence does not appear to expand on the problem but rather
>     Jim> deals with a different issue.  I would like to have the first
>     Jim> thought finished before going onto the second one.  I think
>     Jim> this paragraph is supposed to be talking about issues that we
>     Jim> have been taught - but the word Since does not convey this is a
>     Jim> separate issue we have dealing with.
> 
> Help with wording would be greatly appreciated here.

Not a problem - Elliot - what did you mean by a synchronization problem?  

> 
>     Jim> In the sentence "through the authenticator (i.e., service
>     Jim> provider)" - s/service provider/relying party/
> 
>     Jim> Section 3.5 In this picture - I believe that it would be more
>     Jim> accurate to have the EAP stream go directly through the
>     Jim> Federation layer - this would not be routed as it is E2E.
> 
> No, I think the EAP stream is routed.
> 
> Just as TLS is routed over IP.
> 

While TLS is routed over IP - I generally think of it as being  channel and
thus direct between the two parties.  I ignore the routing that is being
done by the IP layer as it does not affect the data being transported.  This
is not the same as with the RADIUS/DIAMETER stream where the routing layer
can change the contents of the message as it travels through the federation
layer.  Thus I think that representing the data flows differently in the
picture makes sense.

> 
>     Jim> Section 4.3 Given that you have stated that we are going to use
>     Jim> the Kerberos realm naming, on which I have no opinion, I think
>     Jim> that there should be some text about how the end host is going
>     Jim> to make a decision that it is talking to the correct RP to
>     Jim> begin with.  It does not have any pre-existing security
>     Jim> relationship with the realm of the RP.
> 
> It kind of needs to trust the RP for some of this.
> It needs to derive a name for the RP from input it gets from the user or a
> trusted referral.
> Then, the IDP and some proxy goo is responsible for making sure that the
RP
> it is talking to is the RP it names.

But there is a difference between relying on just the IDP to do the name
matching, and the end-host doing the name matching and then sending the name
that it gets from the RP to send to the IDP for the final name matching
check.  I am worried about the question of trying to go from a DNS name to a
NAI name at this point. 

> 
>     Jim> Additional Issues:
> 
>     Jim> 1.  The document is currently written in terms of dealing with
>     Jim> an Identity provider, and I can understand why that is so as
>     Jim> without an identity not much will happen.  However it seems to
>     Jim> me that there is also a desire to be able to talk to an
>     Jim> attribute service in much the same way.  However it is not
>     Jim> clear that there is a need for the End Host to talk to the
>     Jim> attribute provider - that communication should be thought of as
>     Jim> passing between the IdP, the RP and the AtP.  The IdP may need
>     Jim> to get a different or better identity proof as part of that
>     Jim> conversation.
> 
> Hmm.
> 
>     Jim> 2.  I am not sure if there needs to be a discussion on what
>     Jim> needs to be a part of a federation agreement.  One of the
>     Jim> issues that I can see as being troublesome as it does not seem
>     Jim> to be vastly expandable is the question of what makes for an
>     Jim> equivalent statement.  Is it to be expected that the SASL
>     Jim> statements are going to be made in terms of the federation
>     Jim> agreement attributes, or does there need to be available to the
>     Jim> RP some type of mapping statement?
> 
> I hope we can avoid discussions of what goes in a federation agreement.

I can understand this, however I think that there needs to be some high
level discussion of questions like how mapping of statements should be done.

Jim

> 
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

From [email-masked]  Thu Jan 20 13:30:18 2011
From: Sam Hartman <[email-masked]>
To: [email-masked]
Date: Thu, 20 Jan 2011 16:32:46 -0500
Subject: [abfab] draft-ietf-abfab-gss-eap-naming: how to name vendor-specific attributes

We want to be able to name AAA attributes. The reason is that we want
GSS applications to be able to request these attributes from the gss
library so they can get authorization information returned from the AAA
server.

That's relatively easy for standardized attributes.

What do we do about vendor specific attributes (VSAs)?

At the Moonshot meeting last September, people were assuming that VSAs
were uniform in format.  That's not true.  There is a suggested format
in the RADIUS spec (I have not looked at Diameter).  However it's not
used by everything.

So, how do we want to name these attributes?  I guess one option is to
define attribute names for the recommended VSA format and later if there
are VSA formats that are used in abfab, we can describe how they are
handled.

One robustness concern is this means that a GSS implementation needs to
parse each VSA and be robust even if it is mall-formed under the
standard format.  Another implication is that an attribute may end up
generating incorrect names because it happens to parse under the
recommended format even when that is not the actual format.

From [email-masked]  Fri Jan 21 01:10:16 2011
Date: Fri, 21 Jan 2011 10:13:22 +0100
From: =?ISO-8859-1?Q?Gabriel_L=F3pez?= <[email-masked]>
To: [email-masked]
Subject: Re: [abfab] draft-lear-abfab-arch-01 posted

El 20/01/11 00:36, Jim Schaad escribi�:
>
> I am in favor of having some diagrams really early in the processes.  I
> think this really helps to get understanding setup early.  But I tend to be
> a very pictorial person.
>
     I agree with Jim here, flow diagrams will help to understand the 
architecture and to detect missing problems.

     some other comments:

     - pag. 6. - 5. [... ]At this stage, the RP will likely have no idea 
who the principal
         is.

     You propose here to optionally send a SAML Attribute Query to the 
idP/AA, but this query has to include the user's subject. How does it 
match with the previous sentence?

     You could also here request a SAML AuthnStatement that could be use 
latter to request attributes by SOAP channels (if you decide to consider 
this scenario)

     - pag. 6 - 6. IdP informs the principal of which EAP method to use 
[...]

     In this case the RADIUS server plays the role of idP, but what 
happens if the organization already have a running idP (i.e. Shibboleth)?

     - pag. 7 - 9. What kind of checks is done here? could you provide 
an example? I mean.
                 Are you checking if idP could issue an attribute 
statement including user's attributes for SP?
                 An Attribute Release Policy?

      - pag. 12. if you decide to apply abfab arch over eduroam you 
could make use of trust-anchor and PKI services (eduGAIN) to assert 
trust between organizations, but this option is not described in the draft.

     - pag. 19. The text: "Host-based service names do not work ideally 
when different instances
    of a service are running on different ports.  Also, these do not work
    ideally when SRV record or other insecure referrals are used." is 
not in-line with the rest of the section.

     Best regards, Gabi.

-- 
----------------------------------------------------------------
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]  Fri Jan 21 01:51:02 2011
Date: Fri, 21 Jan 2011 10:53:44 +0100
From: Eliot Lear <[email-masked]>
To: =?UTF-8?B?R2FicmllbCBMw7NwZXo=?= <[email-masked]>
Cc: [email-masked]
Subject: Re: [abfab] draft-lear-abfab-arch-01 posted

Hi Gabriel,

Thank you for your comments.  First, everyone please remember that this
draft is absolutely a work in progress and meant to reflect what we are
in fact standardizing, as well as indicate what we are not.  Perhaps it
also serves as an excellent way to focus us on what we may need to
standardize but have not yet agreed to do so.

As to your comments:

On 1/21/11 10:13 AM, Gabriel López wrote:
> El 20/01/11 00:36, Jim Schaad escribió:
>>
>> I am in favor of having some diagrams really early in the processes.  I
>> think this really helps to get understanding setup early.  But I tend
>> to be
>> a very pictorial person.
>>
>     I agree with Jim here, flow diagrams will help to understand the
> architecture and to detect missing problems.

I agree, but I'm not sure that was what Jim was actually saying.  Jim,
were you asking for additional pictoral-non-flow-based diagrams?   If
so, what would you find useful?
>
>
>     some other comments:
>
>     - pag. 6. - 5. [... ]At this stage, the RP will likely have no
> idea who the principal
>         is.
>
>     You propose here to optionally send a SAML Attribute Query to the
> idP/AA, but this query has to include the user's subject. How does it
> match with the previous sentence?
At that point we are not yet ready to issue a SAML Attribute Query. 
That should happen in Step 10.  As you can see there is some XXX in
there that needs to be completed.
>
>     You could also here request a SAML AuthnStatement that could be
> use latter to request attributes by SOAP channels (if you decide to
> consider this scenario)
>
>     - pag. 6 - 6. IdP informs the principal of which EAP method to use
> [...]
>
>     In this case the RADIUS server plays the role of idP, but what
> happens if the organization already have a running idP (i.e. Shibboleth)?

They get to run some additional code.  Not sure how we get around that.

>
>     - pag. 7 - 9. What kind of checks is done here? could you provide
> an example? I mean.
>                 Are you checking if idP could issue an attribute
> statement including user's attributes for SP?
>                 An Attribute Release Policy?

That is view of what Step 9 is all about.  What would follow Step 9
(latter part of Step 10) would be a SAML assertion.  Step 10 probably
needs to be broken down.

>
>      - pag. 12. if you decide to apply abfab arch over eduroam you
> could make use of trust-anchor and PKI services (eduGAIN) to assert
> trust between organizations, but this option is not described in the
> draft.

Thus far we have not ventured into PKI at all in the draft.

>
>     - pag. 19. The text: "Host-based service names do not work ideally
> when different instances
>    of a service are running on different ports.  Also, these do not work
>    ideally when SRV record or other insecure referrals are used." is
> not in-line with the rest of the section.

Again, thanks for your comments!

From [email-masked]  Fri Jan 21 01:55:37 2011
From: Josh Howlett <[email-masked]>
To: Sam Hartman <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 21 Jan 2011 09:58:38 +0000
Accept-Language: en-GB, en-US
Cc: Josh Howlett <[email-masked]>
Subject: Re: [abfab] draft-ietf-abfab-gss-eap-naming: how to name	vendor-specific attributes

> So, how do we want to name these attributes?  I guess one option is to
> define attribute names for the recommended VSA format and later if
> there
> are VSA formats that are used in abfab, we can describe how they are
> handled.

Seems like a reasonable approach. Is this something we might want to bring =
to the attention of RADEXT?

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 Oxford, Didcot, Oxfordshire. OX11 0SG

From [email-masked]  Fri Jan 21 02:19:36 2011
Date: Fri, 21 Jan 2011 11:22:12 +0100
From: =?UTF-8?B?R2FicmllbCBMw7NwZXo=?= <[email-masked]>
To: [email-masked]
Subject: Re: [abfab] draft-lear-abfab-arch-01 posted

El 21/01/11 10:53, Eliot Lear escribió:
> Hi Gabriel,
>
> Thank you for your comments.  First, everyone please remember that this
> draft is absolutely a work in progress and meant to reflect what we are
> in fact standardizing, as well as indicate what we are not.  Perhaps it
> also serves as an excellent way to focus us on what we may need to
> standardize but have not yet agreed to do so.
>
> As to your comments:
>
> On 1/21/11 10:13 AM, Gabriel López wrote:
>> El 20/01/11 00:36, Jim Schaad escribió:
>>> I am in favor of having some diagrams really early in the processes.  I
>>> think this really helps to get understanding setup early.  But I tend
>>> to be
>>> a very pictorial person.
>>>
>>      I agree with Jim here, flow diagrams will help to understand the
>> architecture and to detect missing problems.
> I agree, but I'm not sure that was what Jim was actually saying.  Jim,
> were you asking for additional pictoral-non-flow-based diagrams?   If
> so, what would you find useful?
>>
>>      some other comments:
>>
>>      - pag. 6. - 5. [... ]At this stage, the RP will likely have no
>> idea who the principal
>>          is.
>>
>>      You propose here to optionally send a SAML Attribute Query to the
>> idP/AA, but this query has to include the user's subject. How does it
>> match with the previous sentence?
> At that point we are not yet ready to issue a SAML Attribute Query.
> That should happen in Step 10.  As you can see there is some XXX in
> there that needs to be completed.
so, the idp returns SAML attributes without a SAML attribute query or 
the RP, in a latter second round-trip sends the SAML attribute query to 
the idP over RADIUS.
That's one of the issues the diagrams should clarify :)

>>      You could also here request a SAML AuthnStatement that could be
>> use latter to request attributes by SOAP channels (if you decide to
>> consider this scenario)
>>
>>      - pag. 6 - 6. IdP informs the principal of which EAP method to use
>> [...]
>>
>>      In this case the RADIUS server plays the role of idP, but what
>> happens if the organization already have a running idP (i.e. Shibboleth)?
> They get to run some additional code.  Not sure how we get around that.
>
and the trust based on the AAA infrastructure could not be enough.

thanks for the answer.

regards, Gabi.
>>      - pag. 7 - 9. What kind of checks is done here? could you provide
>> an example? I mean.
>>                  Are you checking if idP could issue an attribute
>> statement including user's attributes for SP?
>>                  An Attribute Release Policy?
> That is view of what Step 9 is all about.  What would follow Step 9
> (latter part of Step 10) would be a SAML assertion.  Step 10 probably
> needs to be broken down.
>>       - pag. 12. if you decide to apply abfab arch over eduroam you
>> could make use of trust-anchor and PKI services (eduGAIN) to assert
>> trust between organizations, but this option is not described in the
>> draft.
> Thus far we have not ventured into PKI at all in the draft.
>
>>      - pag. 19. The text: "Host-based service names do not work ideally
>> when different instances
>>     of a service are running on different ports.  Also, these do not work
>>     ideally when SRV record or other insecure referrals are used." is
>> not in-line with the rest of the section.
> Again, thanks for your comments!
>

-- 
----------------------------------------------------------------
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]  Fri Jan 21 04:19:00 2011
From: Sam Hartman <[email-masked]>
To: Gabriel =?iso-8859-1?Q?L=F3pez?= <[email-masked]>
Date: Fri, 21 Jan 2011 07:21:32 -0500
Cc: [email-masked]
Subject: Re: [abfab] draft-lear-abfab-arch-01 posted

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

    Gabriel>     - pag. 6 - 6. IdP informs the principal of which EAP
    Gabriel> method to use [...]

    Gabriel>     In this case the RADIUS server plays the role of idP,
    Gabriel> but what happens if the organization already have a running
    Gabriel> idP (i.e. Shibboleth)?

We're viewing the AAA server, SAML IDP and EAP server all as one big box
we've been calling IDP.  They may be realized as separate entities.  The
division of labor is a local matter.

From [email-masked]  Fri Jan 21 04:27:41 2011
From: Sam Hartman <[email-masked]>
To: Gabriel =?iso-8859-1?Q?L=F3pez?= <[email-masked]>
Date: Fri, 21 Jan 2011 07:30:17 -0500
Cc: [email-masked]
Subject: Re: [abfab] draft-lear-abfab-arch-01 posted

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

    Gabriel> El 21/01/11 10:53, Eliot Lear escribió:
    >> Hi Gabriel,
    >> 
    >> Thank you for your comments.  First, everyone please remember
    >> that this draft is absolutely a work in progress and meant to
    >> reflect what we are in fact standardizing, as well as indicate
    >> what we are not.  Perhaps it also serves as an excellent way to
    >> focus us on what we may need to standardize but have not yet
    >> agreed to do so.
    >> 
    >> As to your comments:
    >> 
    >> On 1/21/11 10:13 AM, Gabriel López wrote:
    >>> El 20/01/11 00:36, Jim Schaad escribió:
    >>>> I am in favor of having some diagrams really early in the
    >>>> processes.  I think this really helps to get understanding
    >>>> setup early.  But I tend to be a very pictorial person.
    >>>> 
    >>> I agree with Jim here, flow diagrams will help to understand the
    >>> architecture and to detect missing problems.
    >> I agree, but I'm not sure that was what Jim was actually saying.
    >> Jim, were you asking for additional pictoral-non-flow-based
    >> diagrams?  If so, what would you find useful?
    >>> 
    >>> some other comments:
    >>> 
    >>> - pag. 6. - 5. [... ]At this stage, the RP will likely have no
    >>> idea who the principal is.
    >>> 
    >>> You propose here to optionally send a SAML Attribute Query to
    >>> the idP/AA, but this query has to include the user's
    >>> subject. How does it match with the previous sentence?
    >> At that point we are not yet ready to issue a SAML Attribute
    >> Query.  That should happen in Step 10.  As you can see there is
    >> some XXX in there that needs to be completed.
    Gabriel> so, the idp returns SAML attributes without a SAML
    Gabriel> attribute query or the RP, in a latter second round-trip
    Gabriel> sends the SAML attribute query to the idP over RADIUS.
    Gabriel> That's one of the issues the diagrams should clarify :)

I'd like to push back on this a bit.

If there's one thing coming out of the attribute provider discussion it
is a strong indication of complexity.  Let's have the basic abfab
architecture not include support for multiple round trip attribute
queries.  No one has stepped forward to do the work.  The current code,
GSS EAP spec, GSS naming extensions and semantics of the SAML attributes
all need to be extended.

I think Josh has volunteered to do some of the work of extending the AAA
attribute semantics.

I think that Eliot had volunteered to take a stab at writing up some of
the architectural issues with the attribute query problem to show that
it is something we can do as a future extension.  I think there's plenty
of text in the list discussion to support that.

However, this feature is detachable from the base architecture.
Let's detach it: the base architecture is complex enough.

What would this mean?  It would mean we would not discuss additional
AAA-based attribute queries in the diagrams or the step-by-step
overview. We would have a brief discussion of the issues in their own
section, but would not enumerate the interactions in the rest of the
document.  We will not make it a requirement that components of the
system designed today support these queries.  We will continue to make
sure that what we build can be extended in the future to support
multiple rounds.

When someone steps forward, they can write documents extending our
system to support this feature.  Probably at least one of the documents
needs to fall into kitten not here.

--Sam

From [email-masked]  Fri Jan 21 04:39:51 2011
Date: Fri, 21 Jan 2011 13:42:56 +0100
From: =?ISO-8859-1?Q?Gabriel_L=F3pez?= <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked]
Subject: Re: [abfab] draft-lear-abfab-arch-01 posted

El 21/01/11 13:30, Sam Hartman escribi�:
>>>>>> "Gabriel" == Gabriel L�pez<[email-masked]>  writes:
>
>      Gabriel>  so, the idp returns SAML attributes without a SAML
>      Gabriel>  attribute query or the RP, in a latter second round-trip
>      Gabriel>  sends the SAML attribute query to the idP over RADIUS.
>      Gabriel>  That's one of the issues the diagrams should clarify :)
>
> I'd like to push back on this a bit.
>
> If there's one thing coming out of the attribute provider discussion it
> is a strong indication of complexity.  Let's have the basic abfab
> architecture not include support for multiple round trip attribute
> queries.  No one has stepped forward to do the work.  The current code,
> GSS EAP spec, GSS naming extensions and semantics of the SAML attributes
> all need to be extended.

That's what I supposed, and I think should be clarified in the document. 
Following this approach, the current document proposes to return the 
attribute statements without sending an attribute query. As far as I 
understood.
Maybe it is a low level detail that should not be mentioned in the 
document but I think should be clarified.

Best regards, Gabi.
>
>
> --Sam

-- 
----------------------------------------------------------------
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]  Fri Jan 21 04:40:59 2011
From: Josh Howlett <[email-masked]>
To: Sam Hartman <[email-masked]>, =?iso-8859-1?Q?Gabriel_L=F3pez?= <[email-masked]>
Date: Fri, 21 Jan 2011 12:44:00 +0000
Accept-Language: en-GB, en-US
Cc: Josh Howlett <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [abfab] draft-lear-abfab-arch-01 posted

> Probably at least one of the documents
> needs to fall into kitten not here.

Is it worth having some discussion at Kitten in Prague, if only to explain =
the use-case? (in fact, I think this is the second nice-to-have that we've =
identified as having a dependency there).

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 Oxford, Didcot, Oxfordshire. OX11 0SG

From [email-masked]  Fri Jan 21 05:47:40 2011
Date: Fri, 21 Jan 2011 14:50:24 +0100
From: Eliot Lear <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked]
Subject: Re: [abfab] draft-lear-abfab-arch-01 posted

Hi Sam,

On 1/21/11 1:30 PM, Sam Hartman wrote:
> However, this feature is detachable from the base architecture.
> Let's detach it: the base architecture is complex enough.

Again- that is fine so long as we don't end up redoing the architecture
later because we didn't think about this case now.  That's the amount of
thought we have to give to the problem now, IMHO.

Eliot

From [email-masked]  Fri Jan 21 06:17:48 2011
From: Sam Hartman <[email-masked]>
To: Josh Howlett <[email-masked]>
Date: Fri, 21 Jan 2011 09:20:25 -0500
Cc: [email-masked], "[email-masked]" <[email-masked]>
Subject: Re: [abfab] draft-lear-abfab-arch-01 posted

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

    >> Probably at least one of the documents needs to fall into kitten
    >> not here.

    Josh> Is it worth having some discussion at Kitten in Prague, if
    Josh> only to explain the use-case? (in fact, I think this is the
    Josh> second nice-to-have that we've identified as having a
    Josh> dependency there).

I think talking to the kitten chairs about a brief abfab update as a
recurring item would be good.

I think we've identified this and something about credential/network
selection as nice-to-have.

From [email-masked]  Fri Jan 21 06:18:46 2011
From: Sam Hartman <[email-masked]>
To: Eliot Lear <[email-masked]>
Date: Fri, 21 Jan 2011 09:21:23 -0500
Cc: [email-masked]
Subject: Re: [abfab] draft-lear-abfab-arch-01 posted

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

    Eliot> Hi Sam,
    Eliot> On 1/21/11 1:30 PM, Sam Hartman wrote:
    >> However, this feature is detachable from the base architecture.
    >> Let's detach it: the base architecture is complex enough.

    Eliot> Again- that is fine so long as we don't end up redoing the
    Eliot> architecture later because we didn't think about this case
    Eliot> now.  That's the amount of thought we have to give to the
    Eliot> problem now, IMHO.

You and I are in 100% agreement.  I tried to capture that in the longer
part of my message; sorry if it was not clear.

--Sam

From [email-masked]  Fri Jan 21 13:25:17 2011
From: "Jim Schaad" <[email-masked]>
To: "Sam Hartman" <[email-masked]>
Date: Fri, 21 Jan 2011 13:46:33 -0800
Cc: [email-masked]
Subject: [abfab] Comments on draft-ietf-abfab-aaa-saml-00

Sam,

I think there is a disconnect between the picture and the text.  The picture
has a field called MT but the text has a field called Construct Type (CT).
I believe that these are supposed to be the same fields and are mis-labeled.

I am going to show Radius ignorance now, I assume there must be a rule that
you cannot change the order of attributes in AAA, otherwise just a simple
concatenation would not work.  Is there a rule or assumption that all of the
parts of a fragmented attribute would be contiguous?  

I think that for completeness we should be able to have multiple SAML
elements present as attributes.  This would require either an intervening
other element or the ability to distinguish between continued items and
first time items.  Should this be done by making four elements rather than
just two?  Or by length prefixing the construct field?

What do you think the level of review that needs to be added for additional
elements?  Do we need to further refine the range of construct numbers to
have private and RFC required numbers?

Please number your TBD values so that I can distinguish between them without
having to think.

Is there a reason to label this as being SAML specific rather than just
letting it be XML values and letting the construct type identify the type of
values?

Would it make sense to create a new CT value for just carrying an SAML
assertion which is not part of a request or response?  Doing so would allow
for one to toss in arbitrary (and hopefully related) items that were not
actually asked for.

Jim

From [email-masked]  Fri Jan 21 13:35:32 2011
From: "Cantor, Scott E." <[email-masked]>
To: Jim Schaad <[email-masked]>
Date: Fri, 21 Jan 2011 21:38:14 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [abfab] Comments on draft-ietf-abfab-aaa-saml-00

> Is there a reason to label this as being SAML specific rather than just
> letting it be XML values and letting the construct type identify the type=
 of
> values?

Because it would be expensive to have to go parsing things just to find the=
 one you knew how to handle. Same reason most XML vocabularies have their o=
wn MIME types.

-- Scott

From [email-masked]  Fri Jan 21 13:41:46 2011
From: Sam Hartman <[email-masked]>
To: "Cantor\, Scott E." <[email-masked]>
Date: Fri, 21 Jan 2011 16:44:21 -0500
Cc: [email-masked]
Subject: Re: [abfab] Comments on draft-ietf-abfab-aaa-saml-00

[Jim, your mail server is rejecting all my messages, so note that I've
chosen to not send some private comments I would have otherwise sent
you.]

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

    >> Is there a reason to label this as being SAML specific rather
    >> than just letting it be XML values and letting the construct type
    >> identify the type of values?

    Cantor,> Because it would be expensive to have to go parsing things
    Cantor,> just to find the one you knew how to handle. Same reason
    Cantor,> most XML vocabularies have their own MIME types.

Also, we're going to need to attach processing semantics here, like the
discussion of technical trust we've been having.  Those semantics are
very much SAML specific.

From [email-masked]  Fri Jan 21 14:04:43 2011
From: "Jim Schaad" <[email-masked]>
To: "'Cantor, Scott E.'" <[email-masked]>
Date: Fri, 21 Jan 2011 14:26:01 -0800
Cc: [email-masked]
Subject: Re: [abfab] Comments on draft-ietf-abfab-aaa-saml-00

Scott,

What I suggested was that the overall attribute be allowed to carry
arbitrary XML rather than be restricted to SAML.  It would still have the CT
field which could be used to identify more specifically what the XML content
was.

Jim

> -----Original Message-----
> From: Cantor, Scott E. [mailto:[email-masked]]
> Sent: Friday, January 21, 2011 1:38 PM
> To: Jim Schaad
> Cc: [email-masked]
> Subject: RE: [abfab] Comments on draft-ietf-abfab-aaa-saml-00
> 
> > Is there a reason to label this as being SAML specific rather than
> > just letting it be XML values and letting the construct type identify
> > the type of values?
> 
> Because it would be expensive to have to go parsing things just to find
the
> one you knew how to handle. Same reason most XML vocabularies have
> their own MIME types.
> 
> -- Scott

From [email-masked]  Fri Jan 21 14:24:43 2011
From: "Cantor, Scott E." <[email-masked]>
To: Jim Schaad <[email-masked]>
Date: Fri, 21 Jan 2011 22:26:43 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [abfab] Comments on draft-ietf-abfab-aaa-saml-00

> What I suggested was that the overall attribute be allowed to carry
> arbitrary XML rather than be restricted to SAML.  It would still have the=
 CT
> field which could be used to identify more specifically what the XML cont=
ent
> was.

Doesn't that just create a second registry to maintain? You could stick URI=
s into the CT field to avoid that, I suppose, but I think it just moves the=
 document into the position of managing a framework for all uses of XML in =
RADIUS attributes, which is probably out of scope.

-- Scott

From [email-masked]  Mon Jan 24 13:07:34 2011
Resent-To: [email-masked]
Resent-From: Sam Hartman <[email-masked]>
Resent-Date: Mon, 24 Jan 2011 16:10:14 -0500
Resent-Message-ID: <[email-masked]>
From: Sam Hartman <[email-masked]>
To: [email-masked],Alan DeKok <[email-masked]>
Date: Mon, 24 Jan 2011 16:05:42 -0500
Lines: 50
Subject: [abfab] What are our AAA attribute requirements

I've been in the middle of a discussion with Alan trying to figure out
requirements for a RADIUS library for Moonshot to use.  (Our current
solution needs a bit of work)

We were having a discussion surrounding RADIUS attribute dictionaries.
Typically a RADIUs server or library has a dictionary that maps an
attribute number to a name and gives the attribute a type such as
integer, string or IP address.

Alan points out that it would be easy to give the application the opaque
RADIUS value but that if we need to decode the attribute in a manner
specific to its type then the dictionary is required.

RFC 2138 defines four types of data: strings, integers, IP addresses and
times. (Additional types such as IPv6 prefixes are defined by later
specifications.)  In addition, there's a question about how multi-valued
attributes are handled. For example, for the EAP messages and for our
use of SAML, we'reassuming that the multiple values are concatenated.
An alternative for some attributes would be to treat them as multiple
values of a short attribute.

I think the interpretation of RADIUS strings and opaque data would be
the same as far as we're concerned. GSS-API buffers don't tend to have a
trailing null in the C bindings, so I can't see a difference.

Integers are MSB-first 32-bit quantities. As are IP addresses and times.

So, we have a number of options:

1) Just give the application opaque data with a specific interpretation
of multi-valued attributes we hard-code. 

2) Require that the GSS-EAP implementation understand the type and
multi-value semantics of anything it exposes. That's kind of undesirable
because we want the GSS-EAP implementation to eventually be a component
of the operating system and we expect deployments to extend the set of
attributes thought the use of vendor-specific attributes. We expect
facilities like Shibboleth to be able to map AAA attributes into local
attributes under the control of a configuration file.

3) Encode the type into the attribute name exposed through GSS-API
naming extensions. We'd need to decide how inquire_name_attrs works (an
API for enumerating all the attributes an application may request.) It
could assume things were strings but applications could request the
attribute with a different type if they knew better.

Comments very welcome.

From [email-masked]  Mon Jan 24 13:25:08 2011
From: Luke Howard <[email-masked]>
Date: Tue, 25 Jan 2011 08:27:50 +1100
To: Sam Hartman <[email-masked]>
Cc: [email-masked]
Subject: Re: [abfab] What are our AAA attribute requirements

> I think the interpretation of RADIUS strings and opaque data would be
> the same as far as we're concerned. GSS-API buffers don't tend to have =
a
> trailing null in the C bindings, so I can't see a difference.

Don't forget that get_attribute provides a display_value (printable =
representation) and that this is supported in the Moonshot =
implementation -- but requires the RADIUS library be configured with =
dictionaries. value is always the raw data.

> 2) Require that the GSS-EAP implementation understand the type and
> multi-value semantics of anything it exposes. That's kind of =
undesirable
> because we want the GSS-EAP implementation to eventually be a =
component
> of the operating system and we expect deployments to extend the set of
> attributes thought the use of vendor-specific attributes. We expect
> facilities like Shibboleth to be able to map AAA attributes into local
> attributes under the control of a configuration file.

Isn't then the dictionary just another configuration file?

> 3) Encode the type into the attribute name exposed through GSS-API
> naming extensions. We'd need to decide how inquire_name_attrs works =
(an
> API for enumerating all the attributes an application may request.) It
> could assume things were strings but applications could request the
> attribute with a different type if they knew better.

Seems less desirable.

-- Luke=

From [email-masked]  Mon Jan 24 13:29:38 2011
From: Sam Hartman <[email-masked]>
To: Luke Howard <[email-masked]>
Date: Mon, 24 Jan 2011 16:32:17 -0500
Cc: [email-masked]
Subject: Re: [abfab] What are our AAA attribute requirements

>>>>> "Luke" == Luke Howard <[email-masked]> writes:

    >> I think the interpretation of RADIUS strings and opaque data
    >> would be the same as far as we're concerned. GSS-API buffers
    >> don't tend to have a trailing null in the C bindings, so I can't
    >> see a difference.

    Luke> Don't forget that get_attribute provides a display_value
    Luke> (printable representation) and that this is supported in the
    Luke> Moonshot implementation -- but requires the RADIUS library be
    Luke> configured with dictionaries. value is always the raw data.

Why do we (kitten--Nico, Leif and I) do these things to ourselves?

    >> 2) Require that the GSS-EAP implementation understand the type
    >> and multi-value semantics of anything it exposes. That's kind of
    >> undesirable because we want the GSS-EAP implementation to
    >> eventually be a component of the operating system and we expect
    >> deployments to extend the set of attributes thought the use of
    >> vendor-specific attributes. We expect facilities like Shibboleth
    >> to be able to map AAA attributes into local attributes under the
    >> control of a configuration file.

    Luke> Isn't then the dictionary just another configuration file?
Yes.  For that use it's probably OK.  However it requires you get the
dictionary set up correctly even if your application understands what
RADIUS attribute it wants.

    >> 3) Encode the type into the attribute name exposed through
    >> GSS-API naming extensions. We'd need to decide how
    >> inquire_name_attrs works (an API for enumerating all the
    >> attributes an application may request.) It could assume things
    >> were strings but applications could request the attribute with a
    >> different type if they knew better.

    Luke> Seems less desirable.
Agreed.

From [email-masked]  Mon Jan 24 13:32:55 2011
Date: Mon, 24 Jan 2011 15:35:48 -0600
From: Tom Scavo <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked]
Subject: Re: [abfab] What are our AAA attribute requirements

On Mon, Jan 24, 2011 at 3:05 PM, Sam Hartman
<[email-masked]> wrote:
>
> We expect
> facilities like Shibboleth to be able to map AAA attributes into local
> attributes under the control of a configuration file.

It might be easier to consider all attribute values to be mere
strings. Also, I think you should avoid an extra configuration file if
at all possible.

Just my two cents worth :-)

Tom

From [email-masked]  Mon Jan 24 13:42:33 2011
From: "Cantor, Scott E." <[email-masked]>
To: Sam Hartman <[email-masked]>, "[email-masked]" <[email-masked]>, Alan DeKok <[email-masked]>
Date: Mon, 24 Jan 2011 21:45:24 +0000
Accept-Language: en-US
Subject: Re: [abfab] What are our AAA attribute requirements

> 2) Require that the GSS-EAP implementation understand the type and
> multi-value semantics of anything it exposes. That's kind of undesirable
> because we want the GSS-EAP implementation to eventually be a component
> of the operating system and we expect deployments to extend the set of
> attributes thought the use of vendor-specific attributes. We expect
> facilities like Shibboleth to be able to map AAA attributes into local
> attributes under the control of a configuration file.

I specifically have to know what formats, if any, I would need to implement=
 support within Shibboleth (or more accurately in an extension of it) for u=
sing as input. I have been expecting to build something that operates on th=
e GSS context via the naming extensions to pull out non-SAML information an=
d be able to process it, but that obviously requires additional configurati=
on of some sort.

It seems like a bad thing to require that sort of configuration in both pla=
ces, though. I was expecting that if Shibboleth was going to be chewing on =
RADIUS attributes that there wouldn't need to be anything in the way of ext=
ra configuration in the GSS layer to make them available.

-- Scott

From [email-masked]  Mon Jan 24 13:03:05 2011
From: Sam Hartman <[email-masked]>
To: [email-masked],Alan DeKok <[email-masked]>
Date: Mon, 24 Jan 2011 16:05:42 -0500
Subject: [abfab] What are our AAA attribute requirements

I've been in the middle of a discussion with Alan trying to figure out
requirements for a RADIUS library for Moonshot to use.  (Our current
solution needs a bit of work)

We were having a discussion surrounding RADIUS attribute dictionaries.
Typically a RADIUs server or library has a dictionary that maps an
attribute number to a name and gives the attribute a type such as
integer, string or IP address.

Alan points out that it would be easy to give the application the opaque
RADIUS value but that if we need to decode the attribute in a manner
specific to its type then the dictionary is required.

RFC 2138 defines four types of data: strings, integers, IP addresses and
times. (Additional types such as IPv6 prefixes are defined by later
specifications.)  In addition, there's a question about how multi-valued
attributes are handled. For example, for the EAP messages and for our
use of SAML, we'reassuming that the multiple values are concatenated.
An alternative for some attributes would be to treat them as multiple
values of a short attribute.

I think the interpretation of RADIUS strings and opaque data would be
the same as far as we're concerned. GSS-API buffers don't tend to have a
trailing null in the C bindings, so I can't see a difference.

Integers are MSB-first 32-bit quantities. As are IP addresses and times.

So, we have a number of options:

1) Just give the application opaque data with a specific interpretation
of multi-valued attributes we hard-code. 

2) Require that the GSS-EAP implementation understand the type and
multi-value semantics of anything it exposes. That's kind of undesirable
because we want the GSS-EAP implementation to eventually be a component
of the operating system and we expect deployments to extend the set of
attributes thought the use of vendor-specific attributes. We expect
facilities like Shibboleth to be able to map AAA attributes into local
attributes under the control of a configuration file.

3) Encode the type into the attribute name exposed through GSS-API
naming extensions. We'd need to decide how inquire_name_attrs works (an
API for enumerating all the attributes an application may request.) It
could assume things were strings but applications could request the
attribute with a different type if they knew better.

Comments very welcome.

From [email-masked]  Mon Jan 24 13:57:50 2011
From: Sam Hartman <[email-masked]>
To: [email-masked]
Date: Mon, 24 Jan 2011 17:00:27 -0500
Subject: [abfab] exported name format

Should our exported name format be any different than the string
representation of our mechanism name? Section 3.2 of RFC 2743 defines
the wrapping for our name form, but I'm wondering what should go in the
wrapping.
Unless someone thinks something more needs to go in I think it should be
just the string form of the MN.

--Sam

From [email-masked]  Mon Jan 24 13:59:14 2011
From: Sam Hartman <[email-masked]>
To: [email-masked]
Date: Mon, 24 Jan 2011 16:59:03 -0500
Subject: [abfab] OIDs

#The chairs were going to look into OIDs at the last IETF.
What's the status of that?

So far, I believe we need an OID for:

1) the mechanism

2) A name type for importing the string representation of a gss-eap name

It seems likely that additional oids will be needed in the future.

From [email-masked]  Mon Jan 24 14:00:25 2011
From: Sam Hartman <[email-masked]>
To: Tom Scavo <[email-masked]>
Date: Mon, 24 Jan 2011 17:03:04 -0500
Cc: [email-masked]
Subject: Re: [abfab] What are our AAA attribute requirements

>>>>> "Tom" == Tom Scavo <[email-masked]> writes:

    Tom> On Mon, Jan 24, 2011 at 3:05 PM, Sam Hartman
    Tom> <[email-masked]> wrote:
    >> 
> We expect facilities like Shibboleth to be able to map AAA attributes
    >> into local attributes under the control of a configuration file.

    Tom> It might be easier to consider all attribute values to be mere
    Tom> strings. 

What does it mean to consider all attributes strings?

From [email-masked]  Mon Jan 24 14:03:33 2011
From: "Cantor, Scott E." <[email-masked]>
To: Sam Hartman <[email-masked]>, Tom Scavo <[email-masked]>
Date: Mon, 24 Jan 2011 22:06:24 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [abfab] What are our AAA attribute requirements

>What does it mean to consider all attributes strings?

In XML, it just means treating everything as text and ignoring data
typing. It doesn't work when the data representation isn't textual with a
self-descriptive character encoding like XML's.

-- Scott

From [email-masked]  Mon Jan 24 14:04:27 2011
Date: Mon, 24 Jan 2011 23:07:14 +0100
From: Leif Johansson <[email-masked]>
To: [email-masked]
Subject: Re: [abfab] OIDs

On 01/24/2011 10:59 PM, Sam Hartman wrote:
> #The chairs were going to look into OIDs at the last IETF.
> What's the status of that?
> 
> So far, I believe we need an OID for:
> 
> 1) the mechanism
> 
> 2) A name type for importing the string representation of a gss-eap name
> 
> It seems likely that additional oids will be needed in the future.

As I recall we talked to Sean and came to the conclusion that we can't
ask the IANA to pre-allocate OIDs for us but I may be mis-remembering
this.

	Cheers Leif

From [email-masked]  Mon Jan 24 14:57:12 2011
Date: Tue, 25 Jan 2011 00:00:02 +0100
From: Leif Johansson <[email-masked]>
To: [email-masked]
Subject: Re: [abfab] What are our AAA attribute requirements

> Why do we (kitten--Nico, Leif and I) do these things to ourselves?

As a former colleague of mine said when I, upon the birth of his 5th
child, asked him "what were you thinking?", replied "it seemed like a
good idea at the time".

	Cheers Leif

From [email-masked]  Mon Jan 24 15:41:42 2011
From: Sam Hartman <[email-masked]>
To: Leif Johansson <[email-masked]>
Date: Mon, 24 Jan 2011 18:44:21 -0500
Cc: [email-masked]
Subject: Re: [abfab] What are our AAA attribute requirements

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

    >> Why do we (kitten--Nico, Leif and I) do these things to
    >> ourselves?

    Leif> As a former colleague of mine said when I, upon the birth of
    Leif> his 5th child, asked him "what were you thinking?", replied
    Leif> "it seemed like a good idea at the time".

To be fair, thinking for 30 minutes about this, it isn't all that bad of
an idea as an optional facility.

--Sam

From [email-masked]  Mon Jan 24 18:41:32 2011
Date: Tue, 25 Jan 2011 03:44:20 +0100
From: Alan DeKok <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked]
Subject: Re: [abfab] What are our AAA attribute requirements

Sam Hartman wrote:
>     Luke> Isn't then the dictionary just another configuration file?
> Yes.  For that use it's probably OK.  However it requires you get the
> dictionary set up correctly even if your application understands what
> RADIUS attribute it wants.

  If the application understands the attributes it wants, the
dictionaries can be statically defined.

  The dictionaries are mainly used by *administrators* to create
authorization policies.  "If I see FOO with value BAR, do something".
The definition of FOO is in the dictionary, which maps bytes in the
RADIUS packet to "data type for BAR".  The "do something" part is
controlled by the administrator, and can be pretty much anything from
"run a shell script" to "return other attributes".

  RADIUS clients have traditionally been very limited.  They request a
particular kind of authorization/authentication.  They receive either a
NAK or an ACK.  The ACK contains specific details about the requested
authorization, such as IP address assignment.

  If the ACK contains authorizations for things the client *didn't* ask
for, the client ignores them, because the authorizations are
inappropriate.  Even if the client understands the attributes, it
doesn't know what to do with them, because they don't fit within an
existing authorization framework.

  Alan DeKok.

From [email-masked]  Mon Jan 24 20:16:45 2011
From: Luke Howard <[email-masked]>
Date: Tue, 25 Jan 2011 15:19:32 +1100
To: Sam Hartman <[email-masked]>
Cc: [email-masked]
Subject: Re: [abfab] OIDs

On 25/01/2011, at 8:59 AM, Sam Hartman wrote:

> #The chairs were going to look into OIDs at the last IETF.
> What's the status of that?
>=20
> So far, I believe we need an OID for:
>=20
> 1) the mechanism
>=20
> 2) A name type for importing the string representation of a gss-eap =
name

That's all I have (modulo mechanisms are suffixed with encryption type).

There are also a bunch of implementation-specific OIDs for =
set_cred_option but we don't need to standardise those.

-- Luke=

From [email-masked]  Tue Jan 25 03:21:12 2011
Date: Tue, 25 Jan 2011 12:24:03 +0100
From: Eliot Lear <[email-masked]>
To: Leif Johansson <[email-masked]>
Cc: [email-masked]
Subject: Re: [abfab] OIDs

Leif,

Can you check this.  There is some leeway given for emergent work from
the IETF.  But it should be baked at least a little.

Eliot

On 1/24/11 11:07 PM, Leif Johansson wrote:
> On 01/24/2011 10:59 PM, Sam Hartman wrote:
> > #The chairs were going to look into OIDs at the last IETF.
> > What's the status of that?
>
> > So far, I believe we need an OID for:
>
> > 1) the mechanism
>
> > 2) A name type for importing the string representation of a gss-eap name
>
> > It seems likely that additional oids will be needed in the future.
>
> As I recall we talked to Sean and came to the conclusion that we can't
> ask the IANA to pre-allocate OIDs for us but I may be mis-remembering
> this.
>
>     Cheers Leif
_______________________________________________
abfab mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/abfab

From [email-masked]  Tue Jan 25 05:15:50 2011
From: Sam Hartman <[email-masked]>
To: Alan DeKok <[email-masked]>
Date: Tue, 25 Jan 2011 08:18:27 -0500
Cc: [email-masked]
Subject: Re: [abfab] What are our AAA attribute requirements

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

    Alan> Sam Hartman wrote:
    Luke> Isn't then the dictionary just another configuration file?
    >> Yes.  For that use it's probably OK.  However it requires you get
    >> the dictionary set up correctly even if your application
    >> understands what RADIUS attribute it wants.

    Alan>   If the application understands the attributes it wants, the
    Alan> dictionaries can be statically defined.

As I mentioned, the GSS-API naming extensions API does not present a way
for an application to give a dictionary to a RADIUS library.
So, if we were designing something for RADIUS instead of working with an
existing abstract interface, you would be correct.

From [email-masked]  Tue Jan 25 05:22:19 2011
Date: Tue, 25 Jan 2011 14:25:04 +0100
From: Leif Johansson <[email-masked]>
To: Eliot Lear <[email-masked]>
Cc: [email-masked]
Subject: Re: [abfab] OIDs

On 01/25/2011 12:24 PM, Eliot Lear wrote:
> Leif,
> 
> Can you check this.  There is some leeway given for emergent work from
> the IETF.  But it should be baked at least a little.
> 

I'm on it. The initial response from Sean is that we can ask IANA for
an experimental ARC. Do we want that even if it means we may have to
change things as things get published?

	Cheers Leif

From [email-masked]  Tue Jan 25 05:51:48 2011
Date: Tue, 25 Jan 2011 08:54:42 -0500
From: Sean Turner <[email-masked]>
To: Leif Johansson <[email-masked]>
Cc: [email-masked]
Subject: Re: [abfab] OIDs

My thinking is that we get a stable abfab arc and then set up arcs under 
it.  One being experimental.

spt

On 1/25/11 8:25 AM, Leif Johansson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 01/25/2011 12:24 PM, Eliot Lear wrote:
>> Leif,
>>
>> Can you check this.  There is some leeway given for emergent work from
>> the IETF.  But it should be baked at least a little.
>>
>
> I'm on it. The initial response from Sean is that we can ask IANA for
> an experimental ARC. Do we want that even if it means we may have to
> change things as things get published?
>
> 	Cheers Leif
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk0+zzAACgkQ8Jx8FtbMZncrBwCgiu5LBk1mIdJW3R+9RakWWcQM
> gsEAn1ZWKBrawkM5fEZe7I/rfws+y3F1
> =XCc3
> -----END PGP SIGNATURE-----
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab
>

From [email-masked]  Tue Jan 25 06:05:43 2011
From: "Leif Johansson" <[email-masked]>
Date: Tue, 25 Jan 2011 15:08:20 +0100
To: Sean Turner <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [abfab] OIDs

If nobody objects: make it so!

25 jan 2011 kl. 14:55 skrev "Sean Turner" <[email-masked]>:

> My thinking is that we get a stable abfab arc and then set up arcs under i=
t.  One being experimental.
>=20
> spt
>=20
> On 1/25/11 8:25 AM, Leif Johansson wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>=20
>> On 01/25/2011 12:24 PM, Eliot Lear wrote:
>>> Leif,
>>>=20
>>> Can you check this.  There is some leeway given for emergent work from
>>> the IETF.  But it should be baked at least a little.
>>>=20
>>=20
>> I'm on it. The initial response from Sean is that we can ask IANA for
>> an experimental ARC. Do we want that even if it means we may have to
>> change things as things get published?
>>=20
>>    Cheers Leif
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.10 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>=20
>> iEYEARECAAYFAk0+zzAACgkQ8Jx8FtbMZncrBwCgiu5LBk1mIdJW3R+9RakWWcQM
>> gsEAn1ZWKBrawkM5fEZe7I/rfws+y3F1
>> =3DXCc3
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> abfab mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/abfab
>>=20

From [email-masked]  Tue Jan 25 06:09:49 2011
From: Sam Hartman <[email-masked]>
To: Leif Johansson <[email-masked]>
Date: Tue, 25 Jan 2011 09:12:26 -0500
Cc: [email-masked]
Subject: Re: [abfab] OIDs

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

    Leif> On 01/25/2011 12:24 PM, Eliot Lear wrote:
    >> Leif,
    >> 
    >> Can you check this.  There is some leeway given for emergent work
    >> from the IETF.  But it should be baked at least a little.
    >> 

I'm on it. The initial response from Sean is that we can ask IANA for
    Leif> an experimental ARC. Do we want that even if it means we may
    Leif> have to change things as things get published?

I think changing things as they get published would be fairly
problematic.  I'd much rather use non-IETF OIDs than live with that
constraint.

If we're forced to break backward compatibility then we'll have to
evaluate whether the OID needs to change. Currently, I think the answer
would be no; fairly soon, I think the answer would be yes.  However I
don't think it would be a big deal if we needed to burn a few codepoints
in an ABFAB mechanisms oid arc.  I also think it matters very little
where that OID arc lives--IETF or not.

From [email-masked]  Tue Jan 25 06:22:42 2011
Date: Tue, 25 Jan 2011 15:25:30 +0100
From: Leif Johansson <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked]
Subject: Re: [abfab] OIDs

> If we're forced to break backward compatibility then we'll have to
> evaluate whether the OID needs to change. Currently, I think the answer
> would be no; fairly soon, I think the answer would be yes.  However I
> don't think it would be a big deal if we needed to burn a few codepoints
> in an ABFAB mechanisms oid arc.  I also think it matters very little
> where that OID arc lives--IETF or not.

So basically your vote is on an enterprise arc. I'm not sure I
understand the reasons why abfab has requirement that differ so
much from any other IETF protocol where protocol numbers are
typically allocated on publication of the RFC.

	Cheers Leif

From [email-masked]  Tue Jan 25 06:30:29 2011
Date: Tue, 25 Jan 2011 15:33:21 +0100
From: Eliot Lear <[email-masked]>
To: Leif Johansson <[email-masked]>
Cc: [email-masked]
Subject: Re: [abfab] OIDs

On 1/25/11 3:25 PM, Leif Johansson wrote:
> So basically your vote is on an enterprise arc. I'm not sure I
> understand the reasons why abfab has requirement that differ so
> much from any other IETF protocol where protocol numbers are
> typically allocated on publication of the RFC.

Neither do I but then I'm the guy who thought it was possible to get an
early allocation from IANA for IETF protocol work.

From [email-masked]  Tue Jan 25 06:50:57 2011
Date: Tue, 25 Jan 2011 09:52:50 -0500
From: Sean Turner <[email-masked]>
To: Eliot Lear <[email-masked]>
Cc: [email-masked]
Subject: Re: [abfab] OIDs

On 1/25/11 9:33 AM, Eliot Lear wrote:
>
>
> On 1/25/11 3:25 PM, Leif Johansson wrote:
>> So basically your vote is on an enterprise arc. I'm not sure I
>> understand the reasons why abfab has requirement that differ so
>> much from any other IETF protocol where protocol numbers are
>> typically allocated on publication of the RFC.
>
> Neither do I but then I'm the guy who thought it was possible to get an
> early allocation from IANA for IETF protocol work.

I think we can get an early allocation too.  The question is how much of 
a purist do we want to be?  Technically, when you assign an OID it's 
linked to a particular syntax.  If you change that syntax, then you need 
a new OID.

spt

From [email-masked]  Tue Jan 25 06:55:29 2011
Date: Tue, 25 Jan 2011 15:58:21 +0100
From: Eliot Lear <[email-masked]>
To: Sean Turner <[email-masked]>
Cc: [email-masked]
Subject: Re: [abfab] OIDs

On 1/25/11 3:52 PM, Sean Turner wrote:
> I think we can get an early allocation too.  The question is how much
> of a purist do we want to be?  Technically, when you assign an OID
> it's linked to a particular syntax.  If you change that syntax, then
> you need a new OID.
>

So burn OIDs early.  It's not as if they're IPv4 addresses ;-)

Eliot

From [email-masked]  Tue Jan 25 07:17:44 2011
From: Sam Hartman <[email-masked]>
To: Leif Johansson <[email-masked]>
Date: Tue, 25 Jan 2011 10:20:22 -0500
Cc: [email-masked]
Subject: Re: [abfab] OIDs

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

    >> If we're forced to break backward compatibility then we'll have
    >> to evaluate whether the OID needs to change. Currently, I think
    >> the answer would be no; fairly soon, I think the answer would be
    >> yes.  However I don't think it would be a big deal if we needed
    >> to burn a few codepoints in an ABFAB mechanisms oid arc.  I also
    >> think it matters very little where that OID arc lives--IETF or
    >> not.

    Leif> So basically your vote is on an enterprise arc. I'm not sure I
    Leif> understand the reasons why abfab has requirement that differ
    Leif> so much from any other IETF protocol where protocol numbers
    Leif> are typically allocated on publication of the RFC.

No, my vote would be on an IETF arc under the control of the WG turned
over to IANA on our disolution.

I actually think the idea of assigning codepoints on publication for new
protocols works fairly poorly for most protocols.  As someone
implementing ABFAB, I will probably ship implementations before an RFC
is published.  If we need to change because of a real compatibility
issue, we can do that.  However, it's not work breaking backward
compatibility with deployed code just to get a nicer number.

--Sam

From [email-masked]  Tue Jan 25 07:38:33 2011
Date: Tue, 25 Jan 2011 16:41:15 +0100
From: Leif Johansson <[email-masked]>
To: Eliot Lear <[email-masked]>
Cc: [email-masked]
Subject: Re: [abfab] OIDs

On 01/25/2011 03:58 PM, Eliot Lear wrote:
> 
> 
> On 1/25/11 3:52 PM, Sean Turner wrote:
>> I think we can get an early allocation too.  The question is how much
>> of a purist do we want to be?  Technically, when you assign an OID
>> it's linked to a particular syntax.  If you change that syntax, then
>> you need a new OID.
>>
> 
> So burn OIDs early.  It's not as if they're IPv4 addresses ;-)
> 
> Eliot

I tend to agree with that. The WG can figure out when a revision
has to imply allocating new OIDs I think.

From [email-masked]  Tue Jan 25 11:41:22 2011
Date: Tue, 25 Jan 2011 14:44:08 -0500
From: Sean Turner <[email-masked]>
To: Eliot Lear <[email-masked]>
Cc: [email-masked]
Subject: Re: [abfab] OIDs

On 1/25/11 9:58 AM, Eliot Lear wrote:
>
>
> On 1/25/11 3:52 PM, Sean Turner wrote:
>> I think we can get an early allocation too.  The question is how much
>> of a purist do we want to be?  Technically, when you assign an OID
>> it's linked to a particular syntax.  If you change that syntax, then
>> you need a new OID.
>>
>
> So burn OIDs early.  It's not as if they're IPv4 addresses ;-)

Yeah ;)  Seriously, some people say that the warning in RFC 2026 about 
the drafts is enough (repeated below for convenience):

    ********************************************************
    *                                                      *
    *   Under no circumstances should an Internet-Draft    *
    *   be referenced by any paper, report, or Request-    *
    *   for-Proposal, nor should a vendor claim compliance *
    *   with an Internet-Draft.                            *
    *                                                      *
    ********************************************************

and that you could assign an OID and then change the syntax without 
consequences because it's in a draft.  But, we all know that sometimes 
things get coded never get changed.

spt

From [email-masked]  Tue Jan 25 11:45:35 2011
Date: Tue, 25 Jan 2011 14:48:27 -0500
From: Sean Turner <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked]
Subject: Re: [abfab] OIDs

On 1/25/11 10:20 AM, Sam Hartman wrote:
>>>>>> "Leif" == Leif Johansson<[email-masked]>  writes:
>
>      >>  If we're forced to break backward compatibility then we'll have
>      >>  to evaluate whether the OID needs to change. Currently, I think
>      >>  the answer would be no; fairly soon, I think the answer would be
>      >>  yes.  However I don't think it would be a big deal if we needed
>      >>  to burn a few codepoints in an ABFAB mechanisms oid arc.  I also
>      >>  think it matters very little where that OID arc lives--IETF or
>      >>  not.
>
>      Leif>  So basically your vote is on an enterprise arc. I'm not sure I
>      Leif>  understand the reasons why abfab has requirement that differ
>      Leif>  so much from any other IETF protocol where protocol numbers
>      Leif>  are typically allocated on publication of the RFC.
>
> No, my vote would be on an IETF arc under the control of the WG turned
> over to IANA on our disolution.
>
> I actually think the idea of assigning codepoints on publication for new
> protocols works fairly poorly for most protocols.  As someone
> implementing ABFAB, I will probably ship implementations before an RFC
> is published.  If we need to change because of a real compatibility
> issue, we can do that.  However, it's not work breaking backward
> compatibility with deployed code just to get a nicer number.

Sam,

The question is whether you think we should get a new OID every time the 
syntax changes.   I agree that assigning an OID out of an "experimental" 
and then changing it to an "operational" arc if the syntax didn't change 
is kind of a waste of time.  I have this vague notion of the syntax 
changing a lot.  If the WG doesn't think that's going to happen then we 
probably don't have to go the experimental then switch to operational route.

One way around this is to define the syntax use a dummy OID (of your own 
devising) to ensure you can work with yourself.  Once you're convinced 
and the syntax is workable/stable - then put the OID in the draft.

spt

From [email-masked]  Tue Jan 25 12:24:03 2011
From: Simon Wilkinson <[email-masked]>
To: Sean Turner <[email-masked]>
Date: Tue, 25 Jan 2011 20:26:48 +0000
Cc: [email-masked]
Subject: Re: [abfab] OIDs

On 25 Jan 2011, at 19:44, Sean Turner wrote:
>
> Yeah ;)  Seriously, some people say that the warning in RFC 2026  
> about the drafts is enough (repeated below for convenience):

The problem is that as soon as code has been shared, people start to  
deploy it. In the open source sector, this is a real issue if the code  
is shadowing the draft. I hit exactly this problem with my  
implementation of RFC4462 for OpenSSH. There were a issues with  
earlier versions of that draft and with my implementation of them. A  
number of vendors deployed these earlier, buggy, releases and we were  
left maintaining backwards compatibility hacks for many years.

I don't think that there is any easy solution to this - release early,  
release often is always going to create these kind of conflicts, and  
there are problems that you only discover when implementations are  
produced. If those implementations are being produced as open source  
software, then people will deploy your development code, and expect it  
to not be arbitrarily broken by upgrades. So, I do feel that you are  
going to have to change OIDs if the meaning of those identifiers change.

Cheers,

Simon.

From [email-masked]  Wed Jan 26 05:44:13 2011
From: Sam Hartman <[email-masked]>
To: Sean Turner <[email-masked]>
Date: Wed, 26 Jan 2011 08:46:47 -0500
Cc: [email-masked]
Subject: Re: [abfab] OIDs

>>>>> "Sean" == Sean Turner <[email-masked]> writes:

    Sean> Sam,

    Sean> The question is whether you think we should get a new OID
    Sean> every time the syntax changes.  I agree that assigning an OID
    Sean> out of an "experimental" and then changing it to an
    Sean> "operational" arc if the syntax didn't change is kind of a
    Sean> waste of time.  I have this vague notion of the syntax
    Sean> changing a lot.  If the WG doesn't think that's going to
    Sean> happen then we probably don't have to go the experimental then
    Sean> switch to operational route.

I haven't answered this directly because  syntax is a poorly defined
term here.
These OIDs do not describe objects encoded using ASN.1.

If we were using ASN.1 I'd say that whenever we changed the syntax since
the last used version, we should change the OID. By last used version, I
mean any version that someone claimed to have implemented. If we
published draft 2 today and found a minor error and fixed it in draft 3
tomorrow I would not typically require an OID change even if the syntax
changed.

Here, I think we should change the OID if things change in a manner that
breaks compatibility.  We have some extension points in the spec so many
of the things we might want to do would not involve an OID change.  One
thing we've discussed (support for null GSS target names) probably
should involve an OID change because it changes the semantics (and
probably syntax) of the first message from client to server.

I expect we'll have one OID change from the OID in Luke's privaty arc
we're having today (for the target name change above).  Around that time
I expect there will be people using the code and past that point I think
we'd need to be fairly strict about OID changes. I don't see a need for
any spec changes that would require an OID change beyond that point,
which realistically means it will probably happen once or twice. (There
are always changes you don't anticipate.)

--Sam

From [email-masked]  Wed Jan 26 05:58:11 2011
Date: Wed, 26 Jan 2011 15:01:01 +0100
From: Leif Johansson <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked]
Subject: Re: [abfab] OIDs

> Here, I think we should change the OID if things change in a manner that
> breaks compatibility.  We have some extension points in the spec so many

Actually that is how I understood the "change syntax" bit.

	cheers Leif