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

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 16 Aug 2012 10:09:00 +0300

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

---

From: Sam Hartman <[email-masked]>
Date: Thu, 16 Aug 2012 08:22:42 -0400

>>>>> "Hannes" == Hannes Tschofenig <[email-masked]> 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].

    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-masked]
    Hannes> https://www.ietf.org/mailman/listinfo/abfab

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 17 Aug 2012 14:52:04 +0300

Hi Sam, 

thanks for the quick response. 

> may provide an accurate description of our hopes, but not so much of the

The issue with the original paragraph is the following. 

   Privacy:

[hannes] The title privacy suggests that we cover privacy as a whole but instead the paragraph only discussed a small area of privacy. For this reason I suggested to change the title of that paragraph 

      entitlement.

[hannes] Here we have a terminology issue. Let me copy the definition of "identity" here: 
http://tools.ietf.org/html/draft-iab-privacy-considerations-02
"
   $ Identity

      Any subset of a data subject's attributes that identifies the
      subject within a given context.  Data subjects usually have
      multiple identities for use in different contexts.
"

So, I think what the above sentence tries to say is that the relying party only needs to know a (small) subset of the subject's attributes and particularly not an identifier that is persistent across multiple sessions.  

  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); 

[hannes] This also confused the terminology. A unique identifier of a subject is one of the identities of the subject.

in this case, it is a common practise for the IdP
      to only release a pseudonym that is specific to that particular
      Relying Party.

[hannes] Here is the definition of the pseudonym:

"
  $ Pseudonym

      An identifier of a data subject other than the subject's real
      name.
"
So, I guess the previous sentence should have talked about identifiers rather than identities. 

  Federated access management therefore provides

---

From: Josh Howlett <[email-masked]>
Date: Fri, 17 Aug 2012 13:16:57 +0000

> > may provide an accurate description of our hopes, but not so much of

I prefer Hannes' formulation; with the exception of the part discussing consent. I don't think it is necessary to discuss specific policy mechanisms (particularly in the case of consent, where there is plenty of ambiguity about where it is appropriate and where it is not).

Josh.

Janet is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG

---

From: Leif Johansson <[email-masked]>
Date: Fri, 17 Aug 2012 16:33:03 +0200

> I prefer Hannes' formulation; with the exception of the part discussing consent. I don't think it is necessary to discuss specific policy mechanisms (particularly in the case of consent, where ther…

+1 consent is just a huge can of worms

> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

---

From: Sam Hartman <[email-masked]>
Date: Fri, 17 Aug 2012 12:16:37 -0400

I'm fine with Hannes's formulation if we drop consent

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 18 Aug 2012 20:36:53 +0930

I'll try and get this in the next revision

> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]]
> Sent: Saturday, August 18, 2012 1:47 AM
> To: Josh Howlett
> Cc: Hannes Tschofenig; Jim Schaad; [email-masked]
> Subject: Re: [abfab] draft-ietf-abfab-arch-03.txt
>