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

[Hannes Tschofenig <[e-mail]>]

Hi Jim, 

you have shipped an update of the ABFAB architecture draft for the Vancouver IETF meeting and I have only now had a chance to review the changes. Overall, I have to say "Great work." 

I only have a few minor text suggestions: 


   Federated access management has evolved over the last decade through
   such standards as SAML [OASIS.saml-core-2.0-os], OpenID [1], OAuth
   [RFC5849], [I-D.ietf-oauth-v2] and WS-Trust [WS-TRUST]. 
   
   s/such standards as/specifications like 
   
   
   
   Privacy:

      Often a Relying Party does not need to know the identity of a
      Subject to reach an access management decision.  It is frequently
      only necessary for the Relying Party know specific attributes
      about the subject, for example, that the Subject is affiliated
      with a particular organisation or has a certain role or
      entitlement.  Sometimes the RP does not need to know the identity
      of the Subject, but does require a unique identifier for the
      Subject (for example, so that it can recognise the Subject
      subsequently); in this case, it is a common practise for the IdP
      to only release a pseudonym that is specific to that particular
      Relying Party.  Federated access management therefore provides
      various strategies for protecting the Subject's privacy.  Other
      privacy aspects typically of concern are the policy for releasing
      personal data about the Subject from the IdP to the RP, the
      purpose of the usage, the retention period of the data, and many
      more.
      
This paragraph needs to be re-written to something like:

   Data Minimization and User Participation: 
   
      Often a Relying Party does not need to know the identity of a
      Subject to reach an access management decision.  It is frequently
      only necessary for the Relying Party know specific attributes
      about the subject, for example, that the Subject is affiliated
      with a particular organisation or has a certain role or
      entitlement. Sometimes the RP only needs to know a pseudonym 
      of the Subject. 
      
      Prior to the transfer of attributes from the IdP to the RP the 
      consent of the Subject is often explicitly obtained. Along with the 
      transfer of attributes usage constraints and retention policies 
      are enforced by the IdP. 
      
   
1.1.  Terminology

   This document uses identity management and privacy terminology from
   [I-D.iab-privacy-terminology].  In particular, this document uses the
   terms identity provider, relying party, (data) subject, identifier,
   pseudonymity, unlinkability, and anonymity.   
   
   
Please replace the reference to [I-D.iab-privacy-terminology] with a reference to http://tools.ietf.org/html/draft-iab-privacy-considerations since we merged the terminology with the main privacy consideration document. 

We also do not use the term (data) subject anymore but rather individual. I am not sure whether it is worthwhile to change it from subject to individual. 


Section 1.1 lists a table but the table has no title. Why is the 'SASL' row completely empty?
Does SASL, EAP and the GSS-API actually fit in a meaningful way in that table since those are 
all two-party protocols?  

I believe the RADIUS row is wrong. It currently says:

"
   +----------+------------+-------------------+-----------------------+
   | Protocol | Subject    | Relying Party     | Identity Provider     |
   +----------+------------+-------------------+-----------------------+
   | RADIUS   | client     | NAS               | RADIUS server         |
"

but it should say:

"

   +----------+------------+-------------------+-----------------------+
   | Protocol | Subject    | Relying Party     | Identity Provider     |
   +----------+------------+-------------------+-----------------------+
   | RADIUS   | user       | NAS or            | (RADIUS) server       |
   |          |            | (RADIUS) client   |                       |
"

For EAP I would delete the term 'EAP client' since it isn't really defined in the EAP spec (although it is used twice).
EAP client isn't used in this draft. 

Section 1.2:

   Some deployments demand the deployment of sophisticated technical
   infrastructure, including message routing intermediaries, to offer
   the required technical functionality.  In other deployments fewer
   technical components are needed.
   
   
The first sentence sounds a bit strange. Maybe it is better to use

   Some deployments demand the usage of sophisticated technical
   infrastructure, including message routing intermediaries, to offer
   the required technical functionality.  In other deployments fewer
   technical components are needed.
   
   
A note about this sentence: 

   Figure 1 also shows the relationship between the IdP and the Subject.
   Often a real world entity is associated with the Subject; for
   example, a person or some software.
   
At least in the way we have current defined the individual (instead of subject) says:

   $ Individual:   A natural person.
   
The previous definition for subject wasn't different. As such, we don't need to explain that it may be a person and it cannot be software. 

   This relationship would typically involve the IdP
   positively identifying and credentialing the Subject (for example, at
   time of enrollment in the context of employment within an
   organisation).
   
NIST SP 800-63 calls this initial phase identity proofing. Should we re-use that terminology?


   This is sometimes described as the Level of Assurance.
   
Should we reference here NIST SP 800-63 as well since they came up with this concept. 




   Federation does not imposes requirement of an a priori relationship
   or a long-term relationship between the RP and the Subject.
   
   
s/imposes requirement/impose requirements

   Finally, it is important to reiterate that in some scenarios there
   might indeed be a human behind the device denoted as Client and in
   other cases there is no human involved in the actual protocol
   execution.


Hmmm. Wasn't the term for the human subject (or now individual)?


1.3.  Challenges to Contemporary Federation

Shouldn't we write: "Challenges for ..."
Not sure. 

Section 1.4:


   1.   Principal provides an NAI to Application: The client application
        is configured with an NAI.  The provided name contains, at a
        minimum, the realm of an NAI.  The realm represents the IdP to
        be discovered.
        
Here I believe we are talking about EAP, right? The NAI is an EAP/AAA concept. 
So, for example when you give your credentials to the network access application you are in fact provisioning a specific EAP method. 

Section 1.5:

   o  Each party of a transaction will be authenticated, and the client
      will be authorized for access to a specific resource.
      
I believe we have mutual authentication between the EAP peer and the EAP server; we may have mutual authentication between the AAA server and the AAA client. We don't really have the authentication of the Subject to the RP (since the Subject may be anonymous towards the RP). We also do not have a classical authentication of the RP to the Subject/App since the only guarantee we get is the channel binding mechanism (which may not be present, right?)


   o  Hence, the architecture requires no sharing of long term private
      keys.


I believe we should be more specific here: No sharing of the Subject's <-> IdP long term key with the RP. 

Section 2: 


   Other alternatives exist as well and may
   be considered later, such as "TLS using EAP Authentication"
   [I-D.nir-tls-eap].[anchor9]
   
Maybe we remove the [anchor9] thing. 

Section 2.1:

   Communications between the Relying Part and the Identity Provider is
   done by the federation substrate. 

s/Relying Part/Relying Party

   o  Determining the Rules governing the relationship.
   
s/Rules/rules 

   o  Conveying packets between the RP and IdP.
   
s/packets/signaling messages


   o  Providing the means of establishing a trust relationship between
      the RP and the client.   	
      
In the text below it adds:

   The ABFAB protocol
   itself details the method of establishing the trust relationship
   between the RP and the client.
   
I am not sure what this is talking about. Is this trying to hint to the channel binding?

Section 2.1.1:

   The existence
   of these protocols allows us to re-use a pair of existing protocols
   that have been widely deployed and are reasonable well understood.
   
s/reasonable/resonably

   A key
   difference is that today RADIUS is largely transported upon UDP, and
   its use is largely, though not exclusively, intra-domain.  Diameter
   itself was designed to scale to broader uses. 
   
I would rephrase this as:

"
   RADIUS and Diameter are deployed in different environments. RADIUS can often be found in 
   enterprise and university networks, and is also in use by fixed network operators. Diameter, on the other 
   hand, is deployed by mobile operators. 
"

   The
   protocol defines all the necessary new AAA attributes as RADIUS
   attributes, this allows for the same structures and attributes to be
   used in both RADIUS and Diameter.    

Actually, it is not so easy and for that reason there is a separate RADIUS document and 
one for Diameter. So, I would delete this sentence and maybe put references to the drafts. 

Section 2.1.2:

   ABFAB has not formally defined any part of discovery at this point.
   The process of specifying and evaluating the business rules and
   technical policies is too complex to provide a simple framework.
   There is not currently a way to know if a AAA proxy is able to
   communicate with a specific IdP, although this may change with some
   of the routing protocols that are being considered.  At the present
   time, the discovery process is going to be a manual configuration
   process.
   
   
Would it make sense to write this paragrah as follows since the work will progress but this document, once published as an RFC will remain unchanged:

   At the time of writing the discovery process is going to be a manual configuration
   process. Proposals for supporting such a dynamic discovery procedure exist, see [I-D.mrw-abfab-trust-router], 
   and allow an RP to know if a AAA proxy is able to communicate with a specific IdP.     
   
2.1.4.  SAML Assertions

 The new
   profile can be found in RFCXXXX [I-D.ietf-abfab-aaa-saml].
   
--> and in the corresponding Diameter document. 


Throughout this section use s/Assertions/assertions

Section 2.2: 
      
   ABFAB has defined
   and specified a new channel binding mechanism that operates as an EAP
   method for the purpose of agreeing on the identity of the RP.
 
I would write: 

   A new channel binding mechanism that operates as an EAP
   method for the purpose of agreeing on the identity of the RP has been 
   specified in [TBD: whatever that document is].
   
   
Section 2.2.2: 

   A general overview of the problem can be found in
   [I-D.hartman-emu-mutual-crypto-bind].
   The recommended way to deal with channel binding can be found in RFC
   XXXX [I-D.ietf-emu-chbind].
   
I would write: 

   A general overview of the channel binding problem can be found in
   RFC 6677. 
   
   
[I have to continue with the GSS related content later.] 

Ciao
Hannes