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