Subject: draft-winter-radsec-01 published

From: Stefan Winter <[email-masked]>
Date: Fri, 8 Feb 2008 09:33:45 +0100

Hello,

there is a new version of the RadSec draft available under

http://www.ietf.org/internet-drafts/draft-winter-radsec-01.txt

It contains the changes which were announced in IETF70 in Vancouver.

The two main points are:

- mention TLS with shared secrets as a possible means of establishing the TLS 
tunnel (though no implementations currently offer that option)
- The CA selection during the TLS handshake. This was presented in the 
Vancouver meeting, but the problem has two sides: server-to-client signalling 
of acceptable CAs can be signalled with TLS 1.1, as presented in the 
Vancouver meeting. The other way round, client-to-server signalling, is not 
possible with TLS 1.1. There is ongoing work in the tls working group though, 
http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4366-bis-01.txt , which 
will allow a Trusted CA indication later. A note that this signalling is the 
suggested behaviour as soon as that draft is ratified is added in the current 
radsec draft.

Greetings,

Stefan Winter

-- 
Stefan WINTER

RESTENA Foundation - Réseau Téléinformatique de l'Education Nationale et de 
la Recherche
R&D Engineer

6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg
email: [email-masked]     Tel.:     +352 424409-1
http://www.restena.lu               Fax:      +352 422473

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 8 Feb 2008 16:36:41 +0700

Are you planning to request a BOF slot in Philadephia?  If not, I would
strongly encourage you to do so.

Stefan Winter <> scribbled on Friday, February 08, 2008 3:34 PM:

> - mention TLS with shared secrets as a possible means of establishing
> the TLS tunnel (though no implementations currently offer that
> option)  
> - The CA selection during the TLS handshake. This was presented in
> the Vancouver meeting, but the problem has two sides:
> server-to-client signalling of acceptable CAs can be signalled with
> TLS 1.1, as presented in the Vancouver meeting. The other way round,
> client-to-server signalling, is not possible with TLS 1.1. There is
> ongoing work in the tls working group though,
> http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4366-bis-01.txt
> , which will allow a Trusted CA indication later. A note that this
> signalling is the suggested behaviour as soon as that draft is
> ratified is added in the current radsec draft.         
> 
> Greetings,
> 
> Stefan Winter

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: Stefan Winter <[email-masked]>
Date: Fri, 8 Feb 2008 10:56:25 +0100

Hi,

> strongly encourage you to do so.

It was considered, and I held a conf call with several ADs about it. The topic 
would not be RadSec only, but also several other things about the use of 
EAP/EAPoL in large federated roaming environments.
Unfortunately, it is quite late to still do a well-prepared BOF for IETF71, 
and so it was suggested that I hold a "bar BoF", which I will do. As a matter 
of fact, I'll be at the meeting the entire week, so there's plenty of time 
for discussion at any time.
I'm also about to write a draft for one of the EAP issues, about the problem 
that it is sub-optimal to find out how much EAP payload exactly to put into a 
RADIUS packet so that it doesn't fragment on the way but still fills the 
available space. Currently, this is determined by guessing and 
better-safe-than-sorry underestimations on the server side, and not at all 
done on the supplicant side.

Greetings,

Stefan Winter

-- 
Stefan WINTER

Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de 
la Recherche
Ingenieur Forschung & Entwicklung

6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg
E-Mail: [email-masked]     Tel.:     +352 424409-1
http://www.restena.lu                Fax:      +352 422473

---

From: Alan DeKok <[email-masked]>
Date: Fri, 08 Feb 2008 11:02:25 +0100

Stefan Winter wrote:
> available space. Currently, this is determined by guessing

  ?

 RFC 3579, Section 2.4 says that the NAS should Framed-MTU.  All servers
I know of use this to determine EAP payload.  If the Framed-MTU isn't
sent, then a "safe" assumption of normal Ethernet is used.

  i.e. eap_payload = Framed-MTU - eapol_header

  This calculation is extended to the contents of EAP types, by
accounting for known, and fixed, EAP-type headers.

> and 

  ?

  If the supplicant doesn't know what the local L2 MTU is, it's
completely broken.

  Alan DeKok.

---

From: Stefan Winter <[email-masked]>
Date: Fri, 8 Feb 2008 11:14:57 +0100

>   If the supplicant doesn't know what the local L2 MTU is, it's

The issue is more about the supplicant knowing its MTU, sending the maximum 
payload possible (typically, in EAP-TLS where the supplicant has a lot to 
say), the authenticator encapsulating that in a RADIUS packet, which grows 
larger than the MTU on its own uplink, leading to fragmentation of the UDP 
packet. That is not in principle a problem, but practical experience has 
shown that too many firewalls drop the fragments and auth doesn't work.
It would be desirable to be able to tell the supplicant that it should send 
*less* than its own MTU to prevent that from happening.
On the server side, EAP fragment size is statically configured, and is often a 
lot less than what supplicant could handle (1024 is a common default). Thus, 
sending less payload than would be possible means that a server has to split 
the EAP conversation in more RADIUS packets than need be, meaning more 
round-trips and longer time-to-auth. 

greetings,

Stefan Winter

-- 
Stefan WINTER

---

From: Alan DeKok <[email-masked]>
Date: Fri, 08 Feb 2008 11:23:05 +0100

Stefan Winter wrote:
> packet.

  Ah.  That's a completely separate problem.

> That is not in principle a problem, but practical experience has 

  Broken firewalls are bad.  Putting a firewall between a NAS and a
RADIUS server is generally not a good idea.  Sending RADIUS over the
wider Internet isn't a good idea, unless encapsulation is used (IPSec,
etc.), which solves the UDP fragmentation problem.

> *less* than its own MTU to prevent that from happening.

  This is a path MTU discovery problem.  It's hard.  i.e. impossible, in
the general case.

> round-trips and longer time-to-auth. 

  I'm not sure what else to say other than "Yes, that's life..."

  I think it's a bad idea to add complexity to EAP in order to work
around firewall bugs.

  Alan DeKok.

---

From: Stefan Winter <[email-masked]>
Date: Fri, 8 Feb 2008 11:41:28 +0100

Hi,

> > On the server side, EAP fragment size is statically configured, and is
> > often a lot less than what supplicant could handle (1024 is a common
> > default). Thus, sending less payload than would be possible means that a
> > server has to split the EAP conversation in more RADIUS packets than need
> > be, meaning more round-trips and longer time-to-auth.
>

The idea would be to make life better, if that's at all possible. Long 
authentication time is bad.

Stefan

-- 
Stefan WINTER

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 8 Feb 2008 06:15:44 -0800

To be clear, this fragmentation issue is a problem for RADIUS, but not RADSEC, correct? 
I'd assume that TCP MSS negotiation combined with Packetization Layer Path MTU discovery
should make fragmentation of TCP segments relatively unlikely. 

BTW, how does IPsec solve the fragmentation problem for RADIUS?  Couldn't it make it worse? 

> Date: Fri, 8 Feb 2008 11:23:05 +0100
> From: [email-masked]
> To: [email-masked]
> CC: [email-masked]; [email-masked]
> Subject: Re: draft-winter-radsec-01 published
> 
> Stefan Winter wrote:

---

From: "David B. Nelson" <[email-masked]>
Date: Fri, 08 Feb 2008 09:30:33 -0500

Bernard Aboba wrote:

> BTW, how does IPsec solve the fragmentation problem for RADIUS?

Maybe it prevents the "broken" firewalls from peeking into the packets, 
seeing UDP fragments, and dropping them.  They skate by via means of an 
IPsec pass through feature.  Just a guess.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 8 Feb 2008 08:09:07 -0800

To even know whether the packets are IPsec/IKE, it would be necessary to reassemble them.  So
I don't see how they could be treated differently. 

> Date: Fri, 8 Feb 2008 09:30:33 -0500
> From: [email-masked]
> To: [email-masked]
> CC: [email-masked]; [email-masked]; [email-masked]; [email-masked]

---

From: Alan DeKok <[email-masked]>
Date: Sat, 09 Feb 2008 08:58:50 +0100

> I don't see how they could be treated differently.

  They won't.  But administrators can lower the MTU for IPSec
connections until it "just works".  At that point, protocols transported
inside of IPSec are fine.

  This can't be done on the supplicant, because it only sees it's local
MTU.  There is no feedback mechanism to lower this MTU to account for
later RADIUS encapsulation.

  The IPSec solution is less about automated path MTU discovery than
administrator trial and error until "it seems to work".

  Adding a feedback mechanism to EAP for MTU could be useful.  The only
reasonable place to put this information is in the first packet sent by
the EAP server.

  Alan DeKok.

---

From: Stefan Winter <[email-masked]>
Date: Mon, 11 Feb 2008 11:24:09 +0100

Hi,

> To be clear, this fragmentation issue is a problem for RADIUS, but not
> RADSEC, correct? I'd assume that TCP MSS negotiation combined with
> Packetization Layer Path MTU discovery should make fragmentation of TCP
> segments relatively unlikely.

That is correct, a reliable transport makes this problem go away, or at least 
makes life a lot easier in that respect. Still, even though I'm quite 
enthusiastic about RadSec, I can still imagine people using just plain RADIUS 
who suffer from that problem.

> BTW, how does IPsec solve the fragmentation problem for RADIUS?  Couldn't

As I don't use RADIUS-over-IPSec myself, I asked one of our national eduroam 
operators for his practical experiences in that respect. I'll keep you 
posted.

Greetings,

Stefan Winter

-- 
Stefan WINTER

---

From: Stefan Winter <[email-masked]>
Date: Mon, 11 Feb 2008 11:37:04 +0100

Hi,

> As I don't use RADIUS-over-IPSec myself, I asked one of our national
> eduroam operators for his practical experiences in that respect. I'll keep
> you posted.

I got:

"I've seen fragmentation problems on IPsec only once, and that quite long
ago so I can't recall more info than it was related to CISCO PIX FW in
situation when we were using both AH and ESP headers. After droping AH
it started working reliably. That time I realized that AH headers are
not necessary and now we are using only ESP.

[...]

I'm doing from time to time test with big EAP requests to be sure that
our Czech eduroam is running on correctly setup network. When I discover
problem I ask admins to fix that. So far I never had to disconnect
anyone for this incompatibility."

Which looks like forcing admins to tweak stuff until it works.

Stefan

-- 
Stefan WINTER