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: [email protected] [mailto:[email protected]] On Behalf Of
David Chadwick
Sent: Saturday, September 28, 2013 5:08 AM
To: Jim Schaad
Cc: [email protected]; '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:[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
