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

["Jim Schaad" <[e-mail]>]

> -----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
> >