Re: [abfab] [Sam Hartman] comments on draft-ietf-abfab-arch

[David Chadwick <[e-mail]>]

Hi Jim

thankyou for your long answer. Firstly I agree that the answer is not 
trivial, especially once you consider that an SP may require attributes 
from multiple IdPs/AAs. But leaving attribute aggregation aside, lets 
discuss conceptually what is needed in the simple single IDP case, 
before trying to figure out how to map this into the ABFAB protocols.

1. The SP is the only entity that knows which attributes are needed to 
access which of its services
2. The SP may not know this at the time of authn, as the user may not 
have chosen the service he wants to access at login time (assuming the 
SP has multiple services requiring different authz attributes).
3. If the user moves between the different services of the SP, using 
SSO, then different attributes may be needed at different times during 
the same authn session
4. DP legislation indicates that the SP should minimise the attributes 
it asks for, so a "grab them all" approach at authn time is not in the 
spirit of DP, and may be illegal in some juridictions
5. This indicates to me that the SP should be able to send its attribute 
requirements (or authz policy) to the IdP at arbitrary points in time 
during the user's session, and that the IDP should be able to send back 
attribute assertions that match the policy whenever requested to, 
providing that the user consents to this (and the IDP knows that the 
user has).

Is this challenge something the ABFAB group would like to take on, or 
should there be a BOF at a future IETF meeting to discuss this?

regards

David

On 27/09/2013 17:39, Jim Schaad wrote:
>
>
>> -----Original Message-----
>> From: David Chadwick [mailto:[e-mail]]
>> Sent: Sunday, September 22, 2013 11:48 PM
>> To: Jim Schaad
>> Cc: 'Sam Hartman'; [e-mail]
>> Subject: Re: [abfab] [Sam Hartman] comments on draft-ietf-abfab-arch
>>
>> Apologies from me as well Sam, here are my comments on draft-ietf-abfab-
>> arch-07.txt
>>
>> Technical
>>
>> Section 1.
>> i) Data Minimization and User Participation: "There is currently no direct
> client
>> participation in this decision." (i.e. release of identity attributes). We
> should
>> say at this juncture that this is a major deficiency in existing federated
>> systems, since the user does not have full consent or control over which
> of his
>> identity attributes are released. This should be fixed in Abfab
>
> Based on the current set of abilities, there is no real way to fix this in
> ABFAB itself.  I have thought of a proposed way to deal with this, but am
> unsure where it would be bested addressed or even what the solution to the
> problem would include.
>
> If I was solving this today, I would define a couple of experimental items
> in the TEAP protocol to allow for this to be done, however given that this
> would definitely be experimental and the fact that the EMU group is trying
> to go away it is not clear that this would be the group to do it.  I don't
> think that ABFAB is really the place to do it either.  I think that there
> needs to be some clear discussions about how this should be attacked as a
> problem before we even think about it.  In some instances it is not clear
> that that is any solution to the problem, such as when a SAML request goes
> from the server to the IDP after the EAP authentication has been completed.
> The only thing that could be possible in this case is for a profile to be
> agreed on by the client and the IDP at the authentication time and for the
> IDP to enforce it at a later time.
>
> Given how unclear a solution would be for this I don't see any reason to
> hold this document up over the fact that the ability for the user to fully
> consent does not exist.  This has always been the case for RADIUS and
> Diameter as well.
>
> We can potentially strengthen the language that is present, although I don't
> really see any need to do that either.  At present I do not plan to make any
> changes to address this issue.
>
>>
>> ii) Section 1.1.1
>> Authenticator should be defined before it is used.
>
> This has been fixed.
>
>>
>> iii) I dont buy into your whiteboard example of single entity
> authentication,
>> because a hacked whiteboard could trick the user into opening the wrong
> file,
>> which could be disasterous during an important business meeting. SO mutual
>> authentication is needed here as well. If you want an example where mutual
>> authentication is not important, its one where either the information
> being
>> accessed is of very little value to the accessor so that it does not
> matter if it is
>> erroneous information or not, or one where it does not matter who the
>> accessor is i.e. its public information.
>
> I don't see how having mutual authentication is going to solve anything in
> the case of a hacked whiteboard getting the user to display the wrong file
> or stealing credentials from the user in the case that it the initiator.
> There would be no issue of the file server releasing the file to the
> whiteboard if authorized by the user in all cases.  The only question would
> be if the file server decided based on the name of the whiteboard that it
> should not be released, but it would be the user that is authenticated in
> this case and not the whiteboard so there would not be mutual authentication
> between the file server and the whiteboard in any case.
>
> I will send to the list updated text on this.  After a brief exchange with
> Sam I believe this has some errors in it that need to be clarified.
>
>>
>>
>>
>> Editorials
>>
>> Section 1
>> the Relying Party know specific -> the Relying Party to know specific
> Fixed
>
>>
>> Section 1.1
>> the document uses either a the ABFAB term -> the document uses either the
>> ABFAB term The table should be labelled "Table 1. Terminology"
> Fixed
>
>>
>> Section 1.4
>> a SAML Attribute Requests -> a SAML Attribute Request
> Fixed
>
>>
>> Section 2.1.3
>> to validate theg identities -> to validate the identities The trust
> mechanism
>> must to ensure that -> The trust mechanism must ensure that An RP can
>> submit a request directly to a federation. -> An RP can submit a request
>> directly to the correct federation.
>> information about given a IdP -> information about a given IdP
>
> Fixed
>
>>
>> regards
>>
>> David
>>
>> On 23/09/2013 05:21, Jim Schaad wrote:
>>> My apologies for not getting these out in last call.
>>> One of these (the re-authentication section comment) is serious enough
>>> that I believe it needs to be resolved prior to sending the document on.
>>>
>>>
>>> Section 1.1.1
>>>
>>> old: Typically when considering channel binding
>>>
>>> new:
>>>
>>> Typicially when considering both EAP and GSS-API channel binding
>>>
>>> [JLS] done
>>>
>>> Later in the white board example
>>> channel binding should be GSS-API channel binding
>>>
>>> [JLS]  I don't understand this.   The two sentences which talk about the
>>> whiteboard do not have the phrase channel binding in them.  The next
>>> sentence would seem to apply to either GSS-API or EAP channel binding.
>>> Which sentence did you think should be changed?
>>>
>>> Section 2.3.3
>>>
>>> This is unlikely to survive IETF last call unchallenged.
>>>
>>> [JLS] Quite correct - this should say - please present your
>>> authentication token
>>>
>>> ...
>>>
>>>             <t>
>>>               There are circumstances where the server will want to
>>> have the client re-authenticate itself.
>>>               These include very long sessions, where the original
>>> authentication is time limited or cases where in order to complete an
>>> operation a different authentication is required.
>>>               GSS-EAP does not have any mechanism for the server to
>>> initiate a re-authentication as all authentication operation start from
> the
>> client.
>>>               If a protocol using GSS-EAP needs to support
>>> re-authentication that is initiated by the server, then a request from
>>> the server to the client for the re-authentication to start needs to
>>> be placed in the protocol.
>>>             </t>
>>>             <t>
>>>               Clients can re-use the existing secure connection
>>> established by GSS-API to run the new authentication in by calling
>> GSS_Init_sec_context.
>>>               At this point a full re-authentication will be done.
>>>             </t>
>>>
>>> What do you think needs to be added to this?
>>>
>>> Section 3.4
>>>
>>> old: shared private key
>>> new: shared session key
>>>
>>> [JLS] - Fixed
>>>
>>> Section 2.2.2 refers to sectian 6.1 for a description of GSS-API
>>> channel binding; that seems wrong
>>>
>>> [JLS] Section 6 has disappeared - so I am killing that portion of the
>>> section.
>>>
>>>> -----Original Message-----
>>>> From: [e-mail] [mailto:[e-mail]] On
>>>> Behalf Of Sam Hartman
>>>> Sent: Wednesday, September 04, 2013 6:04 AM
>>>> To: [e-mail]
>>>> Subject: [abfab] [Sam Hartman] comments on draft-ietf-abfab-arch
>>>>
>>>> Sent from wrong address.
>>>>
>>>
>>>
>>> _______________________________________________
>>> abfab mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/abfab
>>>
>