Subject: [abfab] Comments on draft-lear-abfab-arch-02

From: "James Schaad" <[email-masked]>
Date: Thu, 21 Apr 2011 13:49:15 -0700

I do not seem to be getting this finished -- so I will send it as is.

Let's get you an updated second round of comments.  I should probably go
through my last list at some time and see how many were addressed, but I
haven't done that yet.  I might get some duplication from that list as I
haven't read it in a while.

1.  Introduction para 3 - I want to make sure that your definition of
federation is one that you want to make.  Specifically it would appear that
there can be federations even within a single entity in the event that actor
providing the identity information is not the same as the RP.  Would you
consider a single Kerberos or Windows enterprise to be a federation.  In
these cases the IdP being the login service and the RP being somebody
granting access to a resource (in windows possibly by an RPC).  I generally
think of federation as being between two different entities rather than
within a single entity but using multiple servers.

2.  para 'Provisioning' s/subject that an/subject than an/
	s/by by/by/

3. Section 1.1 - I am still AAA challenged.  Is it more correct to say 'a
radius or diameter server'?  Do you want to put in a generalized statement
that says you use radius but it also applies to diameter?

4. Section 1.2 - s/Some deployments are sometimes required/Some deployments
are required/  or /Deployments are sometimes required/

5.    s/betweem/between/

6.  Next to last paragraph - However, federation does not preclude the
possibility of a pre-existing relationship existing between the RP and the
Subject, nor that they may use the introduction to create a new long-term
relationship independent of the federation.

7.  Section 1.3 - kill the word such  s/number of such federated/number of
federated/
	s/has become/can become/

8.  s/For example, a school might provide online access to
   grades to a parent who is also a teacher.  She must clearly
   distinguish her role upon access./For example, a school might provide
online access to a student's grades to their parents for review, and to the
student's teacher for modifying the grades.  A teacher who is also a parent
must clearly distinguish here role upon access./

9. next para - s/identity provider a user/identity provider(s) a user/
	s/latter ans/latter as/

10.  Possible issue to include here.  In the presence of multiple
federations, the naming of individuals can become murky especially if one is
trying to associate a single individual from different federations.  Asking
a question such as does John Doe belong to an IdP (in the absence of
authentication) may get an answer for the wrong John Doe.

11.  Section 1.4 - Overview
  a)  I think you might need to have a step 2a - Client Application creates
a channel to the RP.  This is not done by the GSS-EAP mechanism as I had
originally assumed.  Let's make it clear additionally that fact will be
needed in order to setup the channel binding at a later time.  Note that at
some point there will need to be a discussion of the properties of this
channel.  It should also be noted that the type of channel used potentially
provide different issues.

 b) in step 5  either /forward a RADIUS request/ or /forward RADIUS
requests/.  AAA ignorance - would message be better than request to avoid
confusion between RADISU request and GSS/EAP request?
- I would ignore how the SAML request is encoded at this point.  So maybe
s/SAML request as a series of attributes/ SAML request for a set of
attributes/
s/.././

c) request that you go back and use subject rather than principal in this
section.  The change in terminology is not introduced.

d) in step 9, I think I have a problem with the last sentence.  These policy
checks would have been done by the AAA system or the RP and not by the IdP.
As such I don't think the title for the paragraph makes sense.

e)  Step 10, Do we need to be explicit that the MSK return must be encrypted
somehow?  Based on the conversations last week there appears to be a problem
in that while RADIUS has the ability to return encrypted responses, it is
not native to Diameter.  Also does this need to be a new attribute or does
the attribute already exist (in both systems).  Is the sentence at the end
of the paragraph wrong?  Is it returned to the subject (not covered by the
title) or the RP?  The subject should already have the MSK 

f) I don't understand part of step 11 --  It may have information that leads
it to make additional attribute queries.  I can see it needing to make
additional attributes because it needs more information, but not because it
has the information it needs.

12. In your diagram, the (11) should be in the RP column.

13. Section 2 - What is this "end host" that is referred to in the second
paragraph?  Is this the IdP, the subject or some new entity.  - Getting all
of these names straight without having a glossary is going to kill me
eventually.''

s/connumication/communication/

14. Section 2.1.1 - discovery --- I don't know that I don't have a slight
problem with the first sentence in this section.   If you are going to tell
me that I need to properly identify the end points of the communication,
then I want to see more details on what is considered to be proper here.
For one thing, I assume that this identification is only true as far as the
AAA substrate is concerned.  This means that asking for a service at a realm
would be considered to be sufficient as oppose to having to know who is
providing the service.  (i.e. I want some [email-masked] as oppose to a
specific one.  It might be that additional restrictions are required for a
type of idp, but that is not covered here.).

How much of the rules determination is to be done by the RP and how much by
the AAA substrate?  

Looking at para 3 - I am wondering if sentence two should be stated as "One
of these is whether the given RP is permitted to rely on the IDP using a
given federation at all,...".   The question is one of does the RP trust the
IdP as oppose to does the IdP allow the RP to talk to it.  The rules
determination is going to be done differently for the two sides.

For the AAA Proxy - the last sentence needs to be motivated.  I can see
flooding routing information but the reason for doing name constraints
escapes me at the moment.

s/support e Simple/support the Simple/

15.  Section 2.3 - Application to Service -- This section discusses the use
of GSS-API, however I believe that it also needs to include a discussion of
the channel that is to be used between the application and the server as
this is not an implicit part of the GSS-API system.  This channel may have
some specific requirements that need to be discussed as well. 

16. Section 2.4 - I don't understand the title of this section.   What does
this have to do with personalization?  Perhaps Attribute or similar word
would be better than personalization.  A look forward in this section to the
one on privacy might be indicated as this would be a good location to talk
about the issues of what information should be released from the IdP to the
RP and how much it should be under the control of the federation agreement
and how much under the control the subject.

17.  Section 2.5 - what  happened to the text in this section?

18.  Should the section on privacy - i.e. talking about privacy,
untraceability, anonymity and so forth be part of section 2?  I think that
discussion this in the context of the architecture and what the requirements
on each section of the architecture are going to be makes sense to me.

19 - section 3.1 - I would suggest a new title as it would be good to
suggest who is being mutually authenticated -- yet another name for somebody
- who are the initiator and the acceptor

Please expand on the difference between bullets 1 and 2 in this section.  It
appears to me that the first sentence in both sections are saying the same
thing - that the initiator trusts that the name it has given for the target
name/acceptor correctly names and describes the acceptor.  If there is a
difference in these concepts I for one don't understand it from the text.

20 - section 3.3 - In the next to last paragraph, would host names work
better in the case that secure SRV records w/ DNSSEC are used?   I also do
not understand how to resolve the decision in paragraph two to say we need
to use realm names, but the last paragraph says that we need to support
host-based service names.   How am I supposed to reconcile these
differences.  Also does it make a difference in how the channel to the
service is created?  I.e. it makes much more sense to use host-based server
names if one is using TLS as the channel between the application and the
channel, but how the RP decides which IdP or federation to use is not going
to be based on host-based service names.  I guess part of my question is
going to be is naming different for the RP (from the point of view of the
client) as oppose to the naming of other entities in the system.

21 - Section 3.4 - I need to have an idea of what entities are going to be
using the GSS-API per-message security services.  There is a difference in
how I think about this if this is done between the subject and the RP as
oppose to between the RP and the IdP or the subject and the IdP.  I also
need to come to grips with how many different MSKs are going to be generated
in this system.  I don't have a good idea of this from this section.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 21 Apr 2011 17:07:13 -0400

I wonder if we can just refer to RFC 2743 for the requirements for the
channel between subject and RP?

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Tue, 26 Apr 2011 05:09:32 -0400

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

    James> 1.  Introduction para 3 - I want to make sure that your
    James> definition of federation is one that you want to make.
    James> Specifically it would appear that there can be federations
    James> even within a single entity in the event that actor providing
    James> the identity information is not the same as the RP.  Would
    James> you consider a single Kerberos or Windows enterprise to be a
    James> federation.  In these cases the IdP being the login service
    James> and the RP being somebody granting access to a resource (in
    James> windows possibly by an RPC).  I generally think of federation
    James> as being between two different entities rather than within a
    James> single entity but using multiple servers.

I tend to agree with you that a lot of problems show up in the
cross-organization case.  I think it's important to make it clear we're
signing up to that and a solution working within a single organization
is not sufficient.  I also think it would be honest to indicate we're
optimizing for the cross organization case.  I don't think we should
forbid our technology being used within a single organization nor ignore
concerns that happen when that is done.  What are your thoughts?

    James> 3. Section 1.1 - I am still AAA challenged.  Is it more
    James> correct to say 'a radius or diameter server'?  Do you want to
    James> put in a generalized statement that says you use radius but
    James> it also applies to diameter?

We're using RADIUS for the example here.  Project Moonshot is only
focusing on RADIUS, but ABFAB needs to be/people are working on making
it technology neutral.
We should clarify in the doc if is this not clear.
(And obviously there is no need to mention Moonshot's implementation
choices at all in the doc.)
    James> 10.  Possible issue to include here.  In the presence of
    James> multiple federations, the naming of individuals can become
    James> murky especially if one is trying to associate a single
    James> individual from different federations.  Asking a question
    James> such as does John Doe belong to an IdP (in the absence of
    James> authentication) may get an answer for the wrong John Doe.

Yes.
This is worth mentioning in my opinion.

    James> 11.  Section 1.4 - Overview a) I think you might need to have
    James> a step 2a - Client Application creates a channel to the RP.
    James> This is not done by the GSS-EAP mechanism as I had originally
    James> assumed.  Let's make it clear additionally that fact will be
    James> needed in order to setup the channel binding at a later time.

    James>  b) in step 5 either /forward a RADIUS request/ or /forward
    James> RADIUS requests/.  AAA ignorance - would message be better
    James> than request to avoid confusion between RADISU request and
    James> GSS/EAP request?  - 

I think RADIUS message would be OK. The particular type of message is
called a request, but we don't need to say that.

    James> I would ignore how the SAML request is
    James> encoded at this point.  So maybe s/SAML request as a series
    James> of attributes/ SAML request for a set of attributes/ s/.././

I'd personally just leave it as SAML request.
After talking to Rhys and Josh about what you can and cannot do with
various types of SAML requests it is better not to get into details
here.

    James> c) request that you go back and use subject rather than
    James> principal in this section.  The change in terminology is not
    James> introduced.

OK.

    James> d) in step 9, I think I have a problem with the last
    James> sentence.  These policy checks would have been done by the
    James> AAA system or the RP and not by the IdP.  As such I don't
    James> think the title for the paragraph makes sense.
No, I think the IDP makes these checks as well.

Consider  the PLASMA example.
An IDP may well know exactly who its organization permits to be a PLASMA
policy point and may forbid others from providing that service.
Some IDPs will have very open policy here; some will not.

I agree that the AAA and RP may also apply policy.

    James> e) Step 10, Do we need to be explicit that the MSK return
    James> must be encrypted somehow?  Based on the conversations last
    James> week there appears to be a problem in that while RADIUS has
    James> the ability to return encrypted responses, it is not native
    James> to Diameter.  Also does this need to be a new attribute or
    James> does the attribute already exist (in both systems).  

AAA keywrap is probably not something we want to go into here.
There are a lot of AAA deployments where the attribute is not encrypted
at all.
I think in our mechanism document we want to make support for encryption
mandatory  in the GSS acceptor. I think our BCPs we definitely want to
make support for implementing this attribute mandatory.
I don't think we want to go into that detail here, although if someone
provided text discussing the issue for elsewhere in the document that
would be good.

    James> Is the
    James> sentence at the end of the paragraph wrong?  Is it returned
    James> to the subject (not covered by the title) or the RP?  The
    James> subject should already have the MSK

Here it is returned to the RP; the subject definitely already has it.

    James> f) I don't understand part of step 11 -- It may have
    James> information that leads it to make additional attribute
    James> queries.  I can see it needing to make additional attributes
    James> because it needs more information, but not because it has the
    James> information it needs.
I agree with your confusion but don't know what was intended here.

    James> 13. Section 2 - What is this "end host" that is referred to
    James> in the second paragraph?  Is this the IdP, the subject or
    James> some new entity.  - Getting all of these names straight
    James> without having a glossary is going to kill me eventually.''

The subject.
I think end-host probably wants to get collapsed into subject.

    James> s/connumication/communication/

    James> 14. Section 2.1.1 - discovery --- I don't know that I don't
    James> have a slight problem with the first sentence in this
    James> section.  If you are going to tell me that I need to properly
    James> identify the end points of the communication, 
    James> then I want to
    James> see more details on what is considered to be proper here.
    James> For one thing, I assume that this identification is only true
    James> as far as the AAA substrate is concerned.  This means that
    James> asking for a service at a realm would be considered to be
    James> sufficient as oppose to having to know who is providing the
    James> service.  (i.e. I want some [email-masked] as oppose to a
    James> specific one.  It might be that additional restrictions are
    James> required for a type of idp, but that is not covered here.).

The following sentences attempt to clarify.
The realm portion of a NAI identifies a conceptual endpoint for sending
a request in AAA.
Identifying the endpoint making the request is more complex; how that is
handled kind of depends on the specific technical trust mechanism in
play.

    James> How much of the rules determination is to be done by the RP
    James> and how much by the AAA substrate?

This is probably an implementation detail.
An RP that has multiple places it can start in the AAA substrate needs
to pick one.
However conceptually you can think of that combination as an RP plus AAA
proxy (possibly all within one process) so I think this is an
implementation matter.

    James> Looking at para 3 - I am wondering if sentence two should be
    James> stated as "One of these is whether the given RP is permitted
    James> to rely on the IDP using a given federation at all,...".  The
    James> question is one of does the RP trust the IdP as oppose to
    James> does the IdP allow the RP to talk to it.  The rules
    James> determination is going to be done differently for the two
    James> sides.

I think either party can decide not to talk to the other party.
The use case motivating that sentence was explicitly a case where an IDP
was selective in what RPs it permitted and where a federation did not
allow all RPs to talk to all IDPs, not the case where the RP had a
trust decision to make.
Obviously, though, both parties may need to decide something.

    James> For the AAA Proxy - the last sentence needs to be motivated.
    James> I can see flooding routing information but the reason for
    James> doing name constraints escapes me at the moment.

Routing information in an AAA fabric is effectively name constraints in
both directions. "This way for FOO.COM!" "Messages coming from that
direction can claim RPs in realms A, B, C and D!"

    James> 15.  Section 2.3 - Application to Service -- This section
    James> discusses the use of GSS-API, however I believe that it also
    James> needs to include a discussion of the channel that is to be
    James> used between the application and the server as this is not an
    James> implicit part of the GSS-API system.  This channel may have
    James> some specific requirements that need to be discussed as well.

I'd really need to see text here, because I don't know what we'd want to
say about the channel.

    James> 16. Section 2.4 - I don't understand the title of this
    James> section.  What does this have to do with personalization?
    James> Perhaps Attribute or similar word would be better than
    James> personalization.  A look forward in this section to the one
    James> on privacy might be indicated as this would be a good
    James> location to talk about the issues of what information should
    James> be released from the IdP to the RP and how much it should be
    James> under the control of the federation agreement and how much
    James> under the control the subject.

I would be fine with both of these changes.

    James> 17.  Section 2.5 - what happened to the text in this section?

I don't know. Did it ever have text?

    James> 19 - section 3.1 - I would suggest a new title as it would be
    James> good to suggest who is being mutually authenticated -- yet
    James> another name for somebody - who are the initiator and the
    James> acceptor

Section 3 is all about GSS-API, which only has two endpoints, so I don't
 see any other options than these two endpoints.

initiator is the GSS name for subject; acceptor is the GSS name for RP.

    James> Please expand on the difference between bullets 1 and 2 in
    James> this section.  It appears to me that the first sentence in
    James> both sections are saying the same thing - that the initiator
    James> trusts that the name it has given for the target
    James> name/acceptor correctly names and describes the acceptor.  If
    James> there is a difference in these concepts I for one don't
    James> understand it from the text.

The second bullet covers the case where the initiator does not supply a
 target name.
I'd be happy to add a sentence to the second bullet that the second
 bullet is a subset of the first when a target name is provided or
 otherwise clarify.

    James> 20 - section 3.3 - In the next to last paragraph, would host
    James> names work better in the case that secure SRV records w/
    James> DNSSEC are used?  

If you were willing to trust DNS both on the initiator and the RP  and
do some work on how applications handle these names, you could improve
the situation.
To me, it seems a big assumption to assume that your application
authentication trust and your DNS trust are aligned, especially when
you'd need to make that assumptions on both sides of a federation.
It's true sometimes and possibly enough of the time to support, but not
enough of the time to rely on.

    James> I also do not understand how to resolve the
    James> decision in paragraph two to say we need to use realm names,
    James> but the last paragraph says that we need to support
    James> host-based service names.  How am I supposed to reconcile
    James> these differences.  

Putting hosts into a realms is a mechanism for more easily supporting
host names.
There is more detail on this in the actual mechanism document.

    James> Also does it make a difference in how the
    James> channel to the service is created?  I.e. it makes much more
    James> sense to use host-based server names if one is using TLS as
    James> the channel between the application and the channel, but how
    James> the RP decides which IdP or federation to use is not going to
    James> be based on host-based service names.  I guess part of my
    James> question is going to be is naming different for the RP (from
    James> the point of view of the client) as oppose to the naming of
    James> other entities in the system.

This section is discussing support for host-based names of GSS
acceptors.  At least as described currently an IDP is not a GSS
acceptor.  In the KMP presentation we gave in Prague, we proposed
creating a GSS acceptor service associated with an IDP, but that is not
discussed at all in this document.

    James> 21 - Section 3.4 - I need to have an idea of what entities
    James> are going to be using the GSS-API per-message security
    James> services.  There is a difference in how I think about this if
    James> this is done between the subject and the RP as oppose to
    James> between the RP and the IdP or the subject and the IdP.  I
    James> also need to come to grips with how many different MSKs are
    James> going to be generated in this system.  I don't have a good
    James> idea of this from this section.

GSS initiator and acceptor use the per-message services. I.E. the IDP
and RP.
Only one MSK in the entire system.

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

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 26 Apr 2011 22:05:01 -0700

> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]]
> Sent: Tuesday, April 26, 2011 2:10 AM
> To: James Schaad
> Cc: [email-masked]; 'Eliot Lear'
> Subject: Re: [abfab] Comments on draft-lear-abfab-arch-02
> 
> I tend to agree with you that a lot of problems show up in the cross-
> organization case.  I think it's important to make it clear we're signing
up to
> that and a solution working within a single organization is not
sufficient.  I also
> think it would be honest to indicate we're optimizing for the cross
> organization case.  I don't think we should forbid our technology being
used
> within a single organization nor ignore concerns that happen when that is
> done.  What are your thoughts?
> 

I don't have a problem with a focus on cross-organization cases, I think
that is where this document should be focused.  I was actually trying to
drive at the question of the definition of what a 'federation' was and
trying to determine if the one given was both a good one and a viable one.
That is a federation is a relationship that defines 'technical signaling,
trust and a common understanding of semantics between the RP and IdP'.
Nothing in this definition rules out federation within an organization.  In
that case the second two element should be easy leaving only the first as a
problem.   The question was more one of is the definition as given
potentially so broad as to eliminate, for some people, the concept that a
single organization has the elements of a federation within it.  The comment
was more intended to make you think that to say what is there is wrong.

> focusing on RADIUS, but ABFAB needs to be/people are working on making it
> technology neutral.

No - you have defined the components of an IdP and did not include Diameter
as an option.  I think that it needs to be included as part of what an IdP
consists of.  I think that it would be perfectly acceptable to put a
paragraph in here that says "In all places where Radius is used, Diameter
could also be used unless otherwise stated."

> I think RADIUS message would be OK. The particular type of message is
called
> a request, but we don't need to say that.

Please change just to eliminate the redundancy.  After re-reading this
paragraph I think that the term forward should be replaced with send.  The
RP 'sends' rather than 'forwards' the RADIUS message as it conceptually
creates the RADIUS request for the IdP.

> After talking to Rhys and Josh about what you can and cannot do with
various
> types of SAML requests it is better not to get into details here.

I agree - better is s/SAML request as a series of attributes/SAML request/

> No, I think the IDP makes these checks as well.

I am not saying that the IdP does not make the policy checks.  I am
referring to the "Additional policy checks" in the last sentence.  Including
this here rather than in the discovery process makes the paragraph title
problematic.   However I do not need a change here.

> There are a lot of AAA deployments where the attribute is not encrypted at
> all.
make
> support for implementing this attribute mandatory.
would
> be good.

I can live with this not being covered.  It may want to go into something
marked security considerations just to make sure it is not lost.  How the
encryption is done is going to be highly variable, in that I agree.

> I think end-host probably wants to get collapsed into subject.

Sounds good.  As stated the fact that there are multiple names but not a
table of those names in the different protocols is confusing.  Actually
adding that table would probably be both an interesting exercise as well as
making a good single point of reference.

> The realm portion of a NAI identifies a conceptual endpoint for sending a
> request in AAA.
> handled kind of depends on the specific technical trust mechanism in play.
> 

Yes I think that flows better.

> An RP that has multiple places it can start in the AAA substrate needs to
pick
> one.
implementation
> matter.

I agree that it does not need to be covered in this case.

> The use case motivating that sentence was explicitly a case where an IDP
was
> selective in what RPs it permitted and where a federation did not allow
all
> RPs to talk to all IDPs, not the case where the RP had a trust decision to
> make.

>From the text in place, I think that it states just the opposite.  I.e. can
an RP rely on the IdP.  I would assume that the IdP would actually do its
own rules determination rather than rely on anything supplied by the RP
except as one input to the IdP rules determination process.  A such the
rules used by the IdP are covered elsewhere?

> Routing information in an AAA fabric is effectively name constraints in
both
> directions. "This way for FOO.COM!" "Messages coming from that direction
> can claim RPs in realms A, B, C and D!"

How about s/flood naming constraints to/flood naming constraints on routed
traffic to/  I think this would make it more clear what you are talking
about.

> I'd really need to see text here, because I don't know what we'd want to
say
> about the channel.

Well I guess the first question is if any channel that is used needs to
support channel binding?  Also I think that it might be necessary to state
that if protocols want a more definitive statement on who the RP is, then
this needs to be provided by the channel (actually I am not sure that is the
case).  There are questions about privacy on the information setup prior to
the GSS-EAP mechanism being setup as well as authentication.  These may be
requirements of the channel.  I am not sure at this point what all is needed
here. 

> I don't know. Did it ever have text?

I have no idea.  For all I know that section exists just to hold the picture
which is odd.  If it needs text then it needs to be supplied.

> Section 3 is all about GSS-API, which only has two endpoints, so I don't
see
> any other options than these two endpoints.
> 

Ok - either the table of names or a sentence saying 'Mutual authentication
occurs between the subject and the RP." Would both address my problem.

> I'd be happy to add a sentence to the second bullet that the second
bullet is
> a subset of the first when a target name is provided or  otherwise
clarify.

Sounds good

> If you were willing to trust DNS both on the initiator and the RP  and do
some
> work on how applications handle these names, you could improve the
> situation.
> authentication trust and your DNS trust are aligned, especially when you'd
> need to make that assumptions on both sides of a federation.

It might make sense to change s/other insecure referrals/other referrals/
since in these cases the referrals would be assumed not to be AAA referrals.

> Putting hosts into a realms is a mechanism for more easily supporting host
> names.

Ok - will read that document again.

> This section is discussing support for host-based names of GSS acceptors.
At
> least as described currently an IDP is not a GSS acceptor.  In the KMP
> presentation we gave in Prague, we proposed creating a GSS acceptor
> service associated with an IDP, but that is not discussed at all in this
> document.

I was more worried about the problems that the client had doing the
comparison between what the RP gave to the IdP and what the RP gave to the
client as a proper name rather than what the GSS acceptor was using.

> GSS initiator and acceptor use the per-message services. I.E. the IDP and
RP.
> Only one MSK in the entire system.

Is there a GSS key between the client and the RP before the EAP has
finished?  At what point do messages between the client and the RP become
protected w/o the use of a channel which is independently providing
protection.

Jim

---

From: Sam Hartman <[email-masked]>
Date: Wed, 27 Apr 2011 07:16:16 -0400

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

    James> Also does it make a difference in how the channel to the
    James> service is created?  I.e. it makes much more sense to use
    James> host-based server names if one is using TLS as the channel
    James> between the application and the channel, but how the RP
    James> decides which IdP or federation to use is not going to be
    James> based on host-based service names.  I guess part of my
    James> question is going to be is naming different for the RP (from
    James> the point of view of the client) as oppose to the naming of
    James> other entities in the system.
    >> acceptors.
    Jim> At
    >> least as described currently an IDP is not a GSS acceptor.  In
    >> the KMP presentation we gave in Prague, we proposed creating a
    >> GSS acceptor service associated with an IDP, but that is not

    Jim> I was more worried about the problems that the client had doing
    Jim> the comparison between what the RP gave to the IdP and what the
    Jim> RP gave to the client as a proper name rather than what the GSS
    Jim> acceptor was using.

It's actually the IDP that does this.
The client gives its idea of GSS acceptor name to the IDP; the RP gives
its idea of the GSS acceptor name to the IDP.

In a typical deployment, I'm expecting that some AAA proxy close to the
acceptor would verify that the acceptor is authorized to claim whatever
host name it actually claims.  I'm imagining that the border proxy
between the IDP's realm and the acceptor's realm (in a RADSEC style
deployment where these entities speak directly) would confirm that the
RP is from the realm it claims and that realm is permitted to claim the
hostname that the acceptor claimed.
This leaves the IDP it self doing a binary comparison of the channel
binding attributes the client/subject sent to the ones from the RP.
Any attribute sent by the client must be present in the RP set and must
compare identically.

This all needs to be spelled out: the proxy behavior sections need to be
written.  I think the IDP behavior is spelled out in the mechanism
document.

    >> GSS initiator and acceptor use the per-message services. I.E. the
    Jim> RP.

Is there a GSS key between the client and the RP before the EAP has
    Jim> finished?  At what point do messages between the client and the
    Jim> RP become protected w/o the use of a channel which is
    Jim> independently providing protection.

There is not a key before EAP generates one; typically the RP doesn't
learn this key until eap succeeds.

Unless we choose to introduce a DH exchange or the like, then things
between the initiator  and RP are not protected until eap succeeds.
Currently the only things sent there are:

* the EAP conversation
* Initiator's request for RP name or initiator's indication of what RP
   name it is using
* The mutual authentication flag that we need to MIC

All of these things would go in the clear in something like TLS.

In terms of channel attributes.

There are a couple of basic approaches you could use.

The GS2 approach is that you never use per-message services, you use a
protected channel if you care about security and you perform channel
binding.

Contrast this with say the approach used by the  Kerberos administration
service. There  the channel is never protected, but gss_wrap is used to
protect every message.
In this model really you need very little from the channel.

I think explicitly describing these two models might help; what do you
think?

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 28 Apr 2011 18:58:42 -0700

> Sent: Wednesday, April 27, 2011 4:16 AM
> To: Jim Schaad
its idea
> of the GSS acceptor name to the IDP.
> 
host
> name it actually claims.  I'm imagining that the border proxy between the
> IDP's realm and the acceptor's realm (in a RADSEC style deployment where
> these entities speak directly) would confirm that the RP is from the realm
it
> claims and that realm is permitted to claim the hostname that the acceptor
> claimed.
binding
> attributes the client/subject sent to the ones from the RP.
document.

Ok - so we have here an even more important case to say that the channel
between the client and the RP needs to have channel binding.  Since we don't
have the channel binding data for the IdP to compare unless the channel is
going to produce it.  There is no channel binding data from the GSS-EAP
mechanism until the MSK is created.   This would not be an issue if we were
comparing text names, but then we have the issue of the difference between
the DNS name used by the client and the AAAA realm name used by the RP.

However this is leaving me confused about what the acceptor name form and
value(s)(?) are supposed to be.   I need to go back and review again what
the form of the name you had on the screen was so that I can look for the
different fields.

> There is not a key before EAP generates one; typically the RP doesn't
learn
> this key until eap succeeds.

Ok - this is what I thought.  Any other keys would come from the channel
being used.

> All of these things would go in the clear in something like TLS.

?? in the clear in or in the clear or ??

think?

Yes I think that this would be useful as two extremes.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 29 Apr 2011 07:04:29 -0400

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

It's absolutely critical for mutual authentication that we have EAP
channel binding. That goes between  the peer/initiator/subject and the
IDP/EAP server.
That is independent of GSS channel binding which goes between the
initiator/subject/peer and the RP/acceptor.

    Jim>     Jim> Since we don't have the channel binding data for the IdP to
    Jim> compare unless the channel is going to produce it.  There is no
    Jim> channel binding data from the GSS-EAP mechanism until the MSK
    Jim> is created.  This would not be an issue if we were comparing
    Jim> text names, but then we have the issue of the difference
    Jim> between the DNS name used by the client and the AAAA realm name
    Jim> used by the RP.

OK, so we also have confusion about channels.  EAP channel binding
describes properties of the EAP lower layer--in our case the GSS
exchange.  The attributes we care about with regard to this channel are
(at least so far) the acceptor name.

The other channel, over which we apply GSS channel binding, is between
the subject and RP. That's the channel that might be TLS.  There', the
attributes we care about are things like the server certificate or the
hash of the finish messages.

GSS and EAP channel binding are even more different than is implied so
far.  It's not just that the channel is different and the attributes
we're talking about are different.  GSS channel binding is intended to
detect a man-in-the-middle attack.  EAP channel binding does make sure
that both ends of a connection have a consistent idea of naming.
However it's not really about detecting man in the middle attacks, but
more about maintaining consistency in a complex multi-party system.

Continual apologies for the terminology confusion. The EAP and GSS
communities independently came up with the term channel binding and
didn't realize the conflict until it was well established in both
communities.

--Sam