Hi Jim,
for issue#6 http://trac.tools.ietf.org/wg/abfab/trac/ticket/6 you wrote:
"
Has the sentences " Aside from a valuable secret being exposed, a
synchronization problem can also often develop. Since there is no
single authentication mechanism that will be used everywhere there
is
another associated requirement:"
I have a couple of issues here. First there is a problem which is stated
- i.e. synchronization - but the next sentence does not appear to expand
on the problem but rather deals with a different issue. I would like to
have the first thought finished before going onto the second one. I
think this paragraph is supposed to be talking about issues that we have
been taught - but the word Since does not convey this is a separate
issue we have dealing with.
"
Here is the text from the draft:
"
2.2. Subject To Identity Provider
Traditional web federation does not describe how a subject
communicates with an identity provider. As a result, this
communication is not standardized. There are several disadvantages
to this approach. It is difficult to have subjects that are machines
rather than humans that use some sort of programatic credential. In
addition, use of browsers for authentication restricts the deployment
of more secure forms of authentication beyond plaintext username and
password known by the server. In a number of cases the
authentication interface may be presented before the subject has
adequately validated they are talking to the intended server. By
giving control of the authentication interface to a potential
attacker, then the security of the system may be reduced and phishing
opportunities introduced.
As a result, it is desirable to choose some standardized approach for
communication between the subject's end-host and the identity
provider. There are a number of requirements this approach must
meet.
Experience has taught us one key security and scalability
requirement: it is important that the relying party not get in
possession of the long-term secret of the entity being authenticated
by the AAA server. Aside from a valuable secret being exposed, a
synchronization problem can also often develop. Since there is no
single authentication mechanism that will be used everywhere there is
another associated requirement: The authentication framework must
allow for the flexible integration of authentication mechanisms. For
instance, some identity providers may require hardware tokens while
others may use passwords. A service provider would want to support
both sorts of federations, and others.
Fortunately, these requirements can be met by utilizing standardized
and successfully deployed technology, namely by the Extensible
Authentication Protocol (EAP) framework [RFC3748]. Figure 2
illustrates the integration graphically.
EAP is an end-to-end framework; it provides for two-way communication
between a peer (i.e,service client or principal) through the
authenticator (i.e., service provider) to the back-end (i.e.,
identity provider). Conveniently, this is precisely the
communication path that is needed for federated identity. Although
EAP support is already integrated in AAA systems (see [RFC3579] and
[RFC4072]) several challenges remain: one is to carry EAP payloads
from the end host to the relying party. Another is to verify
statements the relying party has made to the subject, confirm these
statements are consistent with statements made to the identity
provider and confirm all the above are consistent with the federation
and any federation-specific policy or configuration. Another
challenge is choosing which identity provider to use for which
service.
"
The sentence you are referring to, namely "Aside from a valuable secret
being exposed, a synchronization problem can also often develop." should
be deleted. I understand that there may be a synchronization problem
when you cache your distribute your long term secret everywhere but
that's only secondary (and less important). If we avoid exposing the
long term secret to the RP, which we do in the document by using the AAA
infrastructure, then we do not have to worry about the synchronization
issue.
There is a problem with the readability of the section in general. Here
the text refers to the authentication protocol executed between the
application used by the data subject and the identity provider, which is
indeed left out-of-scope by many standardized Web identity management
protocols, but it does not refer to any other steps the data subject may
need to take as well in order to actually get the credentials
provisioned at the IdP and to perform the steps for identity proofing.
Ciao
Hannes
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
