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

Rafa Marin Lopez <rafa@um.es> Tue, 01 October 2013 08:11 UTC

Return-Path: <rafa@um.es>
X-Original-To: abfab@ietfa.amsl.com
Delivered-To: abfab@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3BF21F9B86 for <abfab@ietfa.amsl.com>; Tue, 1 Oct 2013 01:11:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnrsLjc95vnT for <abfab@ietfa.amsl.com>; Tue, 1 Oct 2013 01:11:51 -0700 (PDT)
Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 8F59B21F8FF5 for <abfab@ietf.org>; Tue, 1 Oct 2013 01:11:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id 58E925D4F9; Tue, 1 Oct 2013 10:11:47 +0200 (CEST)
X-Virus-Scanned: by antispam in UMU at xenon14.um.es
Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id sHL7kOrPcfh5; Tue, 1 Oct 2013 10:11:46 +0200 (CEST)
Received: from [192.168.1.67] (167.Red-83-42-219.dynamicIP.rima-tde.net [83.42.219.167]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon14.um.es (Postfix) with ESMTPSA id 2B2985D4F1; Tue, 1 Oct 2013 10:11:44 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="iso-8859-1"
From: Rafa Marin Lopez <rafa@um.es>
In-Reply-To: <4C04F0D0-6105-448A-82EF-C62F6392F828@cisco.com>
Date: Tue, 01 Oct 2013 10:11:44 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <B9177EDA-74D4-46E3-9CBC-030595CDA5F7@um.es>
References: <tsl61ug7n72.fsf@mit.edu> <052301ceb814$54e4caa0$feae5fe0$@augustcellars.com> <523FE430.4040106@kent.ac.uk> <01ee01cebba0$2dc575c0$89506140$@augustcellars.com>, <5246C6B1.9030500@kent.ac.uk> <4C04F0D0-6105-448A-82EF-C62F6392F828@cisco.com>
To: Klaas Wierenga <kwiereng@cisco.com>
X-Mailer: Apple Mail (2.1283)
Cc: abfab@ietf.org
Subject: Re: [abfab] [Sam Hartman] comments on draft-ietf-abfab-arch
X-BeenThere: abfab@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" <abfab.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/abfab>, <mailto:abfab-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/abfab>
List-Post: <mailto:abfab@ietf.org>
List-Help: <mailto:abfab-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/abfab>, <mailto:abfab-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Oct 2013 08:11:56 -0000

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" <d.w.chadwick@kent.ac.uk> 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:d.w.chadwick@kent.ac.uk]
>>>> Sent: Sunday, September 22, 2013 11:48 PM
>>>> To: Jim Schaad
>>>> Cc: 'Sam Hartman'; abfab@ietf.org
>>>> 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: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On
>>>>>> Behalf Of Sam Hartman
>>>>>> Sent: Wednesday, September 04, 2013 6:04 AM
>>>>>> To: abfab@ietf.org
>>>>>> Subject: [abfab] [Sam Hartman] comments on draft-ietf-abfab-arch
>>>>>> 
>>>>>> Sent from wrong address.
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> abfab mailing list
>>>>> abfab@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/abfab
>> _______________________________________________
>> abfab mailing list
>> abfab@ietf.org
>> https://www.ietf.org/mailman/listinfo/abfab
> _______________________________________________
> abfab mailing list
> abfab@ietf.org
> 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: rafa@um.es
-------------------------------------------------------