Subject: [abfab] Issue #6 - bad flow of text for authentication requriements

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Sat, 17 Dec 2011 18:02:36 +0200

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

---

From: Sam Hartman <[email-masked]>
Date: Mon, 19 Dec 2011 10:08:43 -0500

>>>>> ""Tschofenig," == "Tschofenig, Hannes (NSN <- FI/Espoo)" <[email-masked]>> writes:

    "Tschofenig,> The sentence you are referring to, namely "Aside from
    "Tschofenig,> a valuable secret being exposed, a synchronization
    "Tschofenig,> problem can also often develop." should be deleted. I
    "Tschofenig,> understand that there may be a synchronization problem
    "Tschofenig,> when you cache your distribute your long term secret
    "Tschofenig,> everywhere but that's only secondary (and less
    "Tschofenig,> important). 

I disagree that this synchronization issue is secondary in terms of
deployment concerns.  I actually think that the synchronization issue
drives up support costs and creates a real business case for ABFAB far
more than the security issues.
So, I'd rather continue to document this issue.

--Sam

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 19 Dec 2011 18:58:50 +0200

Hi Sam,

if you want to document it then we may need to provide a bit more text.
I could imagine that we find that text in some of the OAuth documents. 

Ciao
Hannes

> -----Original Message-----
> From: ext Sam Hartman [mailto:[email-masked]]
> Sent: Monday, December 19, 2011 5:09 PM
> To: Tschofenig, Hannes (NSN - FI/Espoo)
> Cc: [email-masked]
> Subject: Re: [abfab] Issue #6 - bad flow of text for authentication
> requriements
>

---

From: Sam Hartman <[email-masked]>
Date: Mon, 19 Dec 2011 12:12:52 -0500

>>>>> ""Tschofenig," == "Tschofenig, Hannes (NSN <- FI/Espoo)" <[email-masked]>> writes:

    "Tschofenig,> Hi Sam, if you want to document it then we may need to
    "Tschofenig,> provide a bit more text.  I could imagine that we find
    "Tschofenig,> that text in some of the OAuth documents.

OK, can you help me understand what's wrong with what is there now?
It seems reasonably clear to me, so I'd like to better understand what
you and/or Jim find confusing.

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 19 Dec 2011 16:35:40 -0800

If you read my note, it has nothing to do with the issues of
synchronization.  I completely agree that they are problem and that they
should be covered.   My issue had to do with how the text was written and
flows.

In terms of completing the thought,  a simple statement that 
this can lead to the client having the new password and a server having the
password and thus they are unable to authenticate" is sufficient for me.  My
real problem is that the text does not flow and the first sentence appears
to want more development but the text skips into a new issue on the next
sentence.

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Sam Hartman
> Sent: Monday, December 19, 2011 9:13 AM
> It seems reasonably clear to me, so I'd like to better understand what you
> and/or Jim find confusing.
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab