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
ii) Section 1.1.1
Authenticator should be defined before it is used.
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.
Editorials
Section 1
the Relying Party know specific -> the Relying Party to know specific
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"
Section 1.4
a SAML Attribute Requests -> a SAML Attribute Request
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
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
