> 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 spe
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
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. Afte
> -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
> -Original Message-
> From: Alan DeKok [mailto:al...@deployingradius.com]
> Sent: Thursday, August 13, 2009 11:16 PM
> To: Joseph Salowey (jsalowey)
> Cc: Alper Yegin; emu@ietf.org
> Subject: Re: [Emu] EAP and authorization
>
> Joseph Salowey (jsalowey) wr
Dan Harkins [mailto://dhark...@lounge.org] writes:
...
> 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 commu
> 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
Hi, Alan:
- Original Message -
From: "Alan DeKok"
To: "Joseph Salowey (jsalowey)"
Cc:
Sent: Friday, August 14, 2009 2:16 PM
Subject: Re: [Emu] EAP and authorization
> Joseph Salowey (jsalowey) wrote:
>> There are other ways in which EAP has proposed
> 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 Th
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 oth
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 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 bul
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
> > th
Hi Steve,
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 (like which
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
ting
the lying NAS repaired 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.o
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
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.
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 of data to do NEA posture checking. And, yes, we should deter
o add a work item for channel bindings. So they
> have already indicated their support for that effort.
>
> Thanks,
>
> Steve
>
>> -Original Message-
>> From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On
>> Behalf Of Dave Nelson
>> Sent: Wednesd
On Aug 14, 2009, Alan DeKok 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 to
> RADIUS gateways (
Joseph Salowey (jsalowey) wrote:
> 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 propo
...@ietf.org [mailto:emu-boun...@ietf.org] On
> Behalf Of Alper Yegin
> Sent: Friday, August 07, 2009 6:31 AM
> To: emu@ietf.org
> Subject: [Emu] EAP and authorization
>
> This issue came up during the last IETF meeting when the WG
> discussed channel binding.
>
>
...@ietf.org [mailto:emu-boun...@ietf.org] On
> Behalf Of Alper Yegin
> Sent: Friday, August 07, 2009 6:31 AM
> To: emu@ietf.org
> Subject: [Emu] EAP and authorization
>
> This issue came up during the last IETF meeting when the WG
> discussed channel binding.
>
>
Hello,
>> 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" restric
Dave Nelson [mailto://d.b.nel...@comcast.net] writes:
> 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 w
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,
I agree that Authentication in the truest sense of the term is about knowing
and verifying who someone is or what something is (yo
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 busi
.
Thanks,
Steve
> -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...
>
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
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
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
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 o
> -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 wr
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
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 "auth
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 findin
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 featu
Glen Zorn wrote:
> 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 (authoriz
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 inform
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 l
Alan DeKok [mailto:al...@deployingradius.com] writes:
> Glen Zorn wrote:
> > Hmm. Has another way been tried or is it the best way because it's
> the
> > easiest (or only) way we've tried?
>
> Authentication decisions have traditionally involved more than just
> username / password checking.
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
Glen Zorn wrote:
> Hmm. Has another way been tried or is it the best way because it's the
> 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-authorizatio
; Sent: Tuesday, August 11, 2009 4:00 PM
> To: Glen Zorn; 'Alan DeKok'
> Cc: emu@ietf.org
> Subject: Re: [Emu] EAP and authorization
>
> This discussion started with the statement that channel bindings
> are a form of authorization data. Our charter requires us
Sent: Tuesday, August 11, 2009 4:22 PM
> To: 'Alan DeKok'
> Cc: emu@ietf.org
> Subject: Re: [Emu] EAP and authorization
>
> Alan DeKok [mailto:al...@deployingradius.com] writes:
>
> > Glen Zorn wrote:
> > > Alan DeKok [mailto://al...@deployingra
t; From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On
> > Behalf Of Alan DeKok
> > Sent: Tuesday, August 11, 2009 2:36 PM
> > To: Glen Zorn
> > Cc: emu@ietf.org
> > Subject: Re: [Emu] EAP and authorization
> >
> > Glen Zorn wrote:
> > > A
Alan DeKok [mailto:al...@deployingradius.com] writes:
> 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
DeKok
> Sent: Tuesday, August 11, 2009 2:36 PM
> 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 comm
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 tra
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
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 authent
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 m
53 matches
Mail list logo
