Hello,
a few clarifications below.
> Not only is it out of scope of the charter, it directly violates a
> number of the restrictions placed on the crypto-agility submissions from
> the actual members of the WG. I, for one, have at least been aware of
> the RADSEC activities for a couple of years now but for some reason they
> have not deigned to inform the radext WG of them until now.
Just to make this clear: I am in no way affiliated with the guys who
originally created the RadSec implementation (OSC). I'm not part of "them".
I don't know why OSC didn't report on their implementation here earlier.
Probably because there were no interoperable other implementations, and so
taking it to a *standardisation* organisation wasn't deemed urgent. Just
speculating though.
OTOH, you mentioned in the session that you read their whitepaper when it was
new. You could have brought it to the attention of radiusext yourself, even
if only to rebut it.
> To 1) ignore our charter (not to mention the (at best) disingenuous '?'
> regarding it in the presentation) and
As David said already: the same presentation was held at the opsawg meeting,
and I received word there that it *may* be possible that radiusext might
interpret its charter more loosely in the future. That's why I added that
question mark after the opsawg discussion took place. I did not act
disingenuous in any way. And I think I even said this during the
presentation.
> 2) ignore the written requirements that every one else had to follow seems
> to me at the very least arrogant.
You mean the charter? I think I expressed myself quite clearly on audio during
the presentation that the proposal is not in the charter, submitted
independently and for information of interested RADIUS experts only. See also
my original post announcing the draft. I asked for presentation slots
sufficient time ahead of the meeting.
You mean formality-wise? I submitted -00 before the deadline.
If there are some other written requirements to follow, please enlighten me.
It was my first IETF meeting after all, I may have missed something.
> Note that I am _not_ 'hostile to the idea' -- I am, however,
> hostile toward arrogant academics proffering "new" schemes (that have
> been around for years in one form or another) in direct contradiction of
> the rules the rest of us (who actually participate in the WG, not just
> drop by with our works of genius ;-) must follow.
First, I am not an academic. I work at an ISP that caters universities and
schools, that's about it.
Second, I never said this was either new or genious. I hope I made clear that
this is a writeup to despcribe interoperability between existing
implementations. Both OSC and Stig Venaas got their due credit, and I also
*did* mention that RadSec has been around for some years now.
Third, I didn't just drop by. I kept reading radiusext for quite some time,
since RADIUS is of vital relevance when operating a global-scale RADIUS wlan
proxy environment, and knowing what's up is important. It's just that I
didn't have anything incredibly urgent or genious to say yet.
> Therefore, I must
> insist that the RADSEC proposal be treated as only a an informative
> presentation (in the nature of an informative liaison)
Which is precisely what I wanted it to be in the first place.
> and not accepted as a candidate for the crypto-agility solution.
While it wasn't the intention of the draft to intersect with crypto-agility
work items (the dynamic discovery part is the reason why we found the concept
sexy), the number of people that consider it as worth investigating according
to the straw poll provides some obvious evidence that it is at least worth
discussing.
To add a bit of constructivity to this mail, and leverage it above the
flame-war barrier, there is one aspect that RadSec or DTLS don't solve (and
I'm not sure either if keywrap can do): in some situations, it might be
useful to have end-to-end security between the first RADIUS server in a proxy
chain (the one that the NAS is directly attached to, let's call it A) and the
last one (the home server which verifies the credentials, lets call it C),
while all intermediates can not (lets call the set of those B). Our use case
for this is when A receives an Access-Accept, but needs more info about the
user ("How old is the user?") to put him either in a porn-filter VLAN or not,
and so asks C. AFAICT, none of the proposals can make sure that only A can
ask this question - a server in B can always pretend to have its upstream
connection directly connected as a NAS, not another proxy server, assuming
that the servers in B also have (other) NASes directly connected and so in
some situations *could* legitimately ask this question (i.e. in keywrap
terms: they also have keying material to legitimately query C).
A clean solution to this problem seems tough.
BTW, solving this particular age verification problem could technically also
be solved without such an end-to-end assertion by pushing the info from C to
A unconditionally in the Access-Accept, not caring about A's backchannel or
the presence of B in the middle. Unfortunately, this is personal data which
can easily be tied to a real-life person, and so probably unconditionally
advertising it violates privacy laws in many countries.
In other news, the IPR discussion about Diameter and a possible affection of
the patents in question by RadSec will be investigated from the side of
eduroam operations; I will let the group know what came out of this
investigation when it's done. Given the swamp that international patent
regulations are, this may take some time though.
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: stefan.winter@restena.lu Tel.: +352 424409-1
http://www.restena.lu Fax: +352 422473
Attachment:
signature.asc
Description: This is a digitally signed message part.