Subject: request to recharter

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

Hello,

the topic of re-chartering radiusext to accomodate the RadSec work has been a 
continuous topic in the last two meetings, the mailing list and in several 
offline discussions.
The last meeting in Vancouver suggested to move the three most promising 
crypto-agility suggestions (keywrap, dtls, radsec) to EXP status within 
radext.
RadSec is being implemented in various independent codebases and is in 
production use today.

The points above make me think that it is about time to seriously consider 
that the radext charter is modified to include RadSec into the working group 
scope.

The DTLS draft led to consensus that TLS-style payload encryption is not 
considered being a new security mechanism for protecting RADIUS (which would 
be excluded by the charter as-is). Then, the same holds true for the TLS part 
of the radsec draft, which in turn means this part of the charter does not 
need changing.

The only part in the charter that would need to be changed is, obviously, the 
line

"- No new RADIUS transports (e.g. TCP, SCTP) will be defined."

which I request to purge from the charter.

After being included in the radext WG scope, the radsec draft would certainly 
be rewritten for more normative wording. Because up to now, it was meant as 
an FYI description of existing implementations, not in any way a standard. 
When EXP is a target, language should change accordingly. I volunteer to do 
this to the best of my knowledge - it is my first I-D at all.

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: "Glen Zorn" <[email-masked]>
Date: Tue, 12 Feb 2008 08:03:49 +0700

Stefan Winter <> scribbled on Monday, February 11, 2008 5:26 PM:

> Hello,
> 
> the topic of re-chartering radiusext to accomodate the RadSec work
> has been a continuous topic in the last two meetings, the mailing
> list and in several offline discussions.  

Yes, there has been a popular upswell of support for abandoning our work
in favor of yours -- oh, wait, that would be you alone...

> The last meeting in Vancouver suggested to move the three most
> promising crypto-agility suggestions (keywrap, dtls, radsec) to EXP
> status within radext.  
> RadSec is being implemented in various independent codebases and is
> in production use today. 
> 
> The points above make me think that it is about time to seriously
> consider that the radext charter is modified to include RadSec into
> the working group scope.  

Yes, there has been a popular upswell of support for abandoning our work
in favor of yours -- oh, wait, that would be you again...

> 
> The DTLS draft led to consensus that TLS-style payload encryption is
> not considered being a new security mechanism for protecting RADIUS
> (which would be excluded by the charter as-is). Then, the same holds
> true for the TLS part of the radsec draft, which in turn means this
> part of the charter does not need changing.    
> 
> The only part in the charter that would need to be changed is,
> obviously, the line 
> 

No, no, NO!  "radsec" is not RADIUS, period.  Not an extension, not even
a perversion, not RADIUS.  I would support a radsec BOF & WG, but I will
not support this.

> 
> After being included in the radext WG scope, the radsec draft would
> certainly be rewritten for more normative wording. Because up to now,
> it was meant as an FYI description of existing implementations, not
> in any way a standard.   
> When EXP is a target, language should change accordingly. I volunteer
> to do this to the best of my knowledge - it is my first I-D at all. 
> 
> 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: "Bernard Aboba" <[email-masked]>
Date: Mon, 11 Feb 2008 18:12:41 -0800

> in favor of yours -- oh, wait, that would be you again...

[BA] Completion of the existing RADEXT WG work items has always been a 
precondition for re-chartering.   There has never been a discussion of 
"abandoning" existing work items.  Once the Design Guidelines, Management 
Attributes and Extended Attributes documents complete WG last call and
are forwarded to the IESG, the remaining work items left will be the
IEEE 802 attributes document, and the Crypto-agility draft.   

At that point a discussion of Re-Chartering would be appropriate.  

> a perversion, not RADIUS.  I would support a radsec BOF & WG, but I will

[BA] The IETF process involves "rough consensus and running code".   
During the RADEXT WG re-charter discussion, the opinion of all 
WG participants will be taken into account. 

With respect to RADSEC, the minutes of IETF 69 show that as part of the 
crypto-agility portion of the meeting, there was a consensus call on 
potential solutions, and that RADSEC got considerable support.    
We did not follow up with a consensus call on the list since 
RADSEC was outside the RADEXT WG charter.   However,
during a re-charter discussion, this and other potential 
WG work items will be open to discussion.

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 11 Feb 2008 18:24:59 -0800

Bernard Aboba <> scribbled on Monday, February 11, 2008 6:13 PM:

>> Yes, there has been a popular upswell of support for abandoning our
>> work in favor of yours -- oh, wait, that would be you again...
> 
> "abandoning" existing work items.  

I didn't say "work items", I said "work", meaning RADIUS.  This is a new
& different protocol, more akin to Diameter than RADIUS & does not
belong in this WG.

> Once the Design Guidelines,
> Management Attributes and Extended Attributes documents complete WG
> last call and are forwarded to the IESG, the remaining work items
> left will be the IEEE 802 attributes document, and the Crypto-agility
> draft.   
> 
>> No, no, NO!  "radsec" is not RADIUS, period.  Not an extension, not
>> even a perversion, not RADIUS.  I would support a radsec BOF & WG,
>> but I will not support this.
> 
> During the RADEXT WG re-charter discussion, the opinion of all WG
> participants will be taken into account. 
> 
> With respect to RADSEC, the minutes of IETF 69 show that as part of
> the crypto-agility portion of the meeting, there was a consensus call
> on  
> during a re-charter discussion, this and other potential WG work
> items will be open to discussion. 

Fine, just change the WG name "radsec" as well.

---

From: "David B. Nelson" <[email-masked]>
Date: Tue, 12 Feb 2008 11:04:03 -0500

Glen Zorn writes...

> No, no, NO!  "radsec" is not RADIUS, period.  Not an extension, 
> not even a perversion, not RADIUS.

Without offering any opinion as to whether RADEXT should seek to amend its
charter to include RADSEC, let me ask why RADIUS over TLS/TCP is
conceptually so different from RADIUS over IPSec?  Seems to me that both are
RADIUS encapsulated in protected transport.  We are also considering RADIUS
over DTLS/UDP, and you don't seem to be quire so concerned about that
proposal.  Is it the use of TCP that bothers you so much?

---

From: Stefan Winter <[email-masked]>
Date: Wed, 13 Feb 2008 15:45:29 +0100

Hi,

> in favor of yours -- oh, wait, that would be you alone...

well, first: it's not abandoning abandoning RADIUS work. In fact, the RADIUS 
payload is left completely untouched.

Second: it wasn't me alone. I was the one who showed up at IETF, that's right. 
But as you very well know, there was an implementation out there for years 
which had customers, and RadSec has proved useful to a worldwide-operating 
roaming consortium, and has been implemented by other parties meanwhile. If I 
had gotten an outright reject from the radext group as whole I wouldn't have 
taken the step to ask for rechartering. But if you recall IETF69+70, there 
*was* support for the work. Yes, there has also been an outcry to ignore 
RadSec completely -- oh, wait, that was you alone...

> a perversion, not RADIUS. 

We've had a discussion on that topic before on this list. That time, at the 
end you resorted to a strange analogy of ducks and snakes IIRC, not providing 
a reasonable argumentation.

> I would support a radsec BOF & WG, but I will not support this.

*Thank you*! It is very nice to read that you would support a WG for that 
work, which appears to imply that you see the concept as worthy for 
exploration and eventual standardisation. Actually, I had been thinking about 
this way forward as well. The outcome was that creating a whole new working 
group for this one thing probably isn't justified. After all, it is not 
likely to create follow-up work, it's pretty much a standalone thing to add 
to RADIUS.
So, if a working group isn't justified due to lack of amount of work, but the 
work is still somewhat important, where would the place to go be? My 
conclusion was that radext is the place to go. And I still think that 
reasoning is justified, Bernard's reply in the thread looks like it is at 
least deemed worth a consideration.

Greetings,

Stefan Winter

-- 
Stefan WINTER

---

From: Alan DeKok <[email-masked]>
Date: Wed, 13 Feb 2008 17:56:43 +0100

> that the radext charter is modified to include RadSec into the working group 

  I have no objections, presuming that TCP is also accepted as a
transport protocol.

> which I request to purge from the charter.

  I'm not sure I understand all of Glen's concerns, but TCP as a
transport protocol is a fairly large change to RADIUS.  The basic
send/receive concepts don't change.  The packet formats don't change,
but there are issues relating to TCP && AAA stability, as discussed in
RFC 3539.

  I have no major objections to this.  If TCP is accepted, I would
suggest a draft focussed on issues relating to TCP as a transport
protocol.  The RadSec document can then reference this draft.

  Alan DeKok.

---

From: "David B. Nelson" <[email-masked]>
Date: Wed, 13 Feb 2008 12:39:23 -0500

Alan DeKok writes...

> If TCP is accepted, I would suggest a draft focussed on issues 
> relating to TCP as a transport protocol.

I think that would be warranted, whether in a separate document or
integrated.  Someone sent me an off-list reply, expressing concern about
changes to the RADIUS paradigm for timeouts and retransmissions, when using
TCP.  Those issues would certainly need to be addressed.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 13 Feb 2008 19:00:47 +0100

> TCP.  Those issues would certainly need to be addressed.

  RFC 3539 already has a suggested retransmission and timeout algorithm
for AAA protocols over TCP.  I think that could be used.

  Any document for RADIUS + TCP would need to concentrate on
RADIUS-specific issues.  e.g. UDP RADIUS practices are NOT appropriate
when TCP is used as a transport protocol.

  Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 13 Feb 2008 15:04:07 -0800

> TCP.  Those issues would certainly need to be addressed.

There is already a proposed standard for the transport of AAA protocols over TCP,
"Authentication, Authorization and Accounting (AAA) Transport Profile", RFC 3539. 
--
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: Bernard Aboba <[email-masked]>
Date: Wed, 13 Feb 2008 15:09:15 -0800

> If TCP is accepted, I would suggest a draft focussed on issues relating to TCP as a transport

Since RFC 3539 already defines the transport profile and failover algorithms
for AAA running over TCP/SCTP, I am not clear what remaining work is
required in that area. 
--
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: "David B. Nelson" <[email-masked]>
Date: Wed, 13 Feb 2008 18:21:33 -0500

Bernard Aboba writes...

> There is already a proposed standard for the transport of AAA protocols
> over TCP, "Authentication, Authorization and Accounting (AAA) Transport
> Profile", RFC 3539.

Yes.  Alan pointed that out in a follow up message.  Was that document
created as part of the Diameter requirements work?  Just curious.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 14 Feb 2008 07:13:22 +0100

> for AAA running over TCP/SCTP, I am not clear what remaining work is

  Partly psychological... people are more likely to read a "RADIUS over
TCP" document than an "AAA over TCP" document.  Also, standardizing TCP
as a RADIUS transport would require the publication of *some* kind of
document, if I understand the IETF process correctly.  We couldn't just
announce that it's OK...

  The "RADIUS over TCP" document could reference existing RADIUS
practices, and explain in excruciating detail why they won't work for TCP.

  Also, some issues relating to RADIUS PDU's over a stream transport may
be discussed.  e.g. receiving half a RADIUS packet and then a FIN is
*not* a problem.  The MIB counters for
radiusAuthServMalformedAccessRequests should NOT be incremented.  e.g.
receiving a PDU with malformed attributes means that the TCP connection
SHOULD be closed.

  Many RADIUS practices related to handling error cases require a PDU to
be "silently discarded".  This won't work for TCP.  The connection has
to be closed, too.  The existing RFC's have to be audited, and a new
document issued which explains the correct behavior.

  Alan DeKok.

---

From: Stefan Winter <[email-masked]>
Date: Thu, 14 Feb 2008 08:58:24 +0100

Hi,

> document, if I understand the IETF process correctly.  We couldn't just

The draft currently already references 3539, in section "Connection 
Keepalive": 

" A RadSec node which initiates a RadSec connection SHOULD send the
   Status-Server packets defined in [10] according to the state machine
   in section 3.4 of [6] since RadSec operates on a reliable transport
   protocol."

where [6] is a reference to 3539. That text could be made more explicitly 
though, and reference 3539 as a whole, not just the one section with the 
state machine.

> document issued which explains the correct behavior.

Sounds plausible.

Greetings,

Stefan

-- 
Stefan WINTER

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 14 Feb 2008 15:07:22 +0700

Stefan Winter <mailto:[email-masked]> scribbled on Wednesday,
February 13, 2008 9:45 PM:

>> work in favor of yours -- oh, wait, that would be you alone...
>
> well, first: it's not abandoning abandoning RADIUS work. In fact, the
> RADIUS payload is left completely untouched.
>
> But as you very well know, there was an implementation out there for
> years which had customers, and RadSec has proved useful to a
> worldwide-operating roaming consortium, and has been implemented by
> other parties meanwhile. If I had gotten an outright reject from the
> radext group as whole I wouldn't have taken the step to ask for
> rechartering. But if you recall IETF69+70, there *was* support for
> the work. Yes, there has also been an outcry to ignore RadSec
> completely -- oh, wait, that was you alone... 

I'm afraid you are incorrect.  From your first appearance at radext I
have expressed the opinion that, while the radsec work was interesting,
it is not RADIUS & therefore does not belong in the radext WG. 
 
>> even a perversion, not RADIUS.
>
> We've had a discussion on that topic before on this list. That time,
> at the end you resorted to a strange analogy of ducks and snakes
> IIRC, not providing a reasonable argumentation. 

I assume that you are referring to the following exchange
(https://ops.ietf.org/lists/radiusext/2007/msg00603.html):

<QUOTE>
> Well, except that in order to place these things in a common category
it
> is necessary to ignore one of the defining characteristics of RADIUS:
> that it is only and intentionally defined as a connectionless
protocol.

>> The impact of connectionless vs. connection is not very significant
when
>> discussing the protocol's *security*, IMO.

So I gather that as far as you're concerned a network "protocol" solely
consists of the format of the innermost PDU?

> might like to believe so, RadSec is _not_ RADIUS,

>> Well, it's _almost_ RADIUS, especially if one takes into account the
>> mechanisms in RADIUS to detect duplication, retransmission etc, which
already
>> contains parts of the merits of TCP.

By that logic, a cobra is _almost_ a pigeon.

> & therefore far out of
> scope of not just the crypto-agility discussions but of this WG.
> RADIUSoDTLS, OTOH, doesn't alter the fundamental nature of RADIUS &
> therefore _is_ in scope.

>> I have understood that DTLS is considered in scope, while RadSec is
out of
>> scope (Reminder: I never claimed otherwise). Just keep in mind that
DTLS
>> itself requires even more characteristics of TCP, so when combining
the
>> RADIUS mechanisms that come on top of UDP + the transport mechanisms
in DTLS,
>> the end result is getting very close to TCP already. So the distance
between
>> in-scope and out-of-scope is a very thin line.

Only if snakes are almost birds...
</QUOTE>

I'm sorry that you didn't understand that simile.  Perhaps you also
don't recall (or didn't understand) the message that elicited it
(https://ops.ietf.org/lists/radiusext/2007/msg00590.html):
<QUOTE>
> I agree that it is not relevant for crypto-agility discussions. As I
> see it, DTLS and RadSec fall under a common category in this respect:
> whole packet encryption, with encryption negotiation happening
> outside of RADIUS.  

Well, except that in order to place these things in a common category it
is necessary to ignore one of the defining characteristics of RADIUS:
that it is only and intentionally defined as a connectionless protocol.
This is not an accidental result of the transport choice as you seem to
imply below ("{some transport}+{the equivalent of TLS for that
transport}"), but a fundamental quality of RADIUS itself.  Much as you
might like to believe so, RadSec is _not_ RADIUS, & therefore far out of
scope of not just the crypto-agility discussions but of this WG.
RADIUSoDTLS, OTOH, doesn't alter the fundamental nature of RADIUS &
therefore _is_ in scope.
</QUOTE>

Since the "strange analogy" you deride was an attempt to explain the
above statement (what part of it is "unreasonable", exactly?)  I won't
risk further derision by attempting to explain it again.

> *Thank you*! It is very nice to read that you would support a WG for
> that work, which appears to imply that you see the concept as worthy
> for exploration and eventual standardisation. 

See above; actually, I'm not really sure about standardization, but
surely it could be documented.  

> Actually, I had been
> thinking about this way forward as well. The outcome was that
> creating a whole new working group for this one thing probably isn't
> justified. After all, it is not likely to create follow-up work, it's
> pretty much a standalone thing to add to RADIUS. So, if a working
> group isn't justified due to lack of amount of work, but the work is
> still somewhat important, where would the place to go be? My
> conclusion was that radext is the place to go. 

As the chairs have pointed out, the WG has almost completed its work &
it seems like the only thing being considered to continue radext is
radsec.  So if there is not enough work to justify a WG (something I
doubt very much) then it doesn't seem to justify the continuation of
radext, either.  Just publish an Informational RFC & be done with it.
BTW, what do the members of the "worldwide-operating roaming consortium"
think about giving up change control to the IETF (or do they think that
we will simply rubberstamp this work of sheer genius)?

> And I still think that
> reasoning is justified, Bernard's reply in the thread looks like it
> is at least deemed worth a consideration.         
>
> Greetings,
>
> Stefan Winter

---

From: Stefan Winter <[email-masked]>
Date: Thu, 14 Feb 2008 09:39:44 +0100

Hi,

> we will simply rubberstamp this work of sheer genius)?

It is clear to everyone that change control goes to the IETF. It is not at all 
a problem. We are in the lucky position that we don't have any commercial 
interest or pressure, but do this work for (excuse the pathos) "the greater 
good of humanity" - at least the subset of humanity we are concerned with: 
educational users and researchers. As such, we have no interest in 
locked-down Intellectual Property. In fact, being a (former) GPL programmer, 
I have an open source guy's typical aversion against closed, IPO'ed, NDA'ed 
stuff.

Regarding the "genius" part: I'm aware that there are several parts in the 
current draft that need to be looked over carefully and modified, as the 
discussion of the last few days has already shown. I'm happy that the 
discussion is happening, that improvements are pointed out etc. Actually, the 
discussion almost looks like WG work on it has already begun :-)

Greetings,

Stefan

-- 
Stefan WINTER

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 14 Feb 2008 15:24:45 -0800

> *not* a problem.
> The MIB counters for
> to be closed, too.
> The existing RFC's have to be audited, and a new

This sounds like an outline of the issues that need to be handled in the 
RADSEC specification.
Regardless of whether the RADEXT WG ends up adding the RADSEC work to the 
Charter, it
would be useful to include this material in the document.

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 15 Feb 2008 16:18:46 +0700

Klaas Wierenga <mailto:[email-masked]> scribbled on Thursday,
February 14, 2008 3:32 PM:

...

> 
> Nobody expects the IETF to just rubberstamp this work, on the
> contrary, this is an effort to sollicit comments and make this better
> than it would be if it was just thought up by a few individuals. 

I'm extremely pleased to hear that!  For example, I'm inclined to think
that TLSoSCTP might be a choice far less destructive of RADIUS semantics
that TLSoTCP...

> We
> have built an infrastructure on what was available and ran into
> operational problems with it, I  believe it is perfectly legitimate
> to try to address these problems.     

No doubt.  The only question is where & how.  I strongly believe that
the radext WG is not the right place,\. The IETF standardization process
may be the "how"; the normal way this is discovered is through the BOF
process.

> Klaas Wierenga
> (creator of eduroam)

---

From: Stefan Winter <[email-masked]>
Date: Fri, 15 Feb 2008 15:41:40 +0100

Hi,

> that TLSoSCTP might be a choice far less destructive of RADIUS semantics

SCTP was also considered, and in fact the Radiator implementation also offers 
SCTP as an option.
The choice for TCP was a rather pragmatic one. SCTP is available on less 
platforms and the implementations appeared to be a bit more flaky - e.g. the 
SCTP implementation in Linux has had several DoS advisories, and I for one 
wouldn't want to rely on it yet.
Regarding platforms: that LANCOM Access Point implementation wouldn't exist if 
SCTP would have been the transport - to my best knowledge, that feature is 
not even anywhere near their radar.
So, the choice was to concentrate on something that works today and almost 
everywhere.

If I take a look at how Diameter approached this: clients TCP and optional 
SCTP, servers both required: if we were to follow that, we'd still have to 
deal with all the complexities of TCP and add on top of that SCTP. And I'm 
not sure that trying SCTP first and falling back to TCP if that doesn't work 
really fits to the KISS mantra of the IETF.

Greetings,

Stefan Winter

-- 
Stefan WINTER

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 21 Feb 2008 08:48:07 -0800

I'm not in favor of taking RADSEC on as a working group item without a
better understanding of the goals.  There is more to RADSEC then just
TCP transport and algorithmic agility.  I think it would be appropriate
to have a BOF to understand that scope of what RADSEC is trying to
achieve. 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Thursday, February 14, 2008 3:25 PM
> To: Alan DeKok
> Cc: Stefan Winter; [email-masked]
> Subject: Re: request to recharter
> 
> >  Also, some issues relating to RADIUS PDU's over a stream transport 
> > may be discussed.  e.g. receiving half a RADIUS packet and 
> then a FIN 
> > is
> > *not* a problem.
> >
> > The MIB counters for
> > receiving a PDU with malformed attributes means that the TCP 
> > connection SHOULD be closed.
> >
> >  Many RADIUS practices related to handling error cases 
> require a PDU 
> > to be "silently discarded".  This won't work for TCP.  The 
> connection 
> > has to be closed, too.
> >
> > The existing RFC's have to be audited, and a new document 
> issued which 
> > explains the correct behavior.
> 
> This sounds like an outline of the issues that need to be 
> handled in the RADSEC specification.
> Regardless of whether the RADEXT WG ends up adding the RADSEC 
> work to the Charter, it would be useful to include this 
> material in the document. 
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.

---

From: Stefan Winter <[email-masked]>
Date: Fri, 29 Feb 2008 10:26:02 +0100

Hi,

> to have a BOF to understand that scope of what RADSEC is trying to

I have just sent a note to ietf, ops-area and int-area that I'd like to 
solicit opinions on the topic of roaming in general during the upcoming 
meeting. RadSec is one topic of course, but it's about more.
This is not a BoF, since a BoF is a well-defined process, but I hope it will 
generate some insight aynway.

As for the scope of RadSec: its primary purpose is really just that: make 
RADIUS more robust and secure. This happens to make it also more flexible, 
i.e. no shared secrets and IP bindings, right, so it might achieve more than 
that.

Still, it is a topic very closely related to RADIUS (Glen might disagree, I 
know) and so I for one am very confident that radext is the place to go for 
this draft.

Greetings,

Stefan Winter
-- 
Stefan WINTER