Subject: Consensus Call on RADEXT WG re-charter

From: <[email-masked]>
Date: Mon, 14 Apr 2008 06:19:57 -0700

This is a consensus call for acceptance of the RADEXT WG re-charter.  The
consensus call will last until April 28, 2008.  Please send email to the list 
stating whether you are in favor or opposed to the RADEXT WG re-charter
proposal: 

=======================================================
Description of Working Group:

The RADIUS Extensions Working Group will focus on extensions to the
RADIUS protocol required to define extensions to the standard
attribute space as well as to address cryptographic algorithm
agility and use over new secure transports. In addition, RADEXT will
work on RADIUS Design Guidelines and define new attributes for 
particular applications of authentication, authorization and 
accounting such as NAS management and local area network (LAN) usage. 

In order to enable interoperation of heterogeneous RADIUS/Diameter
deployments, all RADEXT WG work items MUST contain a Diameter
compatibility section, outlining how interoperability with
Diameter will be maintained.

Furthermore, to ensure backward compatibility with existing RADIUS
implementations, as well as compatibility between RADIUS and Diameter,
the following restrictions are imposed on extensions considered by the
RADEXT WG:

- All RADIUS work MUST be backward compatible with existing RADIUS
RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,
4675, 5080, 5090 and 5176.

- All RADIUS work MUST be compatible with equivalent facilities in
Diameter. Where possible, new attributes should be defined so that
the same attribute can be used in both RADIUS and Diameter without
translation. In other cases a translation considerations
section should be included in the specification.

Work Items

The immediate goals of the RADEXT working group are to address the
following issues:

- RADIUS design guidelines. This document will provide guidelines for
design of RADIUS attributes. It will specifically consider how
complex data types may be introduced in a robust manner, maintaining
backwards compatibility with existing RADIUS RFCs, across all the
classes of attributes: Standard, Vendor-Specific and SDO-Specific.
In addition, it will review RADIUS data types and associated
backwards compatibility issues.
 
- RADIUS Management authorization. This document will define the
use of RADIUS for NAS management over IP. 

-RADIUS attribute space extension. The standard RADIUS attribute
space is currently being depleted. This document will provide
additional standard attribute space, while maintaining backward
compatibility with existing attributes.

-RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally 
relied on MD5 for both per-packet integrity and authentication as well
as attribute confidentiality. Given the increasingly successful
attacks being mounted against MD5, the ability to support
alternative algorithms is required. This work item will
include documentation of RADIUS crypto-agility requirements,
as well as development of one or more Experimental RFCs providing
support for negotiation of alternative cryptographic algorithms
to protect RADIUS.

- IEEE 802 attributes. New attributes have been proposed to
support IEEE 802 standards for wired and wireless LANs. This
work item will support authentication, authorization and
accounting attributes needed by IEEE 802 groups including
IEEE 802.1, IEEE 802.11 and IEEE 802.16.

- New RADIUS transports. New secure transports for RADIUS will
be developed, including TCP/TLS (RADSEC) and UDP/DTLS.

- Documentation of Status-Server usage. A document
describing usage of the Status-Server facility will be
developed.

Goals and Milestones:
Jun 2008 RADIUS Design Guidelines submitted as a Best Current Practice RFC
Jun 2008 RADIUS Management Authorization I-D submitted as a Proposed Standard RFC
Sep 2008 RADIUS Crypto-agility Requirements submitted as an Informational RFC
Sep 2008 Extended Attributes I-D submitted as a Proposed Standard RFC
Dec 2008 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC
Mar 2009 Status-Server I-D submitted as a Proposed Standard RFC
Mar 2009 RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental RFC
June 2009 RADIUS over DTLS I-D submitted as an Experimental RFC
June 2009 RADIUS Cryptographic Algorithm Agility I-D submitted as an Experimental RFC

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 14 Apr 2008 22:56:26 +0700

[email-masked] <> scribbled on Monday, April 14, 2008 8:20
PM:

> This is a consensus call for acceptance of the RADEXT WG
> re-charter.  The consensus call will last until April 28,
> 2008.  Please send email to the list stating whether you are
> in favor or opposed to the RADEXT WG re-charter
> proposal:

Given the Co-Chair's response to the question of the meaning of
"backward compatibility", I think that it would show considerably more
intellectual honesty to simply remove the first bullet: "compatibility"
defined by the feasibility of implementing a protocol gateway is
essentially meaningless, since by that measure there are no two
protocols that are not "compatible".

> The RADIUS Extensions Working Group will focus on extensions
> to the RADIUS protocol required to define extensions to the
> standard attribute space as well as to address cryptographic
> algorithm agility and use over new secure transports. In
> addition, RADEXT will work on RADIUS Design Guidelines and
> define new attributes for particular applications of
> authentication, authorization and accounting such as NAS
> management and local area network (LAN) usage.
> 
> In order to enable interoperation of heterogeneous
> RADIUS/Diameter deployments, all RADEXT WG work items MUST
> contain a Diameter compatibility section, outlining how
> interoperability with Diameter will be maintained.
> 
> Furthermore, to ensure backward compatibility with existing
> RADIUS implementations, as well as compatibility between
> RADIUS and Diameter, the following restrictions are imposed on
> extensions considered by the RADEXT WG:
> 
> - All RADIUS work MUST be backward compatible with existing
> RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580,
> 4668-4673, 4675, 5080, 5090 and 5176.
> 
> - All RADIUS work MUST be compatible with equivalent
> facilities in Diameter. Where possible, new attributes should
> be defined so that the same attribute can be used in both
> RADIUS and Diameter without translation. In other cases a
> translation considerations section should be included in the
> specification. 
> 
> 
> Work Items
> 
> The immediate goals of the RADEXT working group are to address
> the following issues:
> 
> - RADIUS design guidelines. This document will provide
> guidelines for design of RADIUS attributes. It will
> specifically consider how complex data types may be introduced
> in a robust manner, maintaining backwards compatibility with
> existing RADIUS RFCs, across all the classes of attributes:
> Standard, Vendor-Specific and SDO-Specific.
> - RADIUS Management authorization. This document will define
> the use of RADIUS for NAS management over IP.
> 
> -RADIUS attribute space extension. The standard RADIUS
> attribute space is currently being depleted. This document
> will provide additional standard attribute space, while
> maintaining backward compatibility with existing attributes.
> 
> -RADIUS Cryptographic Algorithm Agility. RADIUS has
> traditionally relied on MD5 for both per-packet integrity and
> authentication as well as attribute confidentiality. Given the
> increasingly successful attacks being mounted against MD5, the
> ability to support alternative algorithms is required. This
> work item will include documentation of RADIUS crypto-agility
> requirements, as well as development of one or more
> Experimental RFCs providing support for negotiation of
> alternative cryptographic algorithms to protect RADIUS.
> 
> accounting attributes needed by IEEE 802 groups including IEEE
> 802.1, IEEE 802.11 and IEEE 802.16.
> 
> - Documentation of Status-Server usage. A document describing
> usage of the Status-Server facility will be developed.
> 
> Goals and Milestones:
> Jun 2008 RADIUS Design Guidelines submitted as a Best Current
> Practice RFC Jun 2008 RADIUS Management Authorization I-D
> submitted as a Proposed Standard RFC Sep 2008 RADIUS
> Crypto-agility Requirements submitted as an Informational RFC
> Sep 2008 Extended Attributes I-D submitted as a Proposed
> Standard RFC Dec 2008 IEEE 802 Attributes I-D submitted as a
> Proposed Standard RFC Mar 2009 Status-Server I-D submitted as
> a Proposed Standard RFC Mar 2009 RADSEC (RADIUS over TCP/TLS)
> draft submitted as an Experimental RFC June 2009 RADIUS over
> DTLS I-D submitted as an Experimental RFC June 2009 RADIUS
> Cryptographic Algorithm Agility I-D submitted as an Experimental RFC

--
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: Alan DeKok <[email-masked]>
Date: Mon, 14 Apr 2008 18:39:11 +0200

> protocols that are not "compatible".

  While that's true, a RadSec to RADIUS gateway involves terminating
TCP, TLS, and forwarding the contents to RADIUS.  If this isn't RADIUS,
then by the same standards, any HTTPS to HTTP proxy isn't doing HTTP.

  Similarly, any IPv4 to IPv6 gateway is evil, because it involves
changing the transport layers underneath the application-layer protocol.

  And finally, SIP allows for both UDP and TCP transports, each with the
option (or not) of using TLS.  There would seem to be obvious parallels
between SIP and RADIUS here.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 14 Apr 2008 18:43:22 +0200

> stating whether you are in favor or opposed to the RADEXT WG re-charter

  I am in favor of the proposal.

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 14 Apr 2008 11:25:10 -0700

[email-masked] <> scribbled on Monday, April 14, 2008
11:39 PM:

>> "backward compatibility", I think that it would show considerably
>> more intellectual honesty to simply remove the first bullet:
>> "compatibility" defined by the feasibility of implementing a
>> protocol gateway is essentially meaningless, since by that measure
>> there are no two protocols that are not "compatible".
> 
>  While that's true, a RadSec to RADIUS gateway involves
> terminating TCP, TLS, and forwarding the contents to RADIUS.
> If this isn't RADIUS, then by the same standards, any HTTPS to HTTP
> proxy isn't doing HTTP. 

Hmm.  By that standard, it would seem that Diameter is RADIUS, too...

> 
>  Similarly, any IPv4 to IPv6 gateway is evil, because it
> involves changing the transport layers underneath the
> application-layer protocol. 

I don't think that I said anything about good or evil :-), but you make
my point for me: IPv6 is hardly "backward compatible" w/IPv4 & that's
not a problem.  The problem would arise if someone claimed that it was
because, 'Well, you can build a gateway'.

> 
>  And finally, SIP allows for both UDP and TCP transports,
> each with the option (or not) of using TLS.  There would seem
> to be obvious parallels between SIP and RADIUS here.

Certainly, in that RADIUS (the RFC 2865 version, anyway) only allows UDP
transport.  How could I have missed that? ;-)

> 
>  Alan DeKok.
> 
> --
> to unsubscribe send a message to
> [email-masked] with the word 'unsubscribe' in
> a single line as the message text body.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 14 Apr 2008 20:49:49 +0200

Glen Zorn wrote:
...
> Hmm.  By that standard, it would seem that Diameter is RADIUS, too...

  No.  I didn't mention an HTTPS to FTP proxy as being HTTP.

> because, 'Well, you can build a gateway'.

  The protocols being transported on IPv4 can also be transported on
IPv6.  Similarly, UDP transport + RADIUS application protocol is...
RADIUS.  TCP transport + RADIUS application protocol is... RADIUS.

  The only way to call RadSec something other than RADIUS is if you say
that FTP over IPv6 is not FTP.  After all, FTP was for IPv4, and IPv6 is
a new-fangled transport... so FTP over IPv6 is not FTP... it's "magic".

  Alan DeKok.

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 14 Apr 2008 15:17:14 -0400

Alan DeKok writes...

> RADIUS.  TCP transport + RADIUS application protocol is... RADIUS.

I can see both sides of this argument.  It's a common and desirable practice
that application layer protocols are designed to be transport-agnostic.
Some are; some aren't.  In the case of RADIUS, the original task was to
document RADIUS pretty much "as implemented" by Livingston Enterprises,
Merit Networks, and a few others.  Use of the UDP transport got "hard-wired"
into the RFC.  Maybe UDP is "crucial" to RADIUS being RADIUS, maybe it's an
artifact.
 
> that FTP over IPv6 is not FTP.

Well, FTP runs over TCP.  The similar thing that runs over UDP is called
TFTP.  Maybe that example doesn't make your point as well you'd have liked.

There may be good reasons to "hard-wire" an application layer protocol to a
particular transport layer.  There are also cases when that "hard-wiring"
happens as a matter of default, convenience, or lack of explicit
consideration, rather than as a matter of design or architecture.  I think
we could argue ad infinitum into which category we should slot RFC 2865
RADIUS.  :-)

However, if the WG decides that RADIUS (the application protocol) can be
transport-agnostic, I see no reason to get hung up on "naming rights".

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 14 Apr 2008 19:30:45 -0700

>  No.  I didn't mention an HTTPS to FTP proxy as being HTTP.

This is what you said: "...a RadSec to RADIUS gateway involves
terminating TCP, TLS, and forwarding the contents to RADIUS.  If this
isn't RADIUS, then by the same standards, any HTTPS to HTTP proxy isn't
doing HTTP."  A Diameter to RADIUS gateway involves terminating TCP (or
SCTP), TLS, and forwarding the contents to RADIUS.  If you really think
that this is different from your HTTPS->HTTP example, perhaps it's
because you are conveniently ignoring the fact that HTTP is only defined
over TCP.  However, one could just as easily argue that HTTP != HTTPS,
given the need for different port numbers...

> 
>> I don't think that I said anything about good or evil :-), but you
>> make my point for me: IPv6 is hardly "backward compatible" w/IPv4 &
>> that's not a problem.  The problem would arise if someone claimed
>> that it was because, 'Well, you can build a gateway'.
> 
>  The protocols being transported on IPv4 can also be
> transported on IPv6.  

I really don't know how that is relevant.  Dropping down a layer or 2,
the same protocols can be carried by both Ethernet & ATM.  Are you going
to claim that they are somehow compatible (backward, forward or
upside-down)?

> Similarly, UDP transport + RADIUS application
> protocol is... RADIUS.  TCP transport + RADIUS application protocol
> is... RADIUS. 

I know that you have read RFC 2865 (probably more often than I), so you
know that there is no such thing as a standard "RADIUS application
protocol", defined w/o regard for the underlying transport.  

> 
>  The only way to call RadSec something other than RADIUS is
> if you say that FTP over IPv6 is not FTP.  After all, FTP was
> for IPv4, 

I can't find any mention of IPv4 in RFC 959; it does mention TCP,
however.  Would FTPoUDP also be FTP?  How would FTP & FTPoUDP
interoperate?  These questions seem much more to the point, I think.

> and IPv6 is a new-fangled transport... so FTP over
> IPv6 is not FTP... it's "magic".

One more time: the version of IP being used is transparent & therefore
irrelevant to FTP.  UDP transport is forever enshrined in RFC 2865,
however; maybe that's a bad thing, but it's true nonetheless.

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 14 Apr 2008 19:47:27 -0700

12:17 PM:

...

> 
> However, if the WG decides that RADIUS (the application
> protocol) can be transport-agnostic, I see no reason to get hung up
> on "naming rights". 

First, the WG would have to _define_ RADIUS "the application protocol",
since it doesn't exist w/o reference to the underlying transport.  Maybe
you have your own reasons for not wanting to change the name, but I do
wish that this charade of claiming "backward compatibility" would come
to an end.  Even the creators of RADSEC have conceded that it's not
RADIUS, why can't you?

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 14 Apr 2008 22:25:30 -0700

>UDP transport is forever enshrined in RFC 2865,

How is this different from say, SNMP? 

The original transport mappings for SNMP (RFC 1089, 1906) were all datagram
transports.

The logic for SNMP over UDP was quite well enshrined.  For example, see the
following discussion,
which has some parallels with RFC 2865 Section 2.4:
http://www.unix.org.ua/orelly/networking_2ndEd/snmp/ch02_01.htm

Yet, RFC 3430 defined SNMP over TCP:
http://www.ietf.org/rfc/rfc3430.txt

Normative references included the following:

Transport Mappings for SNMP:
http://www.ietf.org/rfc/rfc3417.txt
SNMP applications:
http://www.ietf.org/rfc/rfc3413.txt
An Architecture for Describing SNMP Management Frameworks:
http://www.ietf.org/rfc/rfc3411.txt

---

From: Stefan Winter <[email-masked]>
Date: Tue, 15 Apr 2008 08:00:48 +0200

Hi,

> to an end.  Even the creators of RADSEC have conceded that it's not

Well, in case you are referring to me in IETF-71, I admitted that there are 
non-trivial operational differences between the two transports, and that the 
characteristics of a stateful transport need to taken into account properly. 
That makes it *different from RADIUS over UDP*, but not substantially 
different from RADIUS *at all*. Even you conceded to saying that the 
innermost PDU still remains as it is, so if nothing else, there is a core of 
RADIUS embedded. And I would be surprised if you don't see yourself that 
backwards compatibility is considerably easier if this PDU can be repackaged 
into a new transport without changing it (except the changes that any RADIUS 
apcket undergoes anyway on a RADIUS proxy, re-signing with its own shared 
secret).

In general, I see this discussion "is it different or not?" as rather 
pointless in the real world. Whatever one's perceived opinion or perceived 
outcome is, it doesn't change anything in the protocol itself.

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: Stefan Winter <[email-masked]>
Date: Tue, 15 Apr 2008 08:06:52 +0200

Hi,

> SCTP), TLS, and forwarding the contents to RADIUS.

With the devil being in the detail: With RadSec to RADIUS, the incoming packet 
is already a RADIUS packet as soon as it is decoded from the TLS tunnel. 
There is no translation of the content.
With Diameter to RADIUS, non-trivial translations need to be done, some of 
which can't even be done at all right now (Accepts >4096 bytes payload, AVPs 
with >253 bytes). We have yet to see a Diameter translation agent that can do 
bijective translations from one to another and back again (which I personally 
see as the holy grail of compatibility). I doubt we will ever. With RadSec to 
RADIUS, this is a triviality.

Greetings,

Stefan Winter

> If you really think 

-- 
Stefan WINTER

---

From: Stefan Winter <[email-masked]>
Date: Tue, 15 Apr 2008 08:07:30 +0200

> consensus call will last until April 28, 2008.  Please send email to the
> list stating whether you are in favor or opposed to the RADEXT WG
> re-charter proposal:

In favour.

Greetings,

Stefan Winter

-- 
Stefan WINTER

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 15 Apr 2008 13:58:38 +0700

[email-masked] <> scribbled on Tuesday, April 15, 2008
12:26 PM:

>> UDP transport is forever enshrined in RFC 2865, however; maybe
>> that's a bad thing, but it's true nonetheless.
> 

Here is the difference: RFC 1067, section 3.2.4 paragraph 2 says
"Consistent with the goal of minimizing complexity of the management
agent, the exchange of SNMP messages requires only an unreliable
datagram service, and every message is entirely and independently
represented by a single transport datagram.  While this document
specifies the exchange of messages via the UDP protocol [8], the
mechanisms of the SNMP are generally suitable for use with a wide
variety of transport services."  It would appear to me that SNMP was
designed _from the beginning_ with a variety of transports in mind; the
fact that all of the transports defined for the next 14 years or so were
connectionless  just says that the original choice was a good one.
Leaving aside the apologetics in section 2.4 of RFC 2865, contrast the
above quotation with section 3, paragraph 1 of that document: "Exactly
one RADIUS packet is encapsulated in the UDP Data field [4], where the
UDP Destination Port field indicates 1812 (decimal)."  Where is the
wiggle room, the opening for a flexible transport mapping in that
statement?  There is none, the statement is flat, inflexible and quite
specific.

> 
> The original transport mappings for SNMP (RFC 1089, 1906) were all
> datagram transports. 
> 
> The logic for SNMP over UDP was quite well enshrined.  For
> example, see the following discussion, which has some
> parallels with RFC 2865 Section 2.4:

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 15 Apr 2008 14:47:24 +0700

Stefan Winter <mailto:[email-masked]> scribbled on Tuesday,
April 15, 2008 1:01 PM:

> Hi,
> 
>> First, the WG would have to _define_ RADIUS "the application
>> protocol", since it doesn't exist w/o reference to the underlying
>> transport.  Maybe you have your own reasons for not wanting to change
>> the name, but I do wish that this charade of claiming "backward
>> compatibility" would come to an end.  Even the creators of RADSEC
>> have conceded that it's not RADIUS, why can't you?
> 
> Well, in case you are referring to me in IETF-71, I admitted
> that there are non-trivial operational differences between the
> two transports, and that the characteristics of a stateful
> transport need to taken into account properly.
> That makes it *different from RADIUS over UDP*, but not
> substantially different from RADIUS *at all*. 

OK, one more time: you are making a distinction that doesn't exist. 

> Even you
> conceded to saying that the innermost PDU still remains as it
> is, so if nothing else, there is a core of RADIUS embedded.

No, there is something that has yet to be defined embedded because
RADIUS simply doesn't exist over a non-UDP transport.

> And I would be surprised if you don't see yourself that
> backwards compatibility is considerably easier if this PDU can
> be repackaged into a new transport without changing it (except
> the changes that any RADIUS apcket undergoes anyway on a
> RADIUS proxy, re-signing with its own shared secret).
> 
> In general, I see this discussion "is it different or not?" as
> rather pointless in the real world. Whatever one's perceived
> opinion or perceived outcome is, it doesn't change anything in the
> protocol itself. 
> 
> Greetings,
> 
> Stefan Winter
> 
> --
> Stefan WINTER
> 
> Stiftung RESTENA - Réseau Téléinformatique de l'Education
> Nationale et de la Recherche Ingenieur Forschung & Entwicklung
>

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 15 Apr 2008 14:58:15 +0700

April 15, 2008 1:07 PM:

>> isn't RADIUS, then by the same standards, any HTTPS to HTTP proxy
>> isn't doing HTTP."  A Diameter to RADIUS gateway involves terminating
>> TCP (or SCTP), TLS, and forwarding the contents to RADIUS.
> 
> With the devil being in the detail: With RadSec to RADIUS, the
> incoming packet is already a RADIUS packet as soon as it is decoded
> from the TLS tunnel. There is no translation of the content.
> With Diameter to RADIUS, non-trivial translations need to be
> done, some of which can't even be done at all right now
> (Accepts >4096 bytes payload, AVPs with >253 bytes). We have
> yet to see a Diameter translation agent that can do bijective
> translations from one to another and back again (which I
> personally see as the holy grail of compatibility). I doubt we
> will ever. With RadSec to RADIUS, this is a triviality.

I don't know how we got started down this path of arguing about the
complexity of building protocol gateways; my point is that if the only
way for two protocols to interoperate is through a gateway, those
protocols _are not_ compatible except in the most trivial of senses,
like ATM & Ethernet or IPv4 & v6 or RADIUS and RadSec.  Therefore, stop
claiming backward compatibility if for no other reason that it's
embarrassing to associated with such a nonsensical claim.

>> because you are conveniently ignoring the fact that HTTP is only
>> defined over TCP.  However, one could just as easily argue that HTTP
>> != HTTPS, given the need for different port numbers...
>> 
>>> IPv6.
>> I really don't know how that is relevant.  Dropping down a layer or
>> 2, the same protocols can be carried by both Ethernet & ATM.  Are you
>> going to claim that they are somehow compatible (backward, forward
>> or upside-down)? 
>> 
>>> Similarly, UDP transport + RADIUS application protocol is... RADIUS.
>>> TCP transport + RADIUS application protocol is... RADIUS.
>> 
>> I know that you have read RFC 2865 (probably more often than I), so
>> you know that there is no such thing as a standard "RADIUS
>> application protocol", defined w/o regard for the underlying
>> transport. 
>> 
>>>  The only way to call RadSec something other than RADIUS is if you
>>> say that FTP over IPv6 is not FTP.  After all, FTP was for IPv4,
>> 
>> One more time: the version of IP being used is transparent &
>> therefore irrelevant to FTP.  UDP transport is forever enshrined in
>> RFC 2865, however; maybe that's a bad thing, but it's true
>> nonetheless. 
>> 
>>>  Alan DeKok.
>>> 
>>> --
>>> [email-masked] with the word 'unsubscribe' in a
>>> single line as the message text body.

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 15 Apr 2008 15:15:06 +0700

...
> substantially different from RADIUS *at all*. 

OK, since RFC 2865 only defines RADIUS in terms of UDP, it must not be
the authoritative reference for "RADIUS *at all*".  What is?  I'd like
to read it...

...

---

From: Stefan Winter <[email-masked]>
Date: Tue, 15 Apr 2008 10:43:02 +0200

> the authoritative reference for "RADIUS *at all*".  What is?  I'd like

Okay, point taken. Since there's no source for RADIUS without entangled UDP 
transport, the RadSec I-D should have a section that states which parts of 
2865 are irrelevant when using a TCP transport. I.e. the draft should define 
the subset that matches the fuzzy expression of "RADIUS *at all*".

I'll go through 2865 and list the spots.

On a side note, 2865 has other hard-wired assumptions that aren't incredibly 
valid today. Are we going to split hairs on every one of them? That would 
mean making an update to 2865 though. Take for example

2. Operation

[...] If the client is valid, the RADIUS server consults a database of users 
to find the user whose name matches the request. The user entry in the 
database contains a list of requirements which must be met to allow access 
for the user.  This always includes verification of the password, but can
also specify the client(s) or port(s) to which the user is allowed access.

Enter EAP-TLS. Where's the database? What password? 

I somehow wonder why the introduction of EAP-TLS went by silently without an 
outcry that 2865 is too narrowly specified to allow this, by being hardwired 
to a specific set of auth backends. Back then, an RFC updated 2865 for EAP, 
and that was it. The fuss argumentation would be and could have been in a 
similar direction like the one we have here. It's a matter of personal liking 
or disliking a specific update I guess.

Greetings,

Stefan Winter

-- 
Stefan WINTER

---

From: Alan DeKok <[email-masked]>
Date: Tue, 15 Apr 2008 10:45:57 +0200

> the authoritative reference for "RADIUS *at all*".  What is?  I'd like

  The authoritative reference for RADIUS is this WG.  If the consensus
is to add bells, whistles, or flying monkeys to RADIUS, then that is our
perogative.

  The alternative is to worship at the holy shrine of the existing
RFC's, which were handed down from on high by the holy priests of
RADIUS.  As mere mortals, we are incapable of changing holy writ, and
must confess that the RFC's are perfect.

  I shall therefore submit a request to the RFC editor admitting that
RFC 5080 is blasphemy, as it points out *errors* in the original RFC's.
 It should therefore be withdrawn immediately, before the holy priests
of RADIUS burn me at the stake.

  Alan DeKok.

---

From: "Matt Holdrege" <[email-masked]>
Date: Tue, 15 Apr 2008 03:30:28 -0700

I'm in favor of adding improved functionality to RADIUS. What that
actually means appears to be of considerable debate.

As far as backwards compatibility is concerned, I hope everyone realizes
that RADIUS is an extremely well installed *SERVICE* and a completely
new *SERVICE* would be a waste of everyone's time. People can scream and
yell about having to twiddle bits in their servers and proxies but I
don't care. It is the clients that you should really be concerned with.

-Matt

From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Monday, April 14, 2008 3:20 PM
To: [email-masked]
Subject: Consensus Call on RADEXT WG re-charter

This is a consensus call for acceptance of the RADEXT WG re-charter.
The

list 

proposal:

---

From: "David B. Nelson" <[email-masked]>
Date: Tue, 15 Apr 2008 08:54:24 -0400

Matt Holdrege wrote:

> that RADIUS is an extremely well installed **SERVICE** and a completely 
> new **SERVICE** would be a waste of everyone’s time. People can scream 
> and yell about having to twiddle bits in their servers and proxies but I 
> don’t care. It is the clients that you should really be concerned with.

Right.  While I think the RADSEC folks indicate they have some client 
implementations, my impression of the work is that its more useful 
between the first-hop proxy and the home server.

For the RADESC folks: Is there any reason that the first-hop proxy 
couldn't terminate a RADIUS (RADIUS over UDP) session with the NAS and 
originate a RADSEC (RADIUS over TLS/TCP) session with the up-stream 
proxies or home server?

---

From: Stefan Winter <[email-masked]>
Date: Tue, 15 Apr 2008 15:06:22 +0200

Hi,

> originate a RADSEC (RADIUS over TLS/TCP) session with the up-stream

That's perfectly possible. In fact, we had planned to deploy it exactly for 
the server-to-server use case. 
It just happened that the use case of "APs in weird environments" *also* 
showed up, and there was additional merit in having client gear that speaks 
RadSec itself.

There is nothing that stops one from having RADIUS client gear and a RadSec 
server behind because the conversion is lossless.
This is what happens for my own country deployment in the Luxembourg TLD: 
upstream connection to the European root is via RadSec, while the connected 
institutions use plain RADIUS to talk to the TLD server.

Greetings,

Stefan Winter

-- 
Stefan WINTER

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 15 Apr 2008 10:45:39 -0700

SNMPv3 made the effort to define an architecture that created abstract
interfaces between modules such as security and transport as is defined
in the architecture documents you cite.  This makes it possible to
implement new transport and security mechanisms within the SNMPv3
architecture (although the architecture has to be extended somewhat to
accommodate a transport security mechanism).  RADIUS has no such formal
modular architecture.  I suppose that one could be retro-fitted, but it
hasn't been done yet.  

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Monday, April 14, 2008 10:26 PM
> To: 'Glen Zorn'; 'Alan DeKok'
> Cc: 'radext mailing list'
> Subject: SNMP vs. RADIUS transport mappings
> 
> >UDP transport is forever enshrined in RFC 2865, however; 
> maybe that's a 
> >bad thing, but it's true nonetheless.
> 
> The original transport mappings for SNMP (RFC 1089, 1906) 
> were all datagram transports.
>

---

From: "Matt Holdrege" <[email-masked]>
Date: Tue, 15 Apr 2008 11:07:46 -0700

SNMP had the full support of the IAB and IESG who pushed many years for
the full development of the protocol. RADIUS has been denigrated by a
long list of IAB and IESG leadership as something that never should have
been allowed to happen and should not have a place in any future IETF
protocol development. I don't know if it would be possible to get the
level of support needed to do what you are suggesting, but it would have
been nice to have done that work back in the 90's.

But all that is IETF politics and future RADIUS development shouldn't
worry too much about past politics.

-Matt

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Joseph Salowey (jsalowey)
Sent: Tuesday, April 15, 2008 7:46 PM
To: Bernard Aboba; Glen Zorn; Alan DeKok
Cc: radext mailing list
Subject: RE: SNMP vs. RADIUS transport mappings

---

From: Mike McCauley <[email-masked]>
Date: Wed, 16 Apr 2008 06:58:33 +1000

> originate a RADSEC (RADIUS over TLS/TCP) session with the up-stream

Thats a very common model which is permitted by the spec and supported by our 
implementation (at least), with the view of protecting the traffic while it 
traverses the internet but without requiring RadSec capable clients.

Cheers.

-- 
Mike McCauley                               [email-masked]
Open System Consultants Pty. Ltd            Unix, Perl, Motif, C++, WWW
9 Bulbul Place Currumbin Waters QLD 4223 Australia   http://www.open.com.au
Phone +61 7 5598-7474                       Fax   +61 7 5598-7070

Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, 
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, 
TTLS, PEAP etc on Unix, Windows, MacOS, NetWare etc.

---

From: "Sanchez, Mauricio (ProCurve)" <[email-masked]>
Date: Wed, 16 Apr 2008 01:21:45 +0000

I am in favor of this proposal.

MS

From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Monday, April 14, 2008 6:20 AM
To: [email-masked]
Subject: Consensus Call on RADEXT WG re-charter

proposal: 

Work Items

 

Goals and Milestones:
Jun 2008 RADIUS Design Guidelines submitted as a Best Current Practice RFC
Jun 2008 RADIUS Management Authorization I-D submitted as a Proposed
Standard RFC
Sep 2008 RADIUS Crypto-agility Requirements submitted as an Informational
RFC
Sep 2008 Extended Attributes I-D submitted as a Proposed Standard RFC
Dec 2008 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC
Mar 2009 Status-Server I-D submitted as a Proposed Standard RFC
Mar 2009 RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental RFC
June 2009 RADIUS over DTLS I-D submitted as an Experimental RFC
June 2009 RADIUS Cryptographic Algorithm Agility I-D submitted as an
Experimental RFC

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 16 Apr 2008 12:40:36 +0700

[email-masked] <> scribbled on Wednesday, April 16, 2008
1:08 AM:

> SNMP had the full support of the IAB and IESG who pushed many
> years for the full development of the protocol. RADIUS has
> been denigrated by a long list of IAB and IESG leadership as
> something that never should have been allowed to happen and
> should not have a place in any future IETF protocol
> development. I don't know if it would be possible to get the
> level of support needed to do what you are suggesting, but it
> would have been nice to have done that work back in the 90's.
> 
> But all that is IETF politics and future RADIUS development
> shouldn't worry too much about past politics.

In a perfect world that would be true; unfortunately, 'the song goes
on'...

...

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 16 Apr 2008 13:37:17 +0700

Alan DeKok <mailto:[email-masked]> scribbled on Tuesday,
April 15, 2008 3:46 PM:

> Glen Zorn wrote:
>> OK, since RFC 2865 only defines RADIUS in terms of UDP, it must not
>> be the authoritative reference for "RADIUS *at all*".  What is? I'd
>> like to read it...
> 
>  The authoritative reference for RADIUS is this WG.  If the
> consensus is to add bells, whistles, or flying monkeys to
> RADIUS, then that is our perogative.
> 
>  The alternative is to worship at the holy shrine of the
> existing RFC's, which were handed down from on high by the
> holy priests of RADIUS.  As mere mortals, we are incapable of
> changing holy writ, and must confess that the RFC's are perfect.
> 
>  I shall therefore submit a request to the RFC editor
> admitting that RFC 5080 is blasphemy, as it points out
> *errors* in the original RFC's.
> It should therefore be withdrawn immediately, before the holy
> priests of RADIUS burn me at the stake.

Could we just try to stay on topic, please?  My assertion was that to
claim "backward compatibility" between 2 protocols which can only
communicate through a translating gateway is essentially meaningless.
That has nothing to do with "priests" or "holy writ", even less with the
ludicrous claim that this WG is some kind of global help desk for RADIUS
developers.  Back to the subject at hand, you managed to define
"backward compatibility" in a slightly different context a couple of
months ago (see https://ops.ietf.org/lists/radiusext/2008/msg00000.html
for the complete message): "Everyone accepts that implementations have
to be updated to handle new standards.  One of the major efforts in
RADIUS has been to maintain backwards compatibility with existing
deployments.  i.e. if a product doesn't implement the new standard, it
can still communicate with products that do implement that standard."  A
RadSec implementation doesn't also listen on UDP 1812 pretty obviously
flunks that test (not that I think it's a particularly good one, but
it's yours).  If there is to be _any_ interoperability between RADIUS
and RadSec, then the definition of the protocol gateway behavior is at
least as, if not more, important than the standardization of RadSec.
Unfortunately, this doesn't seem to be reflected in the charter that
everyone seems in such a hurry to rubberstamp; maybe because RadSec is
by definition "backward compatible"?

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 16 Apr 2008 08:46:19 +0200

Can you guys try to agree on a paragraph which explains what 'backward
compatibility' means in the context of this charter? 

It seems to me that this is the principal item of disagreement in this
debate. 

Dan

> [mailto:[email-masked]] On Behalf Of Glen Zorn
> Sent: Wednesday, April 16, 2008 9:37 AM
> To: 'Alan DeKok'
> Cc: [email-masked]
> Subject: Meaning of "backward compatible" WAS RE: Consensus 
> Call on RADEXT WG re-charter
> 
> Alan DeKok <mailto:[email-masked]> scribbled on 
> Tuesday, April 15, 2008 3:46 PM:
> 
> > Glen Zorn wrote:
> consensus 
> > is to add bells, whistles, or flying monkeys to RADIUS, 
> then that is 
> > our perogative.
> > 
> Could we just try to stay on topic, please?  My assertion was 
> that to claim "backward compatibility" between 2 protocols 
> which can only communicate through a translating gateway is 
> essentially meaningless.
> That has nothing to do with "priests" or "holy writ", even 
> less with the ludicrous claim that this WG is some kind of 
> global help desk for RADIUS developers.  Back to the subject 
> at hand, you managed to define "backward compatibility" in a 
> slightly different context a couple of months ago (see 
> https://ops.ietf.org/lists/radiusext/2008/msg00000.html
> for the complete message): "Everyone accepts that 
> implementations have to be updated to handle new standards.  
> One of the major efforts in RADIUS has been to maintain 
> backwards compatibility with existing deployments.  i.e. if a 
> product doesn't implement the new standard, it can still 
> communicate with products that do implement that standard."  
> A RadSec implementation doesn't also listen on UDP 1812 
> pretty obviously flunks that test (not that I think it's a 
> particularly good one, but it's yours).  If there is to be 
> _any_ interoperability between RADIUS and RadSec, then the 
> definition of the protocol gateway behavior is at least as, 
> if not more, important than the standardization of RadSec.
> Unfortunately, this doesn't seem to be reflected in the 
> charter that everyone seems in such a hurry to rubberstamp; 
> maybe because RadSec is by definition "backward compatible"?  
> 
> > 
> >  Alan DeKok.
> 
> 
> 
> --

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 16 Apr 2008 00:15:37 -0700

For transport items this basically means "uses RADIUS packet formats defined in RFC 2865, 2866 and 5176" (although the ports can be different).

---

From: Alan DeKok <[email-masked]>
Date: Wed, 16 Apr 2008 10:07:18 +0200

Bernard Aboba wrote:
> For transport items this basically means "uses RADIUS packet formats
> defined in RFC 2865, 2866 and 5176" (although the ports can be different).

  Yes.

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 16 Apr 2008 15:15:26 +0700

Romascanu, Dan (Dan) <mailto:[email-masked]> scribbled on Wednesday,
April 16, 2008 1:46 PM:

> Can you guys try to agree on a paragraph which explains what
> 'backward compatibility' means in the context of this charter?

The term is meaningless in the context of this charter & should be
removed or at the very least _highly_ qualified.  Saying (as the
currently proposed charter does) that "All RADIUS work MUST be backward
compatible with existing RADIUS RFCs" is just absurd.  That said, the
following paragraph would work, Think:

- All documents produced MUST specify means of interoperation with
legacy RADIUS implementations and, if possible, be backward 
compatible with existing RADIUS RFCs, including RFCs 2865-2869, 
3162, 3575, 3579, 3580, 4668-4673,4675, 5080, 5090 and 5176.

> 
> It seems to me that this is the principal item of disagreement in
> this debate. 
> 
> Dan
> 

...

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 16 Apr 2008 15:19:49 +0700

Bernard Aboba <mailto:[email-masked]> scribbled on Wednesday,
April 16, 2008 2:16 PM:

> For transport items this basically means "uses RADIUS packet
> formats defined in RFC 2865, 2866 and 5176" (although the
> ports can be different).

So what you're saying is that two nodes can be unable to communicate &
still be "backward compatible"?

---

From: Avi Lior <[email-masked]>
Date: Wed, 16 Apr 2008 12:19:50 -0400

There is a very interesting thing happening here with the notion of adding a new transport to RADIUS: specifically TCP/TLS transport to RADIUS.

In recent experiences in other SDOs people were concerned about the scalability of Diameter.  Specifically, in the hot arena of Femto Cells and Diameter, people were wondering how a diameter server would maintain 100,000 plus connections with the femtos.  This without using multiple servers.

So here we are thinking about perhaps introducing a UDP transport or something equivalent for the Diameter server -- at least for that first hop between the femto cell in your home and the operator's site.

Perhaps the right approach for these protocols is to allow them to utilize the correct transport for the job at hand.  Having no choice is seemingly problematic.

 Avi

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, April 14, 2008 9:20 AM
To: [email-masked]
Subject: Consensus Call on RADEXT WG re-charter

Work Items

Goals and Milestones:

---

From: Mudit Goel <[email-masked]>
Date: Wed, 16 Apr 2008 09:27:36 -0700

Mudit Goel

Work Items

Goals and Milestones:

---

From: "David B. Nelson" <[email-masked]>
Date: Wed, 16 Apr 2008 13:02:26 -0400

Glen Zorn writes...

> So what you're saying is that two nodes can be unable to 
> communicate & still be "backward compatible"?

I don't think that's what was meant.

I think understand your position:

-- The use of UDP is mandated in RFC 2865.

-- Packets sent by clients over UDP to Port 1812, won't be received by a
server listening on TCP Port <TBA>.

An alternate point of view is that a RADIUS client or server implementation
doesn't need to change very much if the sockets that it opens are stream
sockets as opposed to datagram sockets.  The data flow, above the socket
layer, (i.e. the application PDU stream) is the same.  In that regard, the
RADIUS protocol specification relies upon, but does not include the socket
layer and all the layers below.

---

From: "Matt Holdrege" <[email-masked]>
Date: Wed, 16 Apr 2008 10:21:02 -0700

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of David B. Nelson

An alternate point of view is that a RADIUS client or server
implementation
doesn't need to change very much if the sockets that it opens are stream
sockets as opposed to datagram sockets.  The data flow, above the socket
layer, (i.e. the application PDU stream) is the same.  In that regard,
the
RADIUS protocol specification relies upon, but does not include the
socket
layer and all the layers below.

------------------------------------------------------------------------
-----------------

The above would be a heck of an assumption to make for all RADIUS
clients out in the field. The real world is rarely as simple as a high
level protocol architecture document. RADIUS has always used UDP and
perhaps a lot of developers have counted on that and never developed
their products to be socket layer neutral. Not to mention that a
firmware change of clients is not really an option in most cases.
However as I said before, it's nothing much to cry about on the server
side.

---

From: "David B. Nelson" <[email-masked]>
Date: Wed, 16 Apr 2008 13:50:34 -0400

Matt Holdrege writes...

> RADIUS has always used UDP and perhaps a lot of developers have 
> counted on that and never developed their products to be socket
> layer neutral.

This is quite possible.

> Not to mention that a firmware change of clients is not really 
> an option in most cases.

My personal (individual WG member) opinion is that the RADSEC work is
interesting for proxy-to-proxy and proxy-to-home-server usages.  I think
that it would be fairly rare to see it in NAS-to-server or NAS-to-proxy
cases.  That takes most of the "sting" out of the "wedded-to-UDP" issues
with NAS-based client implementations.  I think of proxies as being a server
and client glued together, BTW.

---

From: "Matt Holdrege" <[email-masked]>
Date: Wed, 16 Apr 2008 11:00:08 -0700

-----Original Message-----
From: David B. Nelson [mailto:[email-masked]] 
Sent: Wednesday, April 16, 2008 7:51 PM

Matt Holdrege writes...

This is quite possible.

with NAS-based client implementations.  I think of proxies as being a
server

--------------------------------------------------------------

OK, that's fine, but then if *real* RADIUS clients aren't really a part
of this effort, then why is it in this WG? I assume you have some reason
for not using IETF recommended IPsec to secure proxy-to-proxy data? If
so, why don't you create another proxy-server to proxy-server encryption
protocol?

Sorry, I expect this has been discussed before already. If so, disregard
my question.

-Matt

---

From: "David B. Nelson" <[email-masked]>
Date: Wed, 16 Apr 2008 14:07:26 -0400

Matt Holdrege writes...

> OK, that's fine, but then if *real* RADIUS clients aren't really
> a part of this effort, then why is it in this WG?

Hmmm.  Because the WG isn't limited to considering only RADIUS extensions
that [primarily] impact the NAS?

> I assume you have some reason for not using IETF recommended IPsec
> to secure proxy-to-proxy data? 

That issue has been discussed.  There are implementations and deployments of
RADIUS over IPsec.  The thing that some folks don't like about IPsec is that
it's a Layer 3 protocol and isn't visible to applications at Layer 4 (e.g.
at the socket interface) the way TLS is.  

> If so, why don't you create another proxy-server to proxy-server
> encryption protocol?

One could claim that RADSEC neatly fills that bill.

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 17 Apr 2008 12:02:28 +0700

[email-masked] <> scribbled on Thursday, April 17, 2008
1:07 AM:

> Matt Holdrege writes...
> 
>> OK, that's fine, but then if *real* RADIUS clients aren't really a
>> part of this effort, then why is it in this WG?
> 
> Hmmm.  Because the WG isn't limited to considering only RADIUS
> extensions that [primarily] impact the NAS?

Hmmm.  Since _everything_ has to change, how can you say that?

> 
>> I assume you have some reason for not using IETF recommended IPsec to
>> secure proxy-to-proxy data?
> 
> That issue has been discussed.  There are implementations and
> deployments of RADIUS over IPsec.  The thing that some folks
> don't like about IPsec is that it's a Layer 3 protocol and
> isn't visible to applications at Layer 4 (e.g.

Conceptually, yes; it's nowhere near fully baked from a standards POV
IMHO, but it (or something very similar) has been working in very large
commercial roaming networks for a very long time.  BTW (since it doesn't
seem to have gotten through to some people) let me say it again: I am
not & never have been opposed to the standardization of RadSec.  I think
that it's a mistake to undertake the task in this WG (not least of all
because of an obvious antagonism to innovation on the part of some
members) but since the tide of opinion seems to be to do that it's fine.
I AM REALLY OPPOSED TO BS, however & I don't really understand this
manic grasping at straws to claim RadSec's "backward compatibility", to
the point that now we have 'if you used this interface when you wrote
your code (as opposed to the easy, obvious one)' then it's really almost
the same but not quite'.  Please.

...

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 17 Apr 2008 12:34:57 +0700

11:20 PM:

> There is a very interesting thing happening here with the
> notion of adding a new transport to RADIUS: specifically
> TCP/TLS transport to RADIUS.
> 
> In recent experiences in other SDOs people were concerned
> about the scalability of Diameter.  Specifically, in the hot
> arena of Femto Cells and Diameter, people were wondering how a
> diameter server would maintain 100,000 plus connections with
> the femtos.  This without using multiple servers.
> 
> So here we are thinking about perhaps introducing a UDP
> transport or something equivalent for the Diameter server --
> at least for that first hop between the femto cell in your
> home and the operator's site.
> 
> Perhaps the right approach for these protocols is to allow
> them to utilize the correct transport for the job at hand.
> Having no choice is seemingly problematic.

Good point.  On that note, it seems that RadSec (as currently specified)
creates one new option but eliminates another.  Would it be worthwhile
defining RADIUS over TCP, & then how to use TLS to protect it?

...

---

From: Avi Lior <[email-masked]>
Date: Thu, 17 Apr 2008 13:17:07 -0400

> From: Glen Zorn [mailto:[email-masked]]
> Sent: Thursday, April 17, 2008 1:35 AM
> To: Avi Lior
> Cc: [email-masked]; [email-masked]
> Subject: RE: Consensus Call on RADEXT WG re-charter
>
> [email-masked] <> scribbled on Wednesday, April
> 16, 2008 11:20 PM:
>
> > There is a very interesting thing happening here with the notion of
> > adding a new transport to RADIUS: specifically TCP/TLS transport to
> > RADIUS.
> >
> > In recent experiences in other SDOs people were concerned about the
> > scalability of Diameter.  Specifically, in the hot arena of Femto
> > Cells and Diameter, people were wondering how a diameter
> server would
> > maintain 100,000 plus connections with the femtos.  This
> without using
> > multiple servers.
> >
> transport or
> > something equivalent for the Diameter server -- at least for that
> > first hop between the femto cell in your home and the
> operator's site.
> >
> > Perhaps the right approach for these protocols is to allow them to
> > utilize the correct transport for the job at hand.
> Good point.  On that note, it seems that RadSec (as currently
> specified) creates one new option but eliminates another.
> Would it be worthwhile defining RADIUS over TCP, & then how
> to use TLS to protect it?

Yes.

---

From: "David B. Nelson" <[email-masked]>
Date: Thu, 17 Apr 2008 18:14:27 -0400

Glen Zorn writes...

> I AM REALLY OPPOSED TO BS, however ...

If I thought that slam was targeted at me, I might be offended.  :-)

> ... I don't really understand this manic grasping at straws to 
> claim RadSec's "backward compatibility", to the point that now we
> have 'if you used this interface when you wrote your code (as opposed
> to the easy, obvious one)' then it's really almost the same but not
> quite'.

We need a reasonable definition of "backward compatible" to scope this work.
It needs to be unambiguous, so that we can tell when it has or has not been
met.  It has to be simple enough that we can understand it.

Whether or not you agree that RADIUS *has* an application layer
specification that can be divorced from a specific transport binding, it is
important that the RADSEC specification (or any other alternate transport
specifications for RADIUS) make it clear that all we want to tinker with in
this work item is the *transport* layer.  We want the RADIUS PDUs to remain
otherwise unchanged.

What's wrong with that?

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 18 Apr 2008 11:28:18 +0700

[email-masked] <> scribbled on Friday, April 18, 2008 5:14
AM:

...

>> ... I don't really understand this manic grasping at straws to claim
>> RadSec's "backward compatibility", to the point that now we have 'if
>> you used this interface when you wrote your code (as opposed to the
>> easy, obvious one)' then it's really almost the same but not quite'.
> 
> It needs to be unambiguous, so that we can tell when it has or
> has not been met.  It has to be simple enough that we can understand
> it. 

I agree completely.  What is amazing is that, given the fact that
"backward compatibility" has been in the charter since the WG was formed
(& has been used as a stick to beat to death several useful proposals),
this definition doesn't already exist.  In fact, its utility as an ad
hoc bludgeon is such that I doubt that such a clear, unambiguous
definition will be forthcoming (let alone written into the charter).  I
sincerely hope that I'm proven wrong...

> 
> Whether or not you agree that RADIUS *has* an application
> layer specification that can be divorced from a specific
> transport binding, it is important that the RADSEC
> specification (or any other alternate transport specifications
> for RADIUS) make it clear that all we want to tinker with in
> this work item is the *transport* layer.  We want the RADIUS
> PDUs to remain otherwise unchanged.
> 
> What's wrong with that?

One thing that's wrong is that it ignores the limitations on the RADIUS
PDU that exist primarily (or solely) because of the UDP transport.  One
example: the maximum length of 4096 octets for a Radius packet was
chosen (IIRC) based upon the maximum size of a _UDP_ frame that could be
reliably transmitted w/o fragmentation _in the access networks of the
day_.  It doesn't seem to be very smart to go to all the trouble of
defining RADIUSoTCP while leaving this kind of unnecessary, UDP-specific
limitation in place.

...

---

From: "Matt Holdrege" <[email-masked]>
Date: Fri, 18 Apr 2008 00:21:33 -0700

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of David B. Nelson
Sent: Friday, April 18, 2008 12:14 AM
Glen Zorn writes...

> to the easy, obvious one)' then it's really almost the same but not

We need a reasonable definition of "backward compatible" to scope this
work.
It needs to be unambiguous, so that we can tell when it has or has not
been
met.  It has to be simple enough that we can understand it.

Whether or not you agree that RADIUS *has* an application layer
specification that can be divorced from a specific transport binding, it
is
important that the RADSEC specification (or any other alternate
transport
specifications for RADIUS) make it clear that all we want to tinker with
in
this work item is the *transport* layer.  We want the RADIUS PDUs to
remain
otherwise unchanged.

What's wrong with that?

----------------------------------------------------------------

If you go by the assumption, as reality pretty much dictates, that
RADIUS is not divorced from specific transport binding, then you should
be very cautious to avoid creating a heck of a lot of confusion
downstream from where we sit. For the last umpteen years RADIUS has been
RADIUS. True we have caused all sorts of havoc with attributes, but that
hasn't killed basic interoperability between RADIUS clients and servers.
This new effort would kill that basic interoperability. Therefore you
need to make very clear that the result of this work will NOT be
interoperable with the massive world-wide deployment of RADIUS clients.

-Matt

---

From: Stefan Winter <[email-masked]>
Date: Fri, 18 Apr 2008 10:01:30 +0200

Hi,

> interoperable with the massive world-wide deployment of RADIUS clients.

Well, if an implementation would do RadSec exclusively, and NOT listen on 
UDP/1812 as well, then yes, RADIUS clients would not be able to communicate 
with that implementation.

Reality however is that all the implementations so far can do both, UDP/1812 
and RadSec on TCP/2083, and are able to translate between both. Such 
implementations *are* interoperable with existing RADIUS clients.

Since this is a (sane) behaviour by all implementations so far, it might be 
wise to add an according note to the RadSec I-D that: if interoperability 
with standard RADIUS clients is required, the implementation also has to 
listen on UDP/1812 (I used to think that goes without saying, but it 
certainly doesn't hurt to put that sentence in there). I wouldn't want to 
mandate this for all implementations as a MUST though, since I can easily 
imagine proxy interconnections in a backend that have no business with NASes, 
and for such deployments it would just be an unnecessary burden to mandate 
listening in UDP/1812.

Greetings,

Stefan Winter

-- 
Stefan WINTER

---

From: "David B. Nelson" <[email-masked]>
Date: Fri, 18 Apr 2008 10:52:12 -0400

Stefan Winter writes...

> Well, if an implementation would do RadSec exclusively, and NOT 
> listen on UDP/1812 as well, then yes, RADIUS clients would not be
> able to communicate with that implementation.
> 
> Reality however is that all the implementations so far can do
> both, UDP/1812 and RadSec on TCP/2083, and are able to translate 
> between both. Such implementations *are* interoperable with existing
> RADIUS clients.

So one of the elements of our backwards compatibility definition might be
that any implementation (server or proxy) of RADIUS over a non-UDP transport
that will be used to directly service a NAS MUST additionally implement a
"RADIUS Classic" UDP/1812 listener.

---

From: "David B. Nelson" <[email-masked]>
Date: Fri, 18 Apr 2008 11:00:49 -0400

Glen Zorn writes...

>  One example: the maximum length of 4096 octets for a Radius packet
> was chosen (IIRC) based upon the maximum size of a _UDP_ frame that
> could be reliably transmitted w/o fragmentation _in the access 
> networks of the day_.

I've forgotten that discussion.  Isn't 4096 the maximum size *any* UDP
frame, IP fragmentation and reassembly notwithstanding?

> It doesn't seem to be very smart to go to all the trouble of 
> defining RADIUSoTCP while leaving this kind of unnecessary, 
> UDP-specific limitation in place.

I recall that you have many times advocated the need for longer RADIUS
packets and/or more/longer RADIUS attributes.

It is true that any RADSEC to RADIUS gateway needs to address what is to be
done about larger than UDP-size RADSEC messages in translating them to
RADIUS messages.

I need to see if that issue is covered in the "AAA Transports" RFC...

I believe that addressing this issue ought to be another element of our
definition of backwards compatibility for RADIUS over non-UDP transports.

---

From: "Glen Zorn" <[email-masked]>
Date: Sat, 19 Apr 2008 14:16:12 +0700

[email-masked] <> scribbled on Friday, April 18, 2008
10:01 PM:

> I've forgotten that discussion.  Isn't 4096 the maximum size
> *any* UDP frame, IP fragmentation and reassembly notwithstanding?

No.  The Length field in the UDP header is 16 bits long; RFC 768 notes
that the minimum length is 8 octets but doesn't mention any maximum.

> 
>> It doesn't seem to be very smart to go to all the trouble of defining
>> RADIUSoTCP while leaving this kind of unnecessary, UDP-specific
>> limitation in place.
> 
> I recall that you have many times advocated the need for
> longer RADIUS packets and/or more/longer RADIUS attributes.

This isn't my personal opinion: I have just been echoing customer
requests.  
> 
> It is true that any RADSEC to RADIUS gateway needs to address
> what is to be done about larger than UDP-size RADSEC messages
> in translating them to RADIUS messages.
> 
> I believe that addressing this issue ought to be another
> element of our definition of backwards compatibility for
> RADIUS over non-UDP transports.

The first thing to be addressed is the (bogus) usage of the term
"backward compatibility" in the proposed charter.  PLEASE replace it
with "interoperable" or a synonym thereof.

---

From: "David B. Nelson" <[email-masked]>
Date: Sat, 19 Apr 2008 08:46:43 -0400

Glen Zorn writes...

> with "interoperable" or a synonym thereof.

With all due respect, this seems to me like another "name game" issue.
Let's worry more about what we want the properties to be, and less about
what we call it

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 20 Apr 2008 03:20:07 +0700

[email-masked] <> scribbled on Saturday, April 19, 2008
7:47 PM:

> Let's worry more about what we want the properties to be, and
> less about what we call it

A wonderful attitude, except that the only thing the IETF produces is
words; therefore, it behooves us to make sure that those words are
correct.  It's not a game (or if it is, it's the only one in (our)
town).

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 21 Apr 2008 09:59:31 -0400

Glen Zorn writes...

> A wonderful attitude, except that the only thing the IETF produces
> is words; therefore, it behooves us to make sure that those words
> are correct.

Yes, and I think that what is correct in this case will not be accurately
described by a well-used phrase such as "backwards compatible" or
"interoperable".  I think we need spell out exactly what we expect, in a
couple of sentences.

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 22 Apr 2008 12:10:01 +0700

[email-masked] <> scribbled on Monday, April 21, 2008 9:00
PM:

>> correct.
> Yes, and I think that what is correct in this case will not be
> accurately described by a well-used phrase such as "backwards
> compatible" or "interoperable".  I think we need spell out
> exactly what we expect, in a couple of sentences.

Good idea.

...

---

From: Stefan Winter <[email-masked]>
Date: Fri, 25 Apr 2008 14:20:18 +0200

Hi,

> defining RADIUSoTCP while leaving this kind of unnecessary, UDP-specific

You are perfectly right in condemning the number 4096. It was a limitation 
which was pretty much arbitrary. When using TCP, one wouldn't be forced to 
keep it if using the TCP transport _only_, from end to end.

But giving up on this limitation would completely ruin translation back to 
RADIUS-as-in-2865. Which is a common use for existing RADIUS deployments 
where the NAS speaks RADIUS only. And from what I gathered in this discussion 
so far it is seen as being of paramount importance that this translation 
works.

I think I remember a discussion a while back about what to do with Diameter 
Accepts above 4096 Bytes, and how to build a translation agent that is able 
to turn this into RADIUS. IIRC, the outcome was that it isn't possible at 
all, and that an Accept which is too large has to be translated into a 
Reject. (the discussion took place when talking about NAS-Filter-Rule and the 
issue "Diameter-RADIUS gateway behavior not completely specified" in general)

I definitely want to steer clear of this. Unfortunately, the only way of doing 
so is to stay with 4096. Maybe an option would be: if a deployment scenario 
can be *sure* to be free of plain RADIUS elements everywhere, it MAY use 
larger payloads.

But honestly, I'd prefer to keep it as simple and error-proof (as in: 
configuration errors) as possible and forbid larger payloads outright. 

Greetings,

Stefan Winter

P.S.: 4096 was the max "_in the access networks of the day_"? Anyone have a 
clue what that network was? Token Ring?

-- 
Stefan WINTER

---

From: Stefan Winter <[email-masked]>
Date: Fri, 25 Apr 2008 14:35:54 +0200

Hi,

> defining RADIUS over TCP, & then how to use TLS to protect it?

That sounds good to me. In some earlier offline discussions I also heard of 
people wanting to do RADIUS-over-SSH-TCP-port-forwarding. Not my personal 
favourite, but still.

The idea would then be to have one document about:

- identifying parts of 2865 that are of relevance for UDP only
- how to replace those UDP transport specifics with TCP

and another document about

- using (D)TLS to secure the payload

(where I would hope that DTLS and TLS have enough similarities to warrant 
being put into one document. Not sure about that though.)

RadSec would then be the application of both in conjunction.

Does that sound acceptable?

Greetings,

Stefan

-- 
Stefan WINTER

---

From: "Glen Zorn" <[email-masked]>
Date: Sat, 26 Apr 2008 00:48:22 +0700

Stefan Winter <mailto:[email-masked]> scribbled on Friday,
April 25, 2008 7:20 PM:

> Hi,
> 
>> One thing that's wrong is that it ignores the limitations on the
>> RADIUS PDU that exist primarily (or solely) because of the UDP
>> transport.  One example: the maximum length of 4096 octets for a
>> Radius packet was chosen (IIRC) based upon the maximum size of a
>> _UDP_ frame that could be reliably transmitted w/o fragmentation _in
>> the access networks of the day_.  It doesn't seem to be very smart
>> to go to all the trouble of defining RADIUSoTCP while leaving this
>> kind of unnecessary, UDP-specific limitation in place.
> 
> You are perfectly right in condemning the number 4096. It was
> a limitation which was pretty much arbitrary. When using TCP,
> one wouldn't be forced to keep it if using the TCP transport _only_,
> from end to end. 
> 
> But giving up on this limitation would completely ruin
> translation back to RADIUS-as-in-2865. Which is a common use
> for existing RADIUS deployments where the NAS speaks RADIUS
> only. And from what I gathered in this discussion so far it is
> seen as being of paramount importance that this translation works.
> 
> I think I remember a discussion a while back about what to do
> with Diameter Accepts above 4096 Bytes, and how to build a
> translation agent that is able to turn this into RADIUS. IIRC,
> the outcome was that it isn't possible at all, and that an
> Accept which is too large has to be translated into a Reject.

"Impossible" is such an interesting word, especially when applied to
software ;-).  It's certainly _technically_ possible to do this with a
slight modification of the RADIUS protocol; what seems to be
_politically_ impossible is making the slight change.

> (the discussion took place when talking about NAS-Filter-Rule
> and the issue "Diameter-RADIUS gateway behavior not completely
> specified" in general) 
> 
> I definitely want to steer clear of this. Unfortunately, the
> only way of doing so is to stay with 4096. Maybe an option
> would be: if a deployment scenario can be *sure* to be free of
> plain RADIUS elements everywhere, it MAY use larger payloads.

That seems a bit Draconian: al that is necessary (without the minor
change mentioned above) is that RadSec gateways never forward an illegal
RADIUS packet to a RADIUS client or server (it's really very useful to
treat the two as distinct protocols).

...

---

From: "Glen Zorn" <[email-masked]>
Date: Sat, 26 Apr 2008 00:50:27 +0700

April 25, 2008 7:36 PM:

...

> (where I would hope that DTLS and TLS have enough similarities
> to warrant being put into one document. Not sure about that though.)

Personally, I'd much prefer keeping these things neatly separated.

...