Subject: [Emu] EAP and authorization

From: "Alper Yegin" <[email-masked]>
Date: Fri, 7 Aug 2009 16:30:49 +0300

This issue came up during the last IETF meeting when the WG discussed
channel binding.

Pasi said the discussion was within the scope of EMU WG charter.

- A document that defines EAP channel bindings and provides guidance
for establishing EAP channel bindings within EAP methods.

- A mechanism to support extensible communication within a TLS
protected tunnel.

I'm not against this. But let's face it, this is venturing into dealing with
authorization parameters with EAP (EAP layer? EAP method layer? Etc.) I'm
not against that either. In fact, I know there are a lot of people who'd be
happy to see that happen. 

So, my question is, is this what we are doing: Enabling EAP to exchange
authorization parameters among the EAP peer - authenticator - authentication
server? If not, I hope someone can explain how this is different than what
it takes to solve channel binding problem.

Thanks.

Alper

---

From: Alan DeKok <[email-masked]>
Date: Tue, 11 Aug 2009 18:26:57 +0200

Alper Yegin wrote:
> I’m not against this. But let’s face it, this is venturing into dealing
> with authorization parameters with EAP (EAP layer? EAP method layer?
> Etc.) I’m not against that either. In fact, I know there are a lot of
> people who’d be happy to see that happen.

  Prior to authentication, EAP is the only communications protocol
between a supplicant and *anywhere* on the network.  It is therefore
natural to overload it as a general purpose transport protocol.

> authorization parameters among the EAP peer – authenticator –
> authentication server? If not, I hope someone can explain how this is
> different than what it takes to solve channel binding problem.

  I believe that is what is happening: authorization parameters are
being exchanged in EAP.  This should be made clearer in the documents.

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 11 Aug 2009 10:56:38 -0700

> natural to overload it as a general purpose transport protocol.

To transport what, exactly?

> being exchanged in EAP.  This should be made clearer in the documents.

Above you said "Prior to authentication, EAP is the only communications protocol between a supplicant and *anywhere* on the network" by way of rationalizing the use of EAP "as a general purpose transport protocol".  I could have sworn that authorization _follows_ and is parameterized by authentication.  So, please tell me again why EAP should be (further) bastardized for this purpose.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 11 Aug 2009 20:36:27 +0200

> Alan DeKok [mailto://[email-masked]] writes:
...
> To transport what, exactly?

  The data discussed in the tunnel requirements draft, Section 3.6.
Among others.

> Above you said ... by way of rationalizing

  "explaining"

  The two are very different.

> the use of EAP "as a general purpose transport protocol".  I could have
> sworn that authorization _follows_ and is parameterized by authentication.

  I agree.  I haven't seen any proposal that contradicts this.

> So, please tell me again why EAP should be (further) bastardized for this purpose.

  People are proposing it because they find it useful.  This isn't mean
it's a good idea, just that it's one that has real-world uses.

  My message about this topic was intended to foster discussion.  If
there is strong objection to the idea, we can refuse to "bastardize"
EAP.  If there is strong consensus that this is necessary, it's best to
make it explicit in the documents.

  Alan DeKok.

---

From: Stephen Hanna <[email-masked]>
Date: Tue, 11 Aug 2009 15:02:54 -0400

Network Endpoint Assessment (NEA) messages can be considered
authorization data. Certainly, they're not authentication.
They convey information about endpoint posture (like whether
anti-virus software is installed and enabled). Yet they are
carried in EAP messages every day, generally in tunnel methods.

I don't think there's anything wrong with this practice.
In fact, it's the best way to ensure that a NEA assessment
is performed before network access is granted.

I wouldn't say that EAP is becoming a "general purpose"
transport protocol. EAP has many limitations that make
it a poor choice for most situations that need a
transport protocol. However, for some purposes it
is a good match. NEA is one of those purposes.

Thanks,

Steve

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Alan DeKok
> Sent: Tuesday, August 11, 2009 2:36 PM
> To: Glen Zorn
> Cc: [email-masked]
> Subject: Re: [Emu] EAP and authorization
> 
> Glen Zorn wrote:
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu
>

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 11 Aug 2009 13:22:04 -0700

>   The data discussed in the tunnel requirements draft, Section 3.6.

Since that section is the only one that specifically mentions support for network configuration control (I won't stoop to claiming that NEA has any relation to security) rather than authentication, perhaps it should be removed.

> Among others.

What others?

>   My message about this topic was intended to foster discussion.  

Success!

> If

More likely the creation of a new protocol, unless "convenience" (a word that is used often in the draft as (often the only) justification for bizarre additions to EAP) has taken precedence over engineering in this WG.

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 11 Aug 2009 13:37:12 -0700

Stephen Hanna [mailto:[email-masked]] writes:

> authorization data. 

They can, in the broadest sense of authorization as policy enforcement.  It
has almost nothing to do with actual security, but that's OK, I guess.

> Certainly, they're not authentication.

Certainly not.

> carried in EAP messages every day, generally in tunnel methods.

So is the argument "Juniper (& presumably Cisco) have already bastardized
EAP, so we must rubberstamp it"?

> is performed before network access is granted.

Hmm.  Has another way been tried or is it the best way because it's the
easiest (or only) way we've tried?

> is a good match. NEA is one of those purposes.

Except for that whole pesky name & purpose thing -- you know, Extensible
_Authentication_ Protocol.

---

From: Stephen Hanna <[email-masked]>
Date: Tue, 11 Aug 2009 16:59:53 -0400

This discussion started with the statement that channel bindings
are a form of authorization data. Our charter requires us to
support carrying channel bindings in the tunnel method.
Password change is another form of non-authentication data
that we need to support. Clearly there are several kinds of
non-authentication data that we must support carrying in EAP.
They are in our charter. I see no harm in also supporting
carrying NEA assessments in the tunnel method.

The only bizarre engineering here is Glen's suggestion
that because the A in EAP stands for Authentication, it
should not be allowed to carry anything other than
authentication protocols. By that logic, RADIUS should
be prohibited from carrying VLAN assignments and anything
other than authentication information. After all, the A
in RADIUS also stands for authentication. And RADIUS
should be restricted to Dial In access since that's
what the D and I stand for!

Glen, if you don't have any substantive arguments to
make, don't try to impress us with bluster.

Thanks,

Steve

> Behalf Of Glen Zorn
> Sent: Tuesday, August 11, 2009 4:22 PM
> To: 'Alan DeKok'
> Cc: [email-masked]
> > > So, please tell me again why EAP should be (further) 
> bastardized for
> > this purpose.
> > 
> More likely the creation of a new protocol, unless 
> "convenience" (a word that is used often in the draft as 
> (often the only) justification for bizarre additions to EAP) 
> has taken precedence over engineering in this WG.
> 
> > 
> >   Alan DeKok.
>

---

From: "Hoeper Katrin-QWKN37" <[email-masked]>
Date: Tue, 11 Aug 2009 17:34:06 -0400

Hi,

Before this discussion escalades any further, I would like to summarize
the open issue(s) that need to be addressed to move the channel binding
draft forward.

Channel binding is a work group item because there was a group consensus
that the lying NAS and lying provider problem are real threats that need
to be addressed. In other words, we decided that EAP needs to provide
means to find out whether an authenticator (or intermediary entity) is
sending false information to the peer and/or the EAP server.

There is no need to further discuss the above, since we achieved group
consensus on this a long time ago. 

draft-ietf-emu-chbind-03
(http://tools.ietf.org/html/draft-ietf-emu-chbind-03) was accepted as a
WG item and addresses the above problem.

Here's the open issue (as I see it from previous posts to the list):

The draft also introduces an additional feature that can be achieved
using channel bindings, namely checking whether an authenticator is
authorized to provide the requested services. This feature was added at
some time, because Bernard pointed out that it could be provided at not
much extra cost. Channel binding itself already requires an
integrity-protected exchange of data as well as a local database (only
additional DB entries would be needed and the exchange of data that is
relevant to authorization (and not to channel bindings)). 

I already mentioned in my reply to Klaas' review of
draft-ietf-emu-chbind-02
(http://www.ietf.org/mail-archive/web/emu/current/msg01140.html) that I
could remove this additional feature, if there is a group consensus to
do so.

So please let's concentrate on this issue and not rehash the whole
channel binding discussion.

Is this the only issue that people are having with the draft?
If so, I'd be interested if 1) there is a group consensus to remove the
authorization feature and 2) whether removing this feature solves all
open issues with the draft.

Thanks,
Katrin

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Stephen Hanna
> Sent: Tuesday, August 11, 2009 4:00 PM
> To: Glen Zorn; 'Alan DeKok'
> Cc: [email-masked]
> > > > the use of EAP "as a general purpose transport protocol".  I
could
> > > have

---

From: Alan DeKok <[email-masked]>
Date: Wed, 12 Aug 2009 00:07:55 +0200

> easiest (or only) way we've tried?

  Authentication decisions have traditionally involved more than just
username / password checking.  Authentication decisions are also
commonly based on "pre-authorization" data, such as:

 * time of day
 * location
   * physical
   * network
 * account balance
 * past behavior
 * machine used to authenticate

  And so on.

  An authentication server may use any of that information to return a
"failed authentication" status to the client, even if the username /
password is superficially correct.  This is not "authorization", because
the user has not been authenticated.  But that information is still used
to make authentication decisions.

  Enabling EAP to carry this information is well within the bounds of
the protocol.  TLS-based EAP methods can carry information such as time
of life for a certificate, issuer, etc.

  If we restrict EAP to solely "authentication", then I would ask what
that means.  An authentication protocol that is incapable of
transporting the data required to make authentication decisions would be
perfectly secure: No one would ever be authenticated.

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 11 Aug 2009 16:08:08 -0700

Stephen Hanna [mailto:[email-masked]] writes:

> are a form of authorization data. 

And no one disputed this?

> Our charter requires us to
> that we need to support. 

Please explain how passwords are unrelated to authentication.

> Clearly there are several kinds of

You are entitled to your opinion.

> what the D and I stand for!

I really appreciate your putting two separate messages from me into your
magic blender.  Unsurprisingly, what came out was only vaguely related to
what I actually wrote, but that was the point, wasn't it?  What I actually
said (in a message you didn't quote) was: 

      Except for that whole pesky name & purpose thing -- you know,
Extensible _Authentication_ Protocol.
                                         -------
The Abstract of RFC 3748 says "This document defines the Extensible
Authentication Protocol (EAP), an authentication framework which supports
multiple authentication methods.", a sentence that is repeated in virtually
every EAP-related RFC.  For some reason it _doesn't_ say "an authentication
and authorization framework" or "an authentication and configuration
management framework", which is apparently what you want it to be (it's so
convenient!).  WRT to RADIUS, the Abstract of RFC 2865 says "This document
describes a protocol for carrying authentication, authorization, and
configuration information between a Network Access Server which desires to
authenticate its links and a shared Authentication Server."  This seems to
sum up the purpose of RADIUS pretty well, as the abstract from RFC 3748 sums
up the purpose of EAP. 
 
> make, don't try to impress us with bluster.

OK, I'd appreciate the same from you (along with accurate, rather than
misleading, quoting).  BTW, while you may consider your personal opinion to
be a "substantive argument" ("I see no harm in also supporting carrying NEA
assessments in the tunnel method"), others might not.

...

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 11 Aug 2009 21:28:22 -0700

>  * machine used to authenticate

No.  Please don't confuse authentication with authorization.  The parameters
you mention above are policy-related, not related to authentication.

> password is superficially correct.  

What authentication server is that?  Not RADIUS: the semantics of the
Access-Reject message don't distinguish between failed authentication and
failed authorization.

> This is not "authorization",
> because
> the user has not been authenticated.  

A server can tell me that I'm not authorized without knowing who I am?  This
is incredibly cool technology!  Where can I get some of that?  But
seriously, the initial authorization checks made by a RADIUS server for
example are based upon so-called "simple" authentication (as used daily by
billions of humans).  Although this consists of my telling you my name & you
believing me (for the time being anyway), it is authentication all the same.

> But that information is still
> used

No, they are authorization decisions.

> of life for a certificate, issuer, etc.

I suppose so, but since all those things are typically in the cert, I don't
know why.  In any case, those things are directly related to authentication.

> perfectly secure: No one would ever be authenticated.

I have no idea what you're talking about.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 12 Aug 2009 07:13:41 +0200

> you mention above are policy-related, not related to authentication.

  You are making arbitrary distinctions between pieces of information.
Ones you like are deemed "authentication".  Ones you don't like are
deemed "authorization".

> Access-Reject message don't distinguish between failed authentication and

  This is the EMU WG, not RADIUS.  EAP has an "EAP-Failure" code.

> A server can tell me that I'm not authorized without knowing who I am?

  Yes.  A policy could state that all logins between 5pm and 9am are to
be rejected.  In that case, it can reject you without knowing (or
caring) who you are.  This process can't be "authorization", because it
can happen *before* authentication.

> I have no idea what you're talking about.  

  Explain what criteria you use to distinguish between "authentication"
data and "authorization" data.  Give a name to the policies that get
processed *before* a user is authenticated.

  Such policies exist, and are in wide use.  The NEA use of EAP falls
within this use.

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 11 Aug 2009 23:43:32 -0700

> Ones you like are deemed "authentication".  Ones you don't like are

The distinctions may be arbitrary but I'm hardly inventing them; these are
pretty standard.  And for the record, I love both Authentication and
Authorization equally; it does annoy me when people can't tell them apart,
though ;-).

>   This is the EMU WG, not RADIUS.  

Oh, yeah, thanks for reminding me.

> EAP has an "EAP-Failure" code.

It seems that here in EMU it is habitual to quote others extremely
selectively.  I guess I'll just have to get used to that; for the time
being, though, here's a little context:

<Alan DeKok>
  Authentication decisions have traditionally involved more than just
username / password checking.  Authentication decisions are also commonly
based on "pre-authorization" data, such as:

 * time of day
 * location
   * physical
   * network
 * account balance
 * past behavior

  And so on.

</Alan DeKok>

So I guess that what you are saying is that _EAP_ servers (as opposed to AAA
servers) typically use such data in making authentication decisions (not
access-control decisions or authorization decisions).  Is that correct?

> can happen *before* authentication.

OK.  So, if authentication is irrelevant to the enforcement of this policy,
how is the policy relevant to EAP?

> >> transporting the data required to make authentication decisions
> would
> >> be
> data and "authorization" data.  

Pretty obviously, authentication data is used for authentication &
authorization data are used for authorization.  Maybe I don't understand the
question: are you looking for definitions of authentication and
authorization?

? Give a name to the policies that get
> processed *before* a user is authenticated.

I don't know; what do you call it when you turn off the ringer on your phone
(to use an example similar to the one you gave above)?  The fact that you
don't answer the phone has nothing to do with who's calling (authentication)
nor whether you want to talk to them (authorization). 
 
>   Such policies exist, and are in wide use.  The NEA use of EAP falls

Again, since authentication is irrelevant to the policies, how are the
policies relevant to EAP (aside from the fact that it's just so darn
convenient)?

---

From: Alan DeKok <[email-masked]>
Date: Wed, 12 Aug 2009 10:07:56 +0200

> nor whether you want to talk to them (authorization). 

  Using that analogy: what do you call a policy that has you turning
your cell phone off when in one place, and on again in another?  It's
not authentication, because you don't care who's calling.  It's not
authorization, because no one is being authenticated.

> policies relevant to EAP (aside from the fact that it's just so darn

  To use NEA as an example, the decision about whether or not to return
"success" or "fail" depends on information OTHER than strictly a
username/password check.  This information is called "authentication
credentials", which can be:

  1) username / password (PAP)
  2) client certificate (TLS-based methods)
    * issuer
    * expiry
    * etc.
  3) machine status, etc. (NEA)

  I find it curious that you're willing to accept the first two as being
acceptable for authentication, but not the third.

  How do you determine that "X" is acceptable as an authentication
credential, but "Y" is not?  A clear explanation of the method is most
welcome.

  Your presentation so far has been "Glen says it's OK", or "Glen says
it's not OK".  That isn't anything we can put into a specification.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 12 Aug 2009 12:15:15 +0200

...
> open issues with the draft.

  I believe that this feature is useful enough to warrant mentioning in
the draft.

  If there is objection, we can have a WG consensus call on this issue.

  Alan DeKok.

---

From: Stephen Hanna <[email-masked]>
Date: Wed, 12 Aug 2009 07:03:48 -0400

Glen,

Thanks for clarifying your position. I believe that your argument is
that because EAP is an "authentication framework", it should not be
allowed to carry anything other than authentication protocols.
Is that correct? My apologies if this is not quite right. I am
having some difficulty finding a crisp summary of your position
in your emails. Please feel free to clarify your point of view.

I would argue that an "authentication framework" should not just be
concerned with verifying the EAP peer's identity. EAP should also
include other elements relevant to the authentication process and
the decision about whether to grant network access. For example,
password change requests should be allowed. Channel bindings are
another example. Having the peer send information about the NAS to
the EAP server allows the server to warn the peer about a lying NAS.
It also helps the server decide whether the peer is authorized to
obtain the requested network service. Performing a NEA assessment
helps the server decide whether the peer is secure enough to connect
to the network.

I suppose that my basic argument is a practical one. Password change,
channel bindings, and NEA assessments are useful things to do during
the EAP exchange. They are relevant to the authentication process and
the server's decision about whether to grant network access. There is
no harm in doing them as part of the EAP exchange. And there is no
better way to implement them. Would you like to argue with any of
these assertions?

Thanks,

Steve

---

From: "Dave Nelson" <[email-masked]>
Date: Wed, 12 Aug 2009 09:15:04 -0400

Alan DeKok writes...

>   Yes.  A policy could state that all logins between 5pm
> and 9am are to be rejected.  In that case, it can reject
> you without knowing (or caring) who you are.  This process
> can't be "authorization", because it can happen *before* 
> authentication.

I hate to jump into the heated debates over terminology, but I have to
support Glen in this case.  Alan, I'm sorry, you're simply mistaken about
this.

Authentication is "proof of identity", i.e., it's about who you are.
Authorization is about "access control policy", i.e., what you may do.  In
the example that you cite above, the action is clearly authorization.  The
server is enforcing the "access control policy" that the "wildcard" user is
prohibited from logging in during the hours of 5 PM and 9 AM.  This
authorization action *was* preceded by an implicit authentication action.
It's just that the "wildcard" user, i.e., anyone on the planet, can easily
be authenticated without the exchange of credentials.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 12 Aug 2009 15:32:10 +0200

Dave Nelson wrote:
> the example that you cite above, the action is clearly authorization.

  I've been told that it's impossible to call that process
authorization, because the user has not yet been authenticated.

  I would suggest that a common terminology be used.  Changing the
meaning of terms mid-discussion is not appropriate.

>  The

  This is the first I've heard of an "implicit authentication action" in
this context.

> be authenticated without the exchange of credentials. 

  We're arguing over semantics.  No matter which semantics I choose, I
get old I'm using them incorrectly.  Stop nit-picking over the details,
and pay attention to the *requirements* and *use-cases* that I have
outlined.

  There is information that can be carried in EAP.  Depending on who you
are, it's called "authentication credentials", or "authorization data",
or "damned if I know".  Depending on who you are, the process of
checking it is called "authorization" or "authentication" or "implicit
authentication", or "something magic".  Depending on who you are, it is
"inappropriate" or "useful" to carry that information in EAP.

  If we can't agree on a consistent set of terminology, perhaps you
could give your opinion on *what* information is being carried in EAP,
and whether or not that information is useful or inappropriate.

  My opinion has been clear and consistent: Authenticators would like to
know certain information before returning "success" or "fail" in EAP.
Within some limitations, where that information can be carried in EAP, I
believe it is appropriate and useful to carry it in EAP.

  Alan DeKok.

---

From: "Hoeper Katrin-QWKN37" <[email-masked]>
Date: Wed, 12 Aug 2009 09:38:10 -0400

> From: Alan DeKok [mailto:[email-masked]]
> Sent: Wednesday, August 12, 2009 5:15 AM
> To: Hoeper Katrin-QWKN37
> Cc: Stephen Hanna; Glen Zorn; [email-masked]
[KH] I like this idea! Let's do it :)

---

From: "Dave Nelson" <[email-masked]>
Date: Wed, 12 Aug 2009 09:33:03 -0400

Stephen Hanna writes...

> I suppose that my basic argument is a practical one. Password
> change, channel bindings, and NEA assessments are useful things
> to do during the EAP exchange.

That much I think most of us would agree with.  EAP is a convenient protocol
to use for exchanging that kind of information, even if it's stretching the
original purpose of EAP.  Remember, EAP was to be used during the
authentication phase of PPP.

> They are relevant to the authentication process and the server's
> decision about whether to grant network access. 

I really hate to have to agree with Glen's position on this, but I do.  I
firmly believe that you, and others, are conflating elements of
authorization into the meaning of authentication.  Authentication is about
proof of identity.  I can be authenticated as Dave Nelson, by various means.
I'm still Dave Nelson whether I'm a good guy or a bad guy.  If I'm a bad
guy, you may not want to grant me access to your home.  If I'm a good guy,
but an active carrier for Swine Flue, you still may not want to grant me
access to your home.  In any case I'm still Dave Nelson, and none of the
other "access control" considerations affect my proof of identity.  All
those other considerations are authorization considerations, not
authentication considerations.

I agree that using words clearly and with their exact meaning is important.

However, it appears that the real point of this semantic debate is whether
the "domain of applicability" for EAP will admit the introduction on very
useful, but clearly non-authentication, data elements.  It's quite possible
for the WG to have consensus to do so and at the same time be in apparent
conflict with the "domain of applicability" for EAP.  Of course, maybe the
WG has within its charter the authority to revise the "domain of
applicability" for EAP.

> There is no harm in doing them as part of the EAP exchange. And there
> is no better way to implement them. 

Assuming that's true -- and it may well be -- then EMU ought to expand the
definition of EAP to explicitly include authorization related data, rather
than making semantic, re-definitional, arguments that the authorization data
is really authentication data.

---

From: "Dave Nelson" <[email-masked]>
Date: Wed, 12 Aug 2009 10:04:04 -0400

Alan DeKok writes...

>   This is the first I've heard of an "implicit authentication 
> action" in this context.

We have NULL cipher-suites, why can't we have NULL authentication methods?  
 
>   We're arguing over semantics.

Yes.

> Depending on who you are, it is "inappropriate" or "useful" to carry
> that information in EAP.

My opinion is that is both "useful" *and* "inappropriate".  See my recent
response to Steve Hanna's post.  I think that either the EMU WG or NEA WG
needs to seek to amend the "domain of applicability" for EAP to explicitly
include transport of authorization-related data, and be done with it.
That's the straightforward approach.   It avoids the need to cling to
alternate definitions of well understood terms.  If you need to re-charter
to gain that authority, then so be it.  IMHO, this whole discussion looks
like an end-run around the "domain of applicability" restrictions for EAP.

Shall we take the high road here?  At the very least, you could seek
clarification from the IESG as to whether they think that the current
"domain of applicability" for EAP embraces the "additional data" you want to
include.  After all, enforcement of "applicability statements" is a very hit
or miss thing in the IETF.  You may get lucky.  :-)

---

From: Alan DeKok <[email-masked]>
Date: Wed, 12 Aug 2009 16:43:00 +0200

> We have NULL cipher-suites, why can't we have NULL authentication methods?  

  Yes, but it means we are far afield of the original discussion.

> include transport of authorization-related data, and be done with it.

  That's clear enough.

> like an end-run around the "domain of applicability" restrictions for EAP.

  I agree it does look that way.  I don't even think that's a wrong
characterization of the issue.

> or miss thing in the IETF.  You may get lucky.  :-)

  I would prefer to get WG consensus first.  If the WG believes it's a
good idea, the re-chartering process becomes simpler.

  Alan DeKok.

---

From: "Dave Nelson" <[email-masked]>
Date: Wed, 12 Aug 2009 14:18:24 -0400

Bret Jordan writes...

> Now EAP back in the day may have been the brain child of
> simple authentication for PPP links. However, today we need
> to look into what is really needed to enforce Security Policies
> on networks. It is my belief that regardless of the legacy name
> given to the protocol, EAP, EAP makes a great transport for
> dealing with the age old questions "is this user who they say they
> are" which has been expanded in recent years to be, "is this user
> who they say they are and are they using a company owned system 
> in the right part of the building at the right time of day). 

It's not simply about legacies and names. It's about the rules for protocol
usage.  In the IETF these rules are typically called "applicability
statements".  These limit the area of intended use for a given protocol.
This is not about what's implied by the name, it's about whether we follow
the rules or attempt to circumvent them.  All I'm suggesting is that we
address the rule head on, instead of attempting to dance around it.  

> Even though the ID badge is valid. The ID badge grants the 
> holder to access certain resources, but the Security Guard
> through visual inspection is able to make a better determination
> of are these authentication credentials valid.

Such procedures and meta-data are indeed related to authentication.
However, that's not to say that *all* network access control policy is
authentication meta-data.  Some is; some isn't.

> It is not that I am not authorized to use the systems at weird
> hours, the system just knows that it is out side my normal usage
> times and thus it may need to ask me follow up questions to verify
> that I really am who I say I am.  This is all about authentication.

Well, that might be, but there is absolutely no reason that your normal
hours of employment need to be communicated in an EAP message.  In fact, it
would seem much a more reasonable design that the AAA server's database
contains such access control policies.  I think your argument about the need
for additional authentication meta-data is reasonable, but does not on face
value justify the need to send that meta-data between an EAP client and EAP
server.

---

From: Stephen Hanna <[email-masked]>
Date: Wed, 12 Aug 2009 14:52:46 -0400

There are various definitions of authentication. One could
argue for the broad definition included in RFC 4949:

   $ authentication
      (I) The process of verifying a claim that a system entity or
      system resource has a certain attribute value.

Password change, channel bindings, and NEA assessments could be
included in that definition.

However, I agree that it would be better to get IESG clarification
that carrying authorization data in EAP is permissible. As Alan
suggested, the first step is probably to have a WG consensus
check to verify that we have rough consensus that this should
be permitted. After that, maybe we would ask the IESG for a
clarification of the applicability statement for EAP.

I will note that the IESG has already approved a change to the
EMU charter to add a work item for channel bindings. So they
have already indicated their support for that effort.

Thanks,

Steve

> Behalf Of Dave Nelson
> Sent: Wednesday, August 12, 2009 9:33 AM
> To: [email-masked]

---

From: Bret Jordan <[email-masked]>
Date: Wed, 12 Aug 2009 12:00:36 -0600

Dave et all,

I agree that Authentication in the truest sense of the term is about knowing
and verifying who someone is or what something is (you can authenticate
things in addition to people). Also remember that authentication is NOT
restricted to just usernames and passwords. If we look at a business as a
whole, not just the IT network there are lots of different types of data
that can be used as authentication credentials. Things from fingerprints,
retinal scans, facial recognition, stored CERT, hidden values in the
registry of Windows boxes, simple host based names, ID badges or labels,
stickers on the rear window of a car, etc can all be used as authentication
in the business. Some of these are viewed as really weak forms of
authentication and others as really strong, but the point is that everything
from strong to really weak data can be used for authentication. It all
depends on your appetite for risk.

Given EAP and 802.1X it can also interesting to authentication a system at
the same time you authenticate a user. One use case is to make sure that a
said computer is one of the company owned computers or looks enough like a
company owned computer to be acceptable. You may assess that the computer is
company owned computer if it has some hidden regkey, it has a certain
vendor's MAC address, it has a hidden file on the filesystem or that the
system is fully compliant with the Security Policy of the organization. This
is not Authorization of the computer to the network but is verifying that
the computer is a company owned or a system that is deemed to look enough
like a company owned system to be allowed access to the network, which is
authentication.

Now EAP back in the day may have been the brain child of simple
authentication for PPP links. However, today we need to look into what is
really needed to enforce Security Policies on networks. It is my belief that
regardless of the legacy name given to the protocol, EAP, EAP makes a great
transport for dealing with the age old questions "is this user who they say
they are" which has been expanded in recent years to be, "is this user who
they say they are and are they using a company owned system in the right
part of the building at the right time of day). Yes the later half of the
second age old question is a mix of authentication and authorization, but
this is the world we live in, for better or worse.

NEA and other attributes/data tunneled inside of EAP allow the
authentication server and thus the business make more educated decisions
about whether or not someone is who they say they are or a machine is what
it says it is. This is authentication. Think of this in the terms of the
security guard that checks ID badges when you enter the building. If a
homeless person, all dressed in rags walks in to Chase Bank headquarters
with a valid ID badge, the Security Guard will probably not trust his
authentication, the ID badge. Even though the ID badge is valid. The ID
badge grants the holder to access certain resources, but the Security Guard
through visual inspection is able to make a better determination of are
these authentication credentials valid. The username / password presented is
often not enough to guarantee that the user is who the user says they are. A
business may want to make sure they are using a certain computer, the
computer is in a certain location, the computer is being used a certain time
of day, and the computer has certain things, before they grant network
access. This is NOT authorization. It is all about making sure people are
really and honestly who they say they are.  Some businesses and government
agencies build profiles of work habits.  So if I try to use my
username/password after what is deemed my normal work patterns, that
username/password is not accepted.  It is not that I am not authorized to
use the systems at weird hours, the system just knows that it is out side my
normal usage times and thus it may need to ask me follow up questions to
verify that I really am who I say I am.  This is all about authentication.

Bret

---

From: Bret Jordan <[email-masked]>
Date: Wed, 12 Aug 2009 14:47:20 -0600

It looks like my first attempt at responding did not work due to send-from
email address problems.  If this comes through twice, I apologize in
advance.

Dave et all,

Bret

-- 

---------------------------------------------------------------------------------
Bret Jordan CISSP
Treasurer, OpenSEA Alliance
[email-masked]
---------------------------------------------------------------------------------
"Without cryptography vihv vivc ce xhrnrw, however,
the only thing that can not be unscrambled is an egg."

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 12 Aug 2009 15:59:44 -0700

> be authenticated without the exchange of credentials.

I don't actually think that we need to invent a NULL authentication type
here: there is no authentication nor any authorization in this case, there
is just a fixed policy.  There are lots of policies that are unrelated to
both authentication and authorization, including policies controlling
network access.  For example, it might be a corporation's policy not to put
Ethernet ports in conference rooms, so unless your laptop have a wireless
interface, no network access.  This policy has nothing to do with either
authentication or authorization, only with having the right equipment (not
unlike NEA).

---

From: Stefan Winter <[email-masked]>
Date: Thu, 13 Aug 2009 08:27:50 +0200

Hello,

> characterization of the issue.

It also reminds me of the discussion in radext prior to the last
re-charter, when "No new security mechanisms will be defined for RADIUS"
but at the same time crypto-agility and keywrap lay on the table. There
were lengthy and at times seemingly far-fetched arguments on why this
would or would not be permitted by the charter. In the end, things were
clarified by issuing a new charter and everybody lived happily ever
after (well, sortof ...).

> good idea, the re-chartering process becomes simpler.

I think it's a good idea to acknowledge the reality that transport of
authorization data happens right now in EAP methods.
I also think it's a good idea to have both authentication and
authorization data in EAP.
If a re-charter were to acknowledge that EMU is also allowed to work on
authorization, I think we might end up with a way cleaner, proper
approach to handle authorization in EAP (which might end Dave's
perceived inappropriateness of it). Having an encrypted channel to
exchange authorization information post-authentication, even if the
authentication does not set up a tunnel for it comes to mind. That way,
the EAP conversation could for example always carry NEA information,
agnostic of the protocol used in the prior authentication phase.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 13 Aug 2009 12:24:43 -0700

There have been a lot of proposals about EAP and authorization in the
past.  At its very basis EAP performs authentication at the time of
service access and the data resulting from the authentication can then
be used for authorization and accounting purposes.  Some of the
proposals attempt to enhance this in various ways.  

One way is to carry additional data for use in the authorization
process.  EAP channel bindings are perhaps the simplest form of
authorization data proposed for EAP.  The authorization data is directly
related to the service which is performing the authentication, at the
time of authentication and the exchange is relatively simple; data sent
from client and result response from server.  This exchange helps to
ensure that an authenticator isn't trying to provide services that it is
not authorized to.   I don't see much purpose in channel bindings if
they are not used for authorization or accounting for later forensic
analysis of authorization after the event. 

There are other types of data that may be collected for authorization.
One example is the validation of the "security posture" of the peer in
which information about the peers compliance with a particular policy is
collected.  This example may require the exchange of more data and
require more complex exchanges than channel bindings.  This process may
even involve authentication.  

There are other ways in which EAP has proposed authorization
enhancements.  Other proposals have dealt with requesting authorizations
for or providing authorization data to services other than the one that
is performing the authentication.  In addition proposals have discussed
authorization after the initial authentication to the service.  

I think carrying channel bindings within EAP is useful and necessary.  I
believe it is also reasonable to carry other exchanges to establish data
for authorization.  However, I think there are some limitations.  For
example carrying large amounts of data is probably not a good thing.  I
also think we have to be careful to not leave end stations with the only
means to communicate is through EAP.  I don't think we should be
applying patches or browsing the web through EAP (I don't think anyone
is proposing this, but I'm not certain).   This means that a some point
other communication channels have to be established to perform these
functions.  

When we get into the realm of using EAP for establishing authorization
data for other services, requesting authorization or invoking
authorization at times other than authentication I think there is a much
bigger gray area.  

Joe

> Behalf Of Alper Yegin
> Sent: Friday, August 07, 2009 6:31 AM
> To: [email-masked]
> Subject: [Emu] EAP and authorization
> 
> This issue came up during the last IETF meeting when the WG 
> discussed channel binding.
> 
>  
> 
> - A document that defines EAP channel bindings and provides 
> guidance for establishing EAP channel bindings within EAP methods.
> 
>  
> 
>  
> 
> - A mechanism to support extensible communication within a 
> TLS protected tunnel.
> 
>  
> 
>  
> 
> I'm not against this. But let's face it, this is venturing 
> into dealing with authorization parameters with EAP (EAP 
> layer? EAP method layer? Etc.) I'm not against that either. 
> In fact, I know there are a lot of people who'd be happy to 
> see that happen. 
> 
>  
> 
> So, my question is, is this what we are doing: Enabling EAP 
> to exchange authorization parameters among the EAP peer - 
> authenticator - authentication server? If not, I hope someone 
> can explain how this is different than what it takes to solve 
> channel binding problem.
> 
>  
> 
> Thanks.
> 
>  
> 
> Alper
> 
>  
> 
>  
> 
>

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 13 Aug 2009 12:24:43 -0700

Joe

---

From: Alan DeKok <[email-masked]>
Date: Fri, 14 Aug 2009 08:16:27 +0200

> authorization after the initial authentication to the service.  

  I think part of the concern here is that authorization has
traditionally involved the PDP telling the PEP how the user should be
treated.  The proposals on the table for EAP do not communicate
authorization information over EAP to the PEP.  As such, they do not fit
well into the traditional model.

> for authorization.

  ... of who, to what?  This could be made clearer in the document.

>  However, I think there are some limitations.  For
> is proposing this, but I'm not certain).

  I can propose EAP-IP: carrying IP packets in EAP.  It's crazy, but
possible.  The main limitation on bulk data transfer is that most EAP to
RADIUS gateways (AP's, etc.) will terminate an EAP session after ~50
packets.

> authorization at times other than authentication I think there is a much

  ERP is leveraging EAP to obtain authentication and authorization at
later points in time.  This seems to be acceptable.

  Alan DeKok.

---

From: "Dan Harkins" <[email-masked]>
Date: Sun, 16 Aug 2009 00:30:00 -0700 (PDT)

Hi Steve,

  I don't think what you're talking about falls into the definition
of "channel binding", at least not the one I have, and I wouldn't be
surprised if others (like maybe people on the IESG) agree. And I
agree with Dave, and Glen, that this isn't authentication either.

  "channel bindings" are supposed to solve the lying NAS problem*
which is an issue of authentication (is this guy really who he claims
to be?). What you want to do is use the EAP tunnel to transfer other
kinds of data to do NEA posture checking. And, yes, we should determine
whether it is permissible for EMU to work on such a thing. What we
shouldn't do is say that it's really part of "authentication" or it's
part of "channel binding" and just proceed.

  Dan.

 *the example given, at the Philly IETF I think, was of a Russian
mobile phone operator that made its cell towers broadcast out that
they were actually from an Estonian mobile phone operator and then
billed Estonians whose phones connected to them (even when they had
manual network selection turned on to intentionally avoid accidentially
connecting to the Russian network) as if they were roaming on the
Russian network.

---

From: Alan DeKok <[email-masked]>
Date: Sun, 16 Aug 2009 10:09:33 +0200

> part of "channel binding" and just proceed.

  My question again is where do we draw the line?  What information is
permissible as authentication credentials, and what isn't permissible?

  And why?

  Some sites determine that username/password authentication is
sufficient.  Others also require that the MAC be known, too.  Is the MAC
part of the authentication credentials?  Or is the site doing "posture
checking" by requiring that the MAC be known?

  We need to achieve a common understanding before making any decisions.

> connecting to the Russian network) as if they were roaming on the

  That is largely an issue of fraud, and best *resolved* through legal
methods.  But channel bindings may permit the end user to *detect* the
fraud, at least.

  Alan DeKok.

---

From: "Dan Harkins" <[email-masked]>
Date: Sun, 16 Aug 2009 09:06:42 -0700 (PDT)

Hi Alan,

> permissible as authentication credentials, and what isn't permissible?

  Authentication has to do with proving an identity. Authorization has
to do with determining whether that proven identity is "good" or "bad".

>   And why?

  Because it helps answer questions like "why isn't this part of
authentication?"

> checking" by requiring that the MAC be known?

  I'm not sure what sites do what but I'm not aware of an EAP method
that checks a username and a password AND a MAC address.

  If the policy says, "Alan DeKok is only allowed to access the network if
he's on 00:01:02:03:04:05" then the MAC address is not an authentication
credential because the username and password are deciding the identity and
the MAC address is deciding whether that authenticated identity is "good"
or "bad".

>   We need to achieve a common understanding before making any decisions.

  Yes, but I hope it's not by going through a hundred or so different
things and gauging consensus on "is it authentication or authorization?"
Ask yourself, what is the identity of this peer and is this thing critical
to proving that identity or not? If it is critical to proving the identity
(like a CA certificate to perform validation of the peer's certificate,
for instance) then it's for authentication, otherwise it's not for
authentication.

  Channel bindings are subtly different. Since a 2-party protocol is being
used with 3 parties it is necessary to ensure that all 3 parties have a
consistent view of all 3 identities. But that's still an authentication
problem-- is this 3rd entity really who it says it is?

  Dan.

---

From: Stephen Hanna <[email-masked]>
Date: Sun, 16 Aug 2009 12:43:51 -0400

Actually, in the email that you responded to, I was referring to
the EMU working group item in the current charter:

I hope that we can both agree that this falls within our definition
of "channel binding". Otherwise, we really have a communication
failure! ;-)

I do not agree that EAP channel bindings are about
authentication. They have two parts: checking whether
the NAS is advertising services that it's not
authorized to advertise and using information from
the NAS (like which SSID the peer is trying to
connect to) to supplement the AAA server's decision
about whether to grant the requested access.
Both of these are authorization decisions and they
are made not based on authenticating the NAS (which
we have had for many years in the form of the secret
shared between the NAS and the AAA server) but on
supplementary information about the SSIDs and other
things being advertised by the NAS and requested by
the EAP peer.

I agree that NEA assessments are a different topic.
They're not the same as channel bindings. I'd say
that the data conveyed in EAP for channel bindings
and for NEA assessments are both authorization data
in that they are not authentication protocols but
supplementary data that the AAA server will use in
deciding whether access should be granted (and maybe
whether other action should be taken, like getting
the lying NAS repaired or sending remediation
instructions to an unhealthy endpoint).

Thanks,

Steve

> From: Dan Harkins [mailto:[email-masked]] 
> Sent: Sunday, August 16, 2009 3:30 AM
> To: Stephen Hanna
> Cc: Dave Nelson; [email-masked]

---

From: Alan DeKok <[email-masked]>
Date: Sun, 16 Aug 2009 20:01:18 +0200

> to do with determining whether that proven identity is "good" or "bad".

  That's a clear explanation.

> that checks a username and a password AND a MAC address.

  Bare EAP, no.  But it's possible to put a MAC into a field of a client
cert, and then to compare the MAC received via EAP-TLS against the MAC
received in the same RADIUS packet.  In this case, the MAC is part of
the identity.

> problem-- is this 3rd entity really who it says it is?

  ... and is he authorized to provide the services he's claiming to offer.

  Are we really authenticating the NAS, and then authorizing it, by
passing tunneled data in EAP?  Do we really want to go down that path?

  Alan DeKok.

---

From: "Dan Harkins" <[email-masked]>
Date: Sun, 16 Aug 2009 12:43:47 -0700 (PDT)

Hi Steve,

> things being advertised by the NAS and requested by

  The problem with your definition of channel bindings is that it
completely ignores the lying NAS problem. An identity is not a service
that a NAS can be authorized to provide that is checked after
authentication has completed.

  When there are 3 parties involved in this 2 party protocol it is
justified by saying that the EAP server trusts the NAS so there is no
security issue when MSK is disclosed to it. But what NAS identity does
the EAP server trust? The peer and EAP server derive a shared key and
for the key to be disclosed to another entity the peer and EAP server
must have a consistent view of the identity of that entity. If they cannot
arrive at a consistent view of all identities then the protocol deriving
the key fails. That is not an authorization issue, it's an authentication
issue.

> instructions to an unhealthy endpoint).

  "Repair" the lying NAS after authentication? Whoa! If authentication
does not fail because a lying NAS was detected then there is a huge
security problem.

  You seem to be conflating authentication and authorization because
a "AAA server" might use information from both steps in deciding whether
access is granted or not. An EAP server asks "who are you?" and then
proceeds to prove the identity it is told using a method of its choice.
If the EAP method derives keys the keys have to be bound to a consistent
view of the identities involved in the communication (including the NAS
identity). If the EAP server is successful in proving that the peer really
is the identity it claimed (and the key is successfully bound to a
consistent view of all identities) there can still be other, supplementary,
things to consider before deciding to grant access or not-- time-of-day,
location, up-to-date anti-virus software, etc. But those other,
supplementary, things are not EAP, which is why you're mentioning a "AAA
server" and not an "EAP server".

  We might want to make them part of EAP since EAP is the only protocol
allowed prior to the access decision being made and it's attractive to
pass arbitrary data encapsulated in EAP. But I think it's wrong to say
that NEA assessments can piggy back in because the door is being held
open for channel bindings.

  Dan.

---

From: Stephen Hanna <[email-masked]>
Date: Sun, 16 Aug 2009 21:18:55 -0400

> authentication has completed.

After carefully reviewing again the list of attributes
verified by draft-ietf-emu-chbind-03.txt, I would agree
that several of them are related to the NAS identity:
NAS-IP-Address, Called-Station-Id (the MAC part), and
NAS-Identifier. Some are related to the identity of
the network to which the NAS claims to provide access
or to the mobility domain of which it is a part:
Called-Station-Id (the SSID part) and Mobility-Domain-Id.
For those, I agree that we can call them authentication
since the main purpose of channel bindings is to verify
that the identity claimed by the NAS to the EAP peer is
acceptable (although SSID and Mobility-Domain-Id are
not really NAS identity but network identity).

If/when the AAA server uses the SSID to decide whether
a user is authorized to connect to that SSID, there's
definitely authorization taking place but one can argue
that the primary reason to convey this attribute in
channel bindings is to verify the network identity
claimed by the NAS to the EAP peer. So let's overlook
this authorization aspect.

However, I wonder if you really want to claim that
the Cost-Information AVP is part of the NAS identity.
That seems to be clearly not. Do you want to claim
that this is part of the network identity? That seems
to be a stretch. Really, I think that this is an
attribute of the network (or one could say an
advertisement) that is being verified.

> does not fail because a lying NAS was detected then there is a huge

I agree that authentication should not succeed if a
lying NAS is detected. I didn't say otherwise. I said
that you might want to repair a lying NAS. Of course,
"repair" would mainly apply if it's your equipment.
If it's a rogue NAS, you might want to find it and
smash it with a sledgehammer. ;-)

> You seem to be conflating authentication and authorization
> because a "AAA server" might use information from both steps
> in deciding whether access is granted or not. An EAP server
> asks "who are you?" and then proceeds to prove the identity
> it is told using a method of its choice. If the EAP method
> derives keys the keys have to be bound to a consistent
> view of the identities involved in the communication 
> (including the NAS identity). If the EAP server is successful
> in proving that the peer really is the identity it claimed
> (and the key is successfully bound to a consistent view of
> all identities) there can still be other, supplementary,
> things to consider before deciding to grant access or not-- 
> time-of-day, location, up-to-date anti-virus software, etc.
> But those other, supplementary, things are not EAP, which
> is why you're mentioning a "AAA server" and not an "EAP server".
> 
> We might want to make them part of EAP since EAP is the only
> protocol allowed prior to the access decision being made and
> it's attractive to pass arbitrary data encapsulated in EAP.
> But I think it's wrong to say that NEA assessments can piggy
> back in because the door is being held open for channel bindings.

I am not trying to conflate authentication and authorization.
I recognize that these are two different things and I think
that it will help us to have a clear definition of each.
That should help us decide whether we want to allow some
authorization data to travel over EAP. You wrote:

> Authentication has to do with proving an identity. Authorization
> has to do with determining whether that proven identity is
> "good" or "bad".

I agree with the gist of your definition of authentication.
We might more precisely define authentication as:

  the process of verifying a claim that an entity has a certain
  identity

However, I think that your definition of authorization is a bit
too loose. A perfectly good person should not be authorized to
access someone else's records. I suggest that we use this
definition of authorization from RFC 4949:

      1b. (I) A process for granting approval to a system entity to
      access a system resource.

I agree that EAP was originally defined solely for the purpose
of authentication. I agree that it is wise for us to consider
carefully whether we want to also allow it to be used to carry
information that is useful in authorization. While I believe that
this is a good idea, I think that we'll want to continue to place
constraints on the amount and kind of data that should be
conveyed over EAP. EAP is not a bulk data transfer protocol
and it should not be used as one. That will only result in
heartache for all involved (due to the limit of one packet
in flight at any time, the frequently long round trip times
when RADIUS proxies are used, and the short timeouts given
by many NASs, among other issues).

Thanks,

Steve

---

From: Bret Jordan <[email-masked]>
Date: Sun, 16 Aug 2009 23:02:21 -0600

All,

> by many NASs, among other issues).
 At some level we need to really consider some level of enhanced
authentication meta-data to flow over the EAP session. I would still argue
that it is not all really authorization in the traditional sense.  There is
a big fat gray area these days.  Organizations are looking at using these
traditioinal chunks of data to make more educated authenitcation decisions.
Simply trusting a username/password is not longer sufficient.  We want to be
able to make sure the person is using the computer that was assigned to
them, the computer is still fully compliant with security policy, the user
is in the office that was assigned to them, and a slew of other things.  If
all of these and the stars align just right, then we will authenticate them
to the network and then they can be granted network access and normal
network authorization processes can take place through processes and
protocols that exist or will be created.

Bret

---

From: Qin Wu <[email-masked]>
Date: Mon, 17 Aug 2009 15:59:56 +0800

Hi, Alan:
----- Original Message ----- 
From: "Alan DeKok" <[email-masked]>
To: "Joseph Salowey (jsalowey)" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, August 14, 2009 2:16 PM
Subject: Re: [Emu] EAP and authorization

> RADIUS gateways (AP's, etc.) will terminate an EAP session after ~50

[Qin] Why not carry EAP over Http, in this way, you can browse Web through EAP.
Actually there are still other way for Web Authentication, e.g., SIP.

> later points in time.  This seems to be acceptable.

[Qin]: I agree that the authorization is well integrated into ERP authentication. 
However these authorization data (i.e., authorization indication described in section 5.3.4 of ERP)
is only limited to Called-Station-Id ,Calling-Station-Id , NAS-Identifier, NAS-IP-address, NAS-IPv6-address which is listed in RFC3748.
What's more, ERP has nothing to do with EAP method.

---

From: Qin Wu <[email-masked]>
Date: Mon, 17 Aug 2009 16:29:07 +0800

> be used for authorization and accounting purposes.  

[Qin]: So the data resulting from the authentication not only can be used in the authentication,
but also can be used in authorization. I wonder what it is called as, authentication data or 
authorization data?
On the other hand, the data resulting from authorization also can be used in the second authentication.
e.g., PEAP uses TLS to create an encrypted tunnel from the authentication server to the supplicant after verifying the identity of the authentication server.
 Once the encrypted tunnel is established, a second EAP authorization process occurs inside the tunnel to extend the TLS connection. Any implemented EAP authorization type (tokens, passwords, certificates, etc.) can be used as the client is authenticated in the second EAP authentication process running inside the TLS connection.
As regarding these data from authorization, what is it called as, authentication data or authorization data?

>Some of the proposals attempt to enhance this in various ways.

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 17 Aug 2009 09:19:30 -0700

Dan Harkins [mailto://[email-masked]] writes:

...

> An EAP server asks "who are you?" and then
> allowed prior to the access decision being made 

Yes, it is, but it doesn't have to be.  In IEEE 802.1X-2004, for example,
the transition from the "Authenticating" state to the "Authenticated" state
in the PAE machine is triggered by the reception of an Accept message from
the Back-end authentication server, not by EAP-Success.  In fact, great
pains are taken to ensure that the "correct" EAP message (Success or
Failure) is sent to the supplicant, the correctness being based not on the
actual result of the EAP authentication but on the decision of the AAA
server.

> and it's attractive to
> pass arbitrary data encapsulated in EAP. 

Actually, the only thing that's attractive about it (IMHO) is the fact that
it is there.  There are huge disadvantages to using EAP in this way that
could be removed were a new protocol be designed for this purpose.

...

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 17 Aug 2009 16:32:26 -0700

> Sent: Thursday, August 13, 2009 11:16 PM
> To: Joseph Salowey (jsalowey)
> Cc: Alper Yegin; [email-masked]
> > enhancements.  Other proposals have dealt with requesting 
> > authorizations for or providing authorization data to 
> services other 
> > than the one that is performing the authentication.  In addition 
> > proposals have discussed authorization after the initial 
> authentication to the service.
> 
> traditionally involved the PDP telling the PEP how the user 
> should be treated.  The proposals on the table for EAP do not 
> communicate authorization information over EAP to the PEP.  
> As such, they do not fit well into the traditional model.
> 
[Joe] In the traditional Model, peer entity authentication is performed
and the identity information is communicated over EAP to the PDP.  The
PDP uses this information to make authorization decisions which are
communicated to the PEP.  I don't think the proposals of this type
differ from this model except that the information that is established
is not strictly identity information.  The information collected may
have different security properties than the authenticated data. 

> > I think carrying channel bindings within EAP is useful and 
> necessary.  
> > I believe it is also reasonable to carry other exchanges to 
> establish 
> > data for authorization.
> 
[Joe] I don't think a general discussion of authorization belongs in the
channel bindings document.  Channel bindings is much smaller scope than
the general authorization problem. Is there something about channel
bindings that is unclear in the document?  

> >  However, I think there are some limitations.  For example carrying 
> > large amounts of data is probably not a good thing.  I also 
> think we 
> > have to be careful to not leave end stations with the only means to 
> > communicate is through EAP.  I don't think we should be applying 
> > patches or browsing the web through EAP (I don't think anyone is 
> > proposing this, but I'm not certain).
> 
>   I can propose EAP-IP: carrying IP packets in EAP.  It's 
> crazy, but possible.  The main limitation on bulk data 
> transfer is that most EAP to RADIUS gateways (AP's, etc.) 
> will terminate an EAP session after ~50 packets.
> 
[Joe] There are a great many things that are possible and even
practiced, this does not make them wise.  We have several good transport
protocols for carrying bulk data.  EAP is not one of them.  

> > authorization at times other than authentication I think there is a 
> > much bigger gray area.
> 
>   ERP is leveraging EAP to obtain authentication and 
> authorization at later points in time.  This seems to be acceptable.
> 
[Joe] Yes, I agree there seems to be some precedence here, but the use
cases may vary from the handover case.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 17 Aug 2009 16:46:25 -0700

> From: Qin Wu [mailto:[email-masked]] 
> Sent: Monday, August 17, 2009 1:29 AM
> To: Joseph Salowey (jsalowey); Alper Yegin; [email-masked]
> [Qin]: So the data resulting from the authentication not only 
> can be used in the authentication, but also can be used in 
> authorization. I wonder what it is called as, authentication 
> data or authorization data?
> On the other hand, the data resulting from authorization also 
> can be used in the second authentication.
> e.g., PEAP uses TLS to create an encrypted tunnel from the 
> authentication server to the supplicant after verifying the 
> identity of the authentication server.
>  Once the encrypted tunnel is established, a second EAP 
> authorization process occurs inside the tunnel to extend the 
> TLS connection. Any implemented EAP authorization type 
> (tokens, passwords, certificates, etc.) can be used as the 
> client is authenticated in the second EAP authentication 
> process running inside the TLS connection.
> As regarding these data from authorization, what is it called 
> as, authentication data or authorization data?
> 
[Joe] The differences are subtle and I have used the terms somewhat
loosely.  If you want to get detailed then authentication data is
exchanged to validate data as originating from a particular source.
Often what is authenticated is a peer's identity, but other attributes
may be authenticated as well (attributes in a certificate for example).
The authenticity of these attributes may be validated with varying
degrees of certainty.  The resulting information that is collected
becomes the authorization data used to make authorization decisions.  

> >authorization data proposed for EAP.  The authorization data is 
> >directly  related to the service which is performing the 
> >authentication, at the  time of authentication and the exchange is 
> >relatively simple; data sent  from client and result response from 
> >server.  This exchange helps to  ensure that an 
> authenticator isn't trying to provide services that it is