Steve Hanna said:
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.
Bernard Aboba wrote:
Do we really need “IESG clarification” or a “consensus check” to verify
that IESG approval of a work item for channel bindings should be
interpreted as approval to actually work on channel bindings???
No.
Given that Channel Bindings is discussed in both RFC 3748 and
The discussion here is (a) if we can get *some* generic authorization
passed via methods used for Channel Bindings, and (b) is that a good idea.
I think that the answer to (a) is yes, and (b) is some say yes,
some say no.
Existing RFCs are clear that Channel Bindings have a specific
Hi,
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.
This kind of thing drives me crazy. Why are their such policies?
To prevent bulk transfer of data over EAP, among others.
This would
A sets up an EAP server with EAP-Fraud method which merely
tunnels IP in EAP, installs supplicant with EAP-Fraud support
on his clients.
This approach has some precedent, albeit in a slightly different
context.
http://thomer.com/howtos/nstx.html
josh.
JANET(UK) is a trading name of The
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.
[Qin]: So the data resulting
-Original Message-
From: Qin Wu [mailto:sunse...@huawei.com]
Sent: Monday, August 17, 2009 1:29 AM
To: Joseph Salowey (jsalowey); Alper Yegin; emu@ietf.org
Subject: Re: [Emu] EAP and authorization
There have been a lot of proposals about EAP and
authorization in the
past
-Original Message-
From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On
Behalf Of Dave Nelson
Sent: Wednesday, August 12, 2009 9:33 AM
To: emu@ietf.org
Subject: Re: [Emu] EAP and authorization
Stephen Hanna writes...
I suppose that my basic argument is a practical one
David Mitton wrote:
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.
This kind of thing drives me crazy. Why are their such policies?
To prevent bulk transfer of data over EAP, among others.
Hi Alan,
On Sun, August 16, 2009 1:09 am, Alan DeKok wrote:
Dan Harkins wrote:
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
or sending remediation
instructions to an unhealthy endpoint).
Thanks,
Steve
-Original Message-
From: Dan Harkins [mailto:dhark...@lounge.org]
Sent: Sunday, August 16, 2009 3:30 AM
To: Stephen Hanna
Cc: Dave Nelson; emu@ietf.org
Subject: Re: [Emu] EAP and authorization
Hi Steve
Dan Harkins wrote:
Authentication has to do with proving an identity. Authorization has
to do with determining whether that proven identity is good or bad.
That's a clear explanation.
I'm not sure what sites do what but I'm not aware of an EAP method
that checks a username and a
Dan Harkins wrote:
On Sun, August 16, 2009 9:43 am, Stephen Hanna wrote:
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
On 8/16/2009 04:30 AM, Alan DeKok wrote:
David Mitton wrote:
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.
This kind of thing drives me crazy. Why are their such policies?
To prevent bulk
All,
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
On Aug 14, 2009, Alan DeKok al...@deployingradius.com wrote:
...
I can propose EAP-IP: carrying IP packets in EAP. It's crazy, but
possible.
In many ways that's what PANA is about, but that's not what spurred me to
respond.
The main limitation on bulk data transfer is that most EAP
Alan DeKok [mailto:al...@deployingradius.com] writes:
Glen Zorn wrote:
No. Please don't confuse authentication with authorization. The
parameters
you mention above are policy-related, not related to authentication.
You are making arbitrary distinctions between pieces of information.
Hoeper Katrin-QWKN37 wrote:
Here's the open issue (as I see it from previous posts to the list):
...
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
Alan DeKok writes...
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
Dave Nelson wrote:
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.
I've been told that it's impossible to call that process
-Original Message-
From: Alan DeKok [mailto:al...@deployingradius.com]
Sent: Wednesday, August 12, 2009 5:15 AM
To: Hoeper Katrin-QWKN37
Cc: Stephen Hanna; Glen Zorn; emu@ietf.org
Subject: Re: [Emu] EAP and authorization
Hoeper Katrin-QWKN37 wrote:
Here's the open issue (as I
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
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
Dave Nelson wrote:
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?
Yes, but it means we are far afield of the original discussion.
My opinion is that is both useful *and*
Alan DeKok [mailto://al...@deployingradius.com] writes:
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
Glen Zorn wrote:
Alan DeKok [mailto://al...@deployingradius.com] writes:
...
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.
To transport
To: Glen Zorn
Cc: emu@ietf.org
Subject: Re: [Emu] EAP and authorization
Glen Zorn wrote:
Alan DeKok [mailto://al...@deployingradius.com] writes:
...
Prior to authentication, EAP is the only communications protocol
between a supplicant and *anywhere* on the network. It is
therefore
: Re: [Emu] EAP and authorization
Glen Zorn wrote:
Alan DeKok [mailto://al...@deployingradius.com] writes:
...
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
Stephen Hanna [mailto:sha...@juniper.net] writes:
This discussion started with the statement that channel bindings
are a form of authorization data.
And no one disputed this?
Our charter requires us to
support carrying channel bindings in the tunnel method.
Password change is another form
Glen Zorn wrote:
No. Please don't confuse authentication with authorization. The parameters
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
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
31 matches
Mail list logo
