Hi,
Agreed. However, SSIDs are *likely* to be unique within a roamin
consortium. This is because the parties talk to each other, and can
complain when the SSIDs are unknown, or re-used.
Umm. We use the SSID eduroam wherever possible for brand recognition,
but even we have to deviate
Hi,
3580 says Called-Station-Id SHOULD include the SSID. Most APs do
include the SSID.
s/Most/Some
There's a painful variety in what comes inside Calling-Station-Id, which
is *very* unfortunate. A set of RADIUS attributes to convey things like
the SSID in a proper place would be very
Dan Harkins wrote:
Wrong, it allows the user credentials to be exposed, depending on
the EAP method.
Hmm... it requires that any user credentials in the tunnel be exposed.
I understand the difference (obviously a bit better than you do). And I
didn't ask you to list the differences.
Sam Hartman [mailto:hartmans-i...@mit.edu] writes:
Glen == Glen Zorn g...@net-zen.net writes:
Glen Or we could use the more direct much simpler approach of
Glen allowing the client to authenticate the network to which it is
Glen attached use that data to decide by itself.
Glen Zorn wrote:
If certificate-based TLS authentication is used the TTLS server is located
in the visited network (something that the client can check by matching the
identity advertised with a name in the cert), the task is accomplished (in
that the problem becomes one of policy,
Glen Zorn wrote:
Alan DeKok [mailto:al...@deployingradius.com] writes:
This proxying violates the privacy requirements.
What privacy requirements are those?
The requirement to keep authentication credentials private, which is
one of the reasons for choosing a TLS-based method in the
Alan DeKok [mailto:al...@deployingradius.com] writes:
Glen Zorn wrote:
Alan DeKok [mailto:al...@deployingradius.com] writes:
This proxying violates the privacy requirements.
What privacy requirements are those?
The requirement to keep authentication credentials private, which is
Dan Harkins wrote:
The only type of credential that would have the issues you're
talking about is a long-term password used in PAP. Now I'm not
a big OPS guy but I do have quite a bit of experience in actual
deployments of 802.1X and EAP and I haven't seen them used anywhere.
TTLS is in
On Thu, June 24, 2010 1:55 pm, Alan DeKok wrote:
Dan Harkins wrote:
The only type of credential that would have the issues you're
talking about is a long-term password used in PAP. Now I'm not
a big OPS guy but I do have quite a bit of experience in actual
deployments of 802.1X and EAP and
-Original Message-
From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of
Dan
Harkins
Sent: Thursday, June 24, 2010 3:07 PM
To: Alan DeKok
Cc: emu@ietf.org; Sam Hartman
Subject: Re: [Emu] Channel Binding Discussion at IETF 77: why bother
On Thu, June 24, 2010 1:55
-Original Message-
From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of
Dan
Harkins
Sent: Thursday, June 24, 2010 3:07 PM
To: Alan DeKok
Cc: emu@ietf.org; Sam Hartman
Subject: Re: [Emu] Channel Binding Discussion at IETF 77: why bother
On Thu, June 24, 2010 1:55 pm, Alan
-Original Message-
From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of
Dan
Harkins
Sent: Thursday, June 24, 2010 3:07 PM
To: Alan DeKok
Cc: emu@ietf.org; Sam Hartman
Subject: Re: [Emu] Channel Binding Discussion at IETF 77: why bother
On Thu, June 24, 2010 1:55 pm, Alan
)
Cc: Dan Harkins; Alan DeKok; emu@ietf.org; Sam Hartman
Subject: RE: [Emu] Channel Binding Discussion at IETF 77: why bother
Hi Joe,
Why would someone go to the expense to implement EAP-TTLS or
EAP-FAST
but not also do some hash-a-password-with-nonces method like GPSK or
MSCHAPv2
Alan,
On Thu, June 24, 2010 6:27 pm, Alan DeKok wrote:
Alan, do you want to prohibit an inner method from terminating on a
different entity than the outer (tunnel) method? If the answer is yes
then I have no further questions. If the answer is no then I'd like to
know how you intend on
Sam Hartman [mailto:hartm...@mit.edu] writes:
Glen == Glen Zorn g...@net-zen.net writes:
Hi. I have read the later messages on this thread, but it sounded like
you and Alan were talking past each other a bit, so I want to come back
to where I think the disagreement is introduced.
Glen == Glen Zorn g...@net-zen.net writes:
Glen Or we could use the more direct much simpler approach of
Glen allowing the client to authenticate the network to which it is
Glen attached use that data to decide by itself. This can be
Glen done today using EAP-TTLS.
How?
I'd
Glen Zorn wrote:
Note that transitive trust issues are irrelevant if EAP-TTLS is used.
I agree with Sam here. I'd like to see more explanation behind this
assertion.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
Alan DeKok [mailto://al...@deployingradius.com] writes:
...
Channel bindings closes a security issue in current deployments of the
EAP protocol.
Is that true? If all you want is to solve the case where ...the NAS could
tell the user we're partner X: $0.05 / minute. It could *really* be
Alan, Sam, Glen,
imho, I'd not place any trust in an SSID.
Its just a 32 octet string that can be set to anything, and provides
no guarantee about the identity of a WLAN.
Kind regards
Stephen
On 20 June 2010 17:05, Alan DeKok al...@deployingradius.com wrote:
Glen Zorn
Stephen McCann wrote:
imho, I'd not place any trust in an SSID.
Its just a 32 octet string that can be set to anything, and provides
no guarantee about the identity of a WLAN.
It's useful as an example.
Alan DeKok.
___
Glen Zorn wrote:
Alan DeKok [mailto:al...@deployingradius.com] writes:
and an indication that the home AAA approves
of the connection.
Hmm. I could have sworn that this indication already existed, in the form
of Access-Accept (for RADIUS).
And EAP-Success. Exactly.
It's part of the
Alan DeKok [mailto://al...@deployingradius.com] writes:
...
It's part of the channel binding. It closes the loop between what
the
NAS tells the AAA, and what the NAS tells the client.
Only in the special case where (in your roaming example, below)
roaming
partners X and Y have
Glen Zorn wrote:
Is there an RFC that says this somewhere?
RFC 3580, Section 3.20
802.11-2007 doesn't mention
Called-Station-ID; 802.1X-2004 says this:
D.3.20 Called-Station-Id
For IEEE 802.1X Authenticators, this attribute is used to store the Bridge
or Access Point MAC address,
Alan DeKok [mailto:al...@deployingradius.com] writes:
Glen Zorn wrote:
Is there an RFC that says this somewhere?
RFC 3580, Section 3.20
OK, thanks. This appears to be identical to the section from 802.1X-2004
that I quoted below, though...
802.11-2007 doesn't mention
Alan DeKok [mailto:al...@deployingradius.com]
(sigh, hit send too soon)
...
802.11-2007 doesn't mention
Called-Station-ID; 802.1X-2004 says this:
Taken from 3580.
Whatever; 3580 says
This document provides suggestions on Remote Authentication Dial In
User Service (RADIUS)
Glen Zorn wrote:
Note the use of should.
Which is a common practice.
???
3580 says Called-Station-Id SHOULD include the SSID. Most APs do
include the SSID.
However, SSIDs are *likely* to be unique within a roamin
consortium. This is because the parties talk to each other, and can
Sam Hartman [mailto://hartmans-i...@mit.edu] writes:
Hi. At IETF 77, I agreed to edit draft-ietf-emu-chbind. Also, at that
meeting, I sat down with Glen to understand his concerns with the
document. I'd like to write up my notes on that meeting and to discuss
what I think the critical next
Sam Hartman wrote:
You can imagine that the corporation would know the identities of its
own access points. In particular, a combination of configuration on the
AAA servers and at the boundary firewall could mean that the AAA servers
know whether a given request for access is coming from the
Glen Zorn wrote:
Indeed it could, but all you really seem to be asking for is a way for the
corporation to be able to control the configuration of the client.
That is already done outside of the scope of EAP. (VPN config,
Directory services, etc.) The only requirement I see for EAP is
:29:07 -0400
From: Sam Hartmanhartmans-i...@mit.edu
Subject: [Emu] Channel Binding Discussion at IETF 77
To: emu@ietf.org
Message-ID:tslzkywt7r0@mit.edu
Content-Type: text/plain; charset=us-ascii
Hi. At IETF 77, I agreed to edit draft-ietf-emu-chbind. Also, at that
meeting, I sat down
I will definitely have a revision for IETF 78. I may not have
everything I'd like to have done ready for that revision.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Hi. At IETF 77, I agreed to edit draft-ietf-emu-chbind. Also, at that
meeting, I sat down with Glen to understand his concerns with the
document. I'd like to write up my notes on that meeting and to discuss
what I think the critical next steps are for the document.
I presented two
32 matches
Mail list logo
