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

[David Chadwick <[e-mail]>]

I would be interested in giving a presentation about this, but 
unfortunately I cannot attend the next IETF meeting as it clashes with 
Openstack in Honk Kong (where I am also giving a presentation on 
Federation). But the first meeting next year could be suitable

regards
David

On 29/09/2013 00:34, Jim Schaad wrote:
>   A BOF just to discuss the problem without some idea of a solution would
> probably not be very productive.
>
> I don't think that this problem is restricted to just ABFAB - I think that
> it is of interest to other groups and would therefore be reluctant to do
> more than a preliminary discussion in the ABFAB group to see if we even
> agree on the problem.
>
> I would suggest you ask the ABFAB chairs if there is room for some type of
> presentation if you are interested in doing a short presentation of what you
> see as the problem space and why it is not an easy solution.  I have added
> Trevor because I think that he would be interested in discussing this in the
> context of the Plasma work.
>
> Jim
>
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>> David Chadwick
>> Sent: Saturday, September 28, 2013 5:08 AM
>> To: Jim Schaad
>> Cc: [e-mail]; 'Sam Hartman'
>> Subject: Re: [abfab] [Sam Hartman] comments on draft-ietf-abfab-arch
>>
>> 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
>>>>>
>>>
>> _______________________________________________
>> abfab mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/abfab
>