Stefan Winter <mailto:stefan.winter@restena.lu>
scribbled on Wednesday, February 13, 2008 9:45 PM:
>
Hi,
>
>> Yes, there has been a popular upswell of support for
abandoning our
>> 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.
>
> 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...
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.
>
>> No, no, NO! "radsec" is not
RADIUS, period. Not an extension, not
>> 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.
>
>> 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.
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