>>>>> "Hannes" == Hannes Tschofenig <[email protected]> writes:
Hannes> Privacy:
Hannes> Often a Relying Party does not need to know the
Hannes> identity of a Subject to reach an access management
Hannes> decision. It is frequently only necessary for the Relying
Hannes> Party know specific attributes about the subject, for
Hannes> example, that the Subject is affiliated with a particular
Hannes> organisation or has a certain role or entitlement.
Hannes> Sometimes the RP does not need to know the identity of the
Hannes> Subject, but does require a unique identifier for the
Hannes> Subject (for example, so that it can recognise the Subject
Hannes> subsequently); in this case, it is a common practise for the
Hannes> IdP to only release a pseudonym that is specific to that
Hannes> particular Relying Party. Federated access management
Hannes> therefore provides various strategies for protecting the
Hannes> Subject's privacy. Other privacy aspects typically of
Hannes> concern are the policy for releasing personal data about the
Hannes> Subject from the IdP to the RP, the purpose of the usage,
Hannes> the retention period of the data, and many more.
Hannes> This paragraph needs to be re-written to something like:
Hannes, I'd appreciate it if you would describe your concerns with the
original paragraph. From my standpoint the original paragraph does a
much better job of describing these issues from the ABFAb standpoint.
One particular concern is that I think bringing consent in without a lot more
discussion
may provide an accurate description of our hopes, but not so much of the
realities.
Hannes> Data Minimization and User Participation:
Hannes> Often a Relying Party does not need to know the
Hannes> identity of a Subject to reach an access management
Hannes> decision. It is frequently only necessary for the Relying
Hannes> Party know specific attributes about the subject, for
Hannes> example, that the Subject is affiliated with a particular
Hannes> organisation or has a certain role or entitlement. Sometimes
Hannes> the RP only needs to know a pseudonym of the Subject.
Hannes> Prior to the transfer of attributes from the IdP to
Hannes> the RP the consent of the Subject is often explicitly
Hannes> obtained. Along with the transfer of attributes usage
Hannes> constraints and retention policies are enforced by the IdP.
Hannes> 1.1. Terminology
Hannes> This document uses identity management and privacy
Hannes> terminology from [I-D.iab-privacy-terminology]. In
Hannes> particular, this document uses the terms identity provider,
Hannes> relying party, (data) subject, identifier, pseudonymity,
Hannes> unlinkability, and anonymity.
Hannes> Please replace the reference to
Hannes> [I-D.iab-privacy-terminology] with a reference to
Hannes> http://tools.ietf.org/html/draft-iab-privacy-considerations
Hannes> since we merged the terminology with the main privacy
Hannes> consideration document.
Hannes> We also do not use the term (data) subject anymore but
Hannes> rather individual. I am not sure whether it is worthwhile to
Hannes> change it from subject to individual.
Hannes> Section 1.1 lists a table but the table has no title. Why is
Hannes> the 'SASL' row completely empty? Does SASL, EAP and the
Hannes> GSS-API actually fit in a meaningful way in that table since
Hannes> those are all two-party protocols?
Hannes> I believe the RADIUS row is wrong. It currently says:
Hannes> "
Hannes>
+----------+------------+-------------------+-----------------------+
Hannes> | Protocol | Subject | Relying Party | Identity Provider |
Hannes>
+----------+------------+-------------------+-----------------------+
Hannes> | RADIUS | client | NAS | RADIUS server | "
Hannes> but it should say:
Hannes> "
Hannes>
+----------+------------+-------------------+-----------------------+
Hannes> | Protocol | Subject | Relying Party | Identity Provider |
Hannes>
+----------+------------+-------------------+-----------------------+
Hannes> | RADIUS | user | NAS or | (RADIUS) server | | | | (RADIUS)
Hannes> client | | "
Hannes> For EAP I would delete the term 'EAP client' since it isn't
Hannes> really defined in the EAP spec (although it is used twice).
Hannes> EAP client isn't used in this draft.
Hannes> Section 1.2:
Hannes> Some deployments demand the deployment of sophisticated
Hannes> technical infrastructure, including message routing
Hannes> intermediaries, to offer the required technical
Hannes> functionality. In other deployments fewer technical
Hannes> components are needed.
Hannes> The first sentence sounds a bit strange. Maybe it is better
Hannes> to use
Hannes> Some deployments demand the usage of sophisticated
Hannes> technical infrastructure, including message routing
Hannes> intermediaries, to offer the required technical
Hannes> functionality. In other deployments fewer technical
Hannes> components are needed.
Hannes> A note about this sentence:
Hannes> Figure 1 also shows the relationship between the IdP and
Hannes> the Subject. Often a real world entity is associated with
Hannes> the Subject; for example, a person or some software.
Hannes> At least in the way we have current defined the individual
Hannes> (instead of subject) says:
Hannes> $ Individual: A natural person.
Hannes> The previous definition for subject wasn't different. As
Hannes> such, we don't need to explain that it may be a person and
Hannes> it cannot be software.
Hannes> This relationship would typically involve the IdP
Hannes> positively identifying and credentialing the Subject (for
Hannes> example, at time of enrollment in the context of employment
Hannes> within an organisation).
Hannes> NIST SP 800-63 calls this initial phase identity
Hannes> proofing. Should we re-use that terminology?
Hannes> This is sometimes described as the Level of Assurance.
Hannes> Should we reference here NIST SP 800-63 as well since they
Hannes> came up with this concept.
Hannes> Federation does not imposes requirement of an a priori
Hannes> relationship or a long-term relationship between the RP and
Hannes> the Subject.
Hannes> s/imposes requirement/impose requirements
Hannes> Finally, it is important to reiterate that in some
Hannes> scenarios there might indeed be a human behind the device
Hannes> denoted as Client and in other cases there is no human
Hannes> involved in the actual protocol execution.
Hannes> Hmmm. Wasn't the term for the human subject (or now
Hannes> individual)?
Hannes> 1.3. Challenges to Contemporary Federation
Hannes> Shouldn't we write: "Challenges for ..." Not sure.
Hannes> Section 1.4:
Hannes> 1. Principal provides an NAI to Application: The client
Hannes> application is configured with an NAI. The provided name
Hannes> contains, at a minimum, the realm of an NAI. The realm
Hannes> represents the IdP to be discovered.
Hannes> Here I believe we are talking about EAP, right? The NAI is
Hannes> an EAP/AAA concept. So, for example when you give your
Hannes> credentials to the network access application you are in
Hannes> fact provisioning a specific EAP method.
Hannes> Section 1.5:
Hannes> o Each party of a transaction will be authenticated, and
Hannes> the client will be authorized for access to a specific
Hannes> resource.
Hannes> I believe we have mutual authentication between the EAP peer
Hannes> and the EAP server; we may have mutual authentication
Hannes> between the AAA server and the AAA client. We don't really
Hannes> have the authentication of the Subject to the RP (since the
Hannes> Subject may be anonymous towards the RP). We also do not
Hannes> have a classical authentication of the RP to the Subject/App
Hannes> since the only guarantee we get is the channel binding
Hannes> mechanism (which may not be present, right?)
Hannes> o Hence, the architecture requires no sharing of long
Hannes> term private keys.
Hannes> I believe we should be more specific here: No sharing of the
Hannes> Subject's <-> IdP long term key with the RP.
Hannes> Section 2:
Hannes> Other alternatives exist as well and may be considered
Hannes> later, such as "TLS using EAP Authentication"
Hannes> [I-D.nir-tls-eap].[anchor9]
Hannes> Maybe we remove the [anchor9] thing.
Hannes> Section 2.1:
Hannes> Communications between the Relying Part and the Identity
Hannes> Provider is done by the federation substrate.
Hannes> s/Relying Part/Relying Party
Hannes> o Determining the Rules governing the relationship.
Hannes> s/Rules/rules
Hannes> o Conveying packets between the RP and IdP.
Hannes> s/packets/signaling messages
Hannes> o Providing the means of establishing a trust
Hannes> relationship between the RP and the client.
Hannes> In the text below it adds:
Hannes> The ABFAB protocol itself details the method of
Hannes> establishing the trust relationship between the RP and the
Hannes> client.
Hannes> I am not sure what this is talking about. Is this trying to
Hannes> hint to the channel binding?
Hannes> Section 2.1.1:
Hannes> The existence of these protocols allows us to re-use a
Hannes> pair of existing protocols that have been widely deployed
Hannes> and are reasonable well understood.
Hannes> s/reasonable/resonably
Hannes> A key difference is that today RADIUS is largely
Hannes> transported upon UDP, and its use is largely, though not
Hannes> exclusively, intra-domain. Diameter itself was designed to
Hannes> scale to broader uses.
Hannes> I would rephrase this as:
Hannes> " RADIUS and Diameter are deployed in different
Hannes> environments. RADIUS can often be found in enterprise and
Hannes> university networks, and is also in use by fixed network
Hannes> operators. Diameter, on the other hand, is deployed by
Hannes> mobile operators. "
Hannes> The protocol defines all the necessary new AAA attributes
Hannes> as RADIUS attributes, this allows for the same structures
Hannes> and attributes to be used in both RADIUS and Diameter.
Hannes> Actually, it is not so easy and for that reason there is a
Hannes> separate RADIUS document and one for Diameter. So, I would
Hannes> delete this sentence and maybe put references to the drafts.
Hannes> Section 2.1.2:
Hannes> ABFAB has not formally defined any part of discovery at
Hannes> this point. The process of specifying and evaluating the
Hannes> business rules and technical policies is too complex to
Hannes> provide a simple framework. There is not currently a way to
Hannes> know if a AAA proxy is able to communicate with a specific
Hannes> IdP, although this may change with some of the routing
Hannes> protocols that are being considered. At the present time,
Hannes> the discovery process is going to be a manual configuration
Hannes> process.
Hannes> Would it make sense to write this paragrah as follows since
Hannes> the work will progress but this document, once published as
Hannes> an RFC will remain unchanged:
Hannes> At the time of writing the discovery process is going to
Hannes> be a manual configuration process. Proposals for supporting
Hannes> such a dynamic discovery procedure exist, see
Hannes> [I-D.mrw-abfab-trust-router], and allow an RP to know if a
Hannes> AAA proxy is able to communicate with a specific IdP.
Hannes> 2.1.4. SAML Assertions
Hannes> The new profile can be found in RFCXXXX
Hannes> [I-D.ietf-abfab-aaa-saml].
--> and in the corresponding Diameter document.
Hannes> Throughout this section use s/Assertions/assertions
Hannes> Section 2.2:
Hannes> ABFAB has defined and specified a new channel binding
Hannes> mechanism that operates as an EAP method for the purpose of
Hannes> agreeing on the identity of the RP.
Hannes> I would write:
Hannes> A new channel binding mechanism that operates as an EAP
Hannes> method for the purpose of agreeing on the identity of the RP
Hannes> has been specified in [TBD: whatever that document is].
Hannes> Section 2.2.2:
Hannes> A general overview of the problem can be found in
Hannes> [I-D.hartman-emu-mutual-crypto-bind]. The recommended way
Hannes> to deal with channel binding can be found in RFC XXXX
Hannes> [I-D.ietf-emu-chbind].
Hannes> I would write:
Hannes> A general overview of the channel binding problem can be
Hannes> found in RFC 6677.
Hannes> [I have to continue with the GSS related content later.]
Hannes> Ciao Hannes
Hannes> _______________________________________________ abfab
Hannes> mailing list [email protected]
Hannes> https://www.ietf.org/mailman/listinfo/abfab
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
