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