Re: [AAA-DOCTORS] Please review draft-ietf-abfab-arch

[Alan DeKok <[e-mail]>]

Benoit Claise wrote:
> No answer to this one?

  Here we go.  In short, the document is good, but seems to assume a
familiarity with the concepts being discussed.  It talks about concepts
without introducing them, leading to confusion on the part of the naive
reader.

Section 1

   Numerous security mechanisms have been deployed on the Internet to
   manage access to various resources.

- This is a bit vague.  "Security does stuff". Some examples would help.

   A Relying Party (RP) is the entity that manages access to some
   resource

- This sentence jumps discontinuously from the previous paragraph.  Why
are we talking about Relying parties?  It's generally easier to talk
about problems, and then to introduce solutions to those problems.

     ... The entity that is requesting access to that resource is
   often described as the Client.

  Why not use "Client" and "Server"?  Jumping straight to new
terminology is awkward.

   Some security mechanisms allow the RP to delegate aspects of the
   access management decision to an entity called the Identity Provider
   (IdP).  This delegation requires technical signaling, trust and a
   common understanding of semantics between the RP and IdP.  These
   aspects are generally managed within a relationship known as a
   'federation'.

- The "federation" doesn't follow from delegation.  System A can
delegate functionality to system B, but that's just delegation.  I would
expect to see motivation for federation.

- e.g. when there are many people trying to authenticate, the Server may
not have credentials for all of them.  It may delegate the
authentication to one or more secondary Servers.  Any grouping of
Servers to achieve a common purpose is called a "federation"

- once we define the problem space in terms of *existing* terminology,
it's then possible to introduce *new* terminology.

   Single or Simplified sign-on:

      An Internet service can delegate access management

- what's an "Internet Service" ?  That's the first use of the term in
this document.  Is it a Relying Party?  A generic Server?

      Often a Relying Party does not need to know the identity of a
      Client to reach an access management decision.  It is frequently
      only necessary for the Relying Party to know specific attributes
      about the client,

- nitpick I'd use "properties" rather than "attributes".  Attributes
have a well-defined meaning in AAA space.  The properties talked about
above may not be transported in attributes, so they shouldn't be called
attributes.

      Prior to the release of attributes to the RP from the IdP, the IdP
      will check configuration and policy to determine if the attributes
      are to be released.

- Why is an IdP releasing attributes to the RP?  This is the first
mention of it.

      Sometimes a Relying Party needs, or would like, to know more about
      a client than an affiliation or a pseudonym.

- Why?  Because "it's Tuesday, and I want to know his shoe size"?  Or
are there problems whih are solved by asking for additional information?

   This memo describes the Application Bridging for Federated Access
   Beyond the Web (ABFAB) architecture.  This architecture makes use of
   extensions to the commonly used security mechanisms for both
   federated and non-federated access management, including RADIUS, the
   Generic Security Service (GSS), the Extensible Authentication
   Protocol (EAP) and SAML.  The architecture should be extended to use
   Diameter in the future.  The architecture addresses the problem of
   federated access management primarily for non-web-based services.

- the last sentence there should be moved to be the second one.
  i.e. What is ABFAB.  Problem to be solved.  Technology used to solve
  the problem.

Section 1.1

   This document uses identity management and privacy terminology from
   [RFC6973].  In particular, this document uses the terms identity
   provider, relying party, identifier, pseudonymity, unlinkability, and
   anonymity.

- that sentence could be moved to earlier in the document.  It gives a
basis for the terminology used in Section 1.  Or, re-word Section 1 to
use less of the terminology introduced in Section 1.1.

   This document uses the term Network Access Identifier (NAI), as
   defined in [I-D.ietf-radext-nai].  An NAI consists of a realm
   identifier, which is associated with an IdP

- Why is a realm associated with an IdP?  Again, motivation.  Does the
*document* use the NAI, or does it assume that the *authentication it
talks about* uses the NAI?

- e.g. We assume that each authentication request in the ABFAB
architecture includes an NAI.  The realm portion of the NAI is used to
distinguish and/or select an IdP.  Each IdP may have one or more realms.

   One of the problems some people have found with reading this document
   is that the terminology sometimes appears to be inconsistent.  This
   is due the fact that the terms used by the different standards we are
   referencing are not consistent with each other.  In general the
   document uses either the ABFAB term or the term associated with the
   standard under discussion as appropriate.

- nitpick: I would say that for general cases, this document uses the
terminology from RFC 6973, as it is cross-standard.  Where this document
refers to actions of a particular protocol, the protocol-specific terms
are used.  e.g. "ABFAB relies on an IdP", versus "the RADIUS client ..."

- doing so should make the document clearer

   Note that in some cases a cell has been left empty; in these cases
   there is no name that represents the entity.

- nitpick: there is no name *within that standard* which defines the
given term.

   This document uses the term channel binding with two different
   meanings.

- I would say "in two different contexts".  The later specification of
"EAP channel bindings" and "GSS-API channel bindings" makes the
distinction clear.  The term "channel bindings" therefore does not have
two different meanings, as it should be used only within the context of
"EAP" or "GSS-API".

   Federation

      The Identity Provider and the Relying Parties are part of a
      Federation.  The relationship may be direct (they have an explicit
      trust relationship) or transitive (the trust relationship is
      mediated by one or more entities).  The federation relationship is
      governed by a federation agreement.  Within a single federation,
      there may be multiple Identity Providers as well as multiple
      Relying Parties.

- I find this confusing, and not in line with the other definitions.  A
definition should be of the form:

  FOO
    FOO is thing which does BAR, and used BAZ and BARK to do so.

- e.g.  A Federation is composed of a set of Identity Providers and
Relying Parties.  The IdPs and RPs may have explicit trust relationships
with each other, or the trust may be mediated by one more more entities
within that federation.  The relationships between IdPs and RPs is
governed by a federation agreement, which is outside of the scope of
this specification.

   Authentication

      There is a direct relationship between the Client and the Identity
      Provider.  This relationship provides the means by which they
      trust each other and can securely authenticate each other.

- the same comment applies here.  Authentication is *something*.  The
first sentence of the definition above seems to have no bearing on
authentication

  Operational Specifications:

- put the last sentence first, which motivates the rest of the paragraph.

   The Operational Specifications can demand the usage of a
   sophisticated technical infrastructure,

- as opposed to a crappy technical infrastructure?  I suggest just
deleting the word "sophisticated"

   While a federation agreement is often discussed within the context of
   formal relationships, such as between an enterprise and an employee
   or a government and a citizen,

- who is doing that discussion?  I don't see it in this document.  Some
clarity would help here.

   For an IdP and a
   Client, it is sufficient for a relationship to be established by
   something as simple as using a web form and confirmation email.

- are we suggesting implementation details?  If so, why does it matter?

   The nature of federation dictates that there is some form of
   relationship between the identity provider and the relying party.
   This is particularly important when the relying party wants to use
   information obtained from the identity provider for access management
   decisions and when the identity provider does not want to release
   information to every relying party (or only under certain
   conditions).

- Suggest capitalization of terms, to match the rest of the draft

   While it is possible to have a bilateral agreement between every IdP
   and every RP; on an Internet scale this setup requires the
   introduction of the multi-lateral federation concept, as the
   management of such pair-wise relationships would otherwise prove
   burdensome.

- what is a "multi-lateral federation concept"?  A concept?  A real thing?

   The nature and quality of the relationship between the Client and the
   IdP is an important contributor to the level of trust that an RP may
   attribute to an assertion

- "attribute" is used in other contexts here.  I'd suggest using a
synonym for "attribute"

   Federation does not require an a priori relationship or a long-term
   relationship between the RP and the Client; it is this property of
   federation that yields many of its benefits.

- what does "its" refer to?  The federation?  The relationship?

   However, federation
   does not preclude the possibility of a pre-existing relationship
   between the RP and the Client, nor that they may use the introduction
   to create a new long-term relationship independent of the federation.

- nitpick: I would say that the entities may have relationships outside
of the federation, including ones prior and post to the federation

   As the number of federated IdPs and RPs (services) proliferats,

- typo "proliferates".  And why is (services) there?  Are RPs just RPs,
or are they now (services)?  I suggest deleting it.

   As the number of federated IdPs and RPs (services) proliferats, the
   role of the individual

- ... was not previously discussed.  I suggest replacing that with
something like "an individual may have multiple identities (NAIs), and
choose the correct identity for network access"

  For instance, in the case of an email
   provider, the SMTP and IMAP protocols do not have the ability for the
   server to request information from the client, beyond the clients
   NAI, that the server would then use to decide between the multiple
   federations it is associated with.

Section 1.4

- nitpick: that's a long sentence.  Suggest breaking it up into smaller
fragments.

   In this example, a client is attempting to connect to a server

- nitpick: suggest passive voice. "a client attempts to connect ..."

- many of the following paragraphs have "X is configured".  OK, how?
Maybe "we assume that configuration discussed below is out of band, e.g.
via manual administrator action"



  OK... it's lunchtime here.  I'm done for now.  More later.

  Alan DeKok.