Hi Klaas, David: I think all these aspects are really interesting and worthy of studying them. As you say, Klaas, I agree that finishing first current charter is the best way to go for now. In any case, I would be happy to contribute somehow in this topic in a rechartered ABFAB or a new WG.
Best Regards. El 29/09/2013, a las 09:12, Klaas Wierenga (kwiereng) escribió: > Hi David, > >> On 28 sep. 2013, at 14:08, "David Chadwick" <[email protected]> wrote: >> >> 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). > > I believe these are all fair statements and indicative of where we want > federated identity systems to be eventually. At the same time, I think this > is beyond the current scope of ABFAB. > >> 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? > > With my chair hat on I'd say let's finish the current set of documents and > not let the scope creep. Having said that, once we are done I'd welcome a > discussion on how to address valid concerns about user consent and privacy, > whether that would lead to concrete ideas and/or a WG (a rechartered ABFAB or > new doesn't really matter to me). > > Klaas > >> >> regards >> >> David >> >>> On 27/09/2013 17:39, Jim Schaad wrote: >>> >>> >>>> -----Original Message----- >>>> From: David Chadwick [mailto:[email protected]] >>>> Sent: Sunday, September 22, 2013 11:48 PM >>>> To: Jim Schaad >>>> Cc: 'Sam Hartman'; [email protected] >>>> 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: [email protected] [mailto:[email protected]] On >>>>>> Behalf Of Sam Hartman >>>>>> Sent: Wednesday, September 04, 2013 6:04 AM >>>>>> To: [email protected] >>>>>> Subject: [abfab] [Sam Hartman] comments on draft-ietf-abfab-arch >>>>>> >>>>>> Sent from wrong address. >>>>> >>>>> >>>>> _______________________________________________ >>>>> abfab mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/abfab >> _______________________________________________ >> abfab mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/abfab > _______________________________________________ > abfab mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/abfab ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: [email protected] ------------------------------------------------------- _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
