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

[David Chadwick <[e-mail]>]

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