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