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
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
