Re: [abfab] draft-ietf-abfab-arch-03.txt

[Sam Hartman <[e-mail]>]

>>>>> "Hannes" == Hannes Tschofenig <[e-mail]> 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 [e-mail]
    Hannes> https://www.ietf.org/mailman/listinfo/abfab