Here are the draft minutes from the Virtual Interim.
Comments/edits/additions welcome.
RADEXT WG Virtual Interim Meeting
June 10, 2009
Minutes
RADIUS Crypto-agility Requirements
Open Issues include 274, 275, 303.
Of the open issues, 303 (from Pasi Eronen's review) overlaps with some of the
comments in the other issues.
David Nelson: Addressing Pasi's comments will probably require a complete rewrite
of the document, but I haven't had the time...
Bernard Aboba: Pasi had comments in the following areas:
Hop-by-hop/end-to-end: Explaining why solutions only need to focus on "hop-by-hop".
Forward secrecy: Whether this is necessary or not. Issue is transmission of keys that
could be used for a long time.
Credentials: what kinds of credentials solutions are expected to support.
Replay protection: Access-Request messages currently aren't replay protected. Do we
need to do better?
Negotiation: Does this require negotiation in the protocol, or between admins?
Automated Key management: If you don't have automated key management, there can be
issues; more explanation is needed.
Compromise of legacy shared secret: The requirement in the document seems difficult
to meet, since if MD5 is cracked, then how do you avoid
bidding down attacks?
Backward compatibility: It is hard *not* to meet this requirement. Is the goal to
require some kind of negotiation?
Operational model: What does this mean?
RADIUS service: What is a RADIUS service?
Hannes: Do we really need the requirements document anymore? Isn't Glen's document obsolete?
Glen Zorn: I am no longer pursuing it, though Cisco might want to publish a document
describing what they have implemented.
David Nelson: So do we now just have a single proposed solution (TLS/DTLS)? The
other approach can just go forward as an Informational RFC, via the
RFC Editor.
Glen Zorn: To be clear -- I still think that the approach has value. Diameter adopted
TLS, but it isn't deployed. Many implementations actually use no security
at all. So do we really think that RADSEC will solve this problem? It seems
unlikely.
David Nelson: RADSEC is only for use by proxies, right?
Alan DeKok: Yes.
David Nelson: So how can RADSEC solve the problem of protecting communication between
a NAS and a proxy?
Bernard Aboba: It can't. But presumably DTLS would be used for that situation?
Alan DeKok: I am revising the DTLS draft.
Glen Zorn: The problem is bigger than that... what credentials will you use? Is it
possible to require certificates on every NAS/proxy?
Bernard: Judging from the situation with Diameter, the answer to that is "No."
Glen Zorn: The solution provided in my draft is something that has actually been
implemented... and that operators could actually deploy. Isn't that
important?
Bernard: It would seem that Pasi's questions apply to all approaches... and that they
need to be answered in order for us to understand when we're done. For
example, the "bidding down" problem can occur with TLS/DTLS as well.
Alan DeKok: With DTLS it is possible for a RADIUS server to detect whether an incoming
packet is DTLS or not, and switch automatically.
Bernard: But how does the NAS know to attempt DTLS? Does it use DNS discovery? And
what if DNSSEC isn't in use? Couldn't that be spoofed?
Alan DeKok: You can have policy to require TLS/DTLS.
Bernard: That works once you know that you have transitioned the NASes... but what
about when you're operating a mixed network?
Alan DeKok: The RADIUS server can keep a list of what NASes have ever attempted TLS/DTLS.
Bernard: So once the NAS tried DTLS/TLS it is assumed that it will always use that.
Alan DeKok: Yes.
Glen Zorn: Also, my draft provides a mechanism for encrypting RADIUS attributes. That
has value beyond what TLS can provide.
Bernard: In the "end-to-end" case, which is what Pasi was asking about. So to answer
Hannes' question, the requirements document would seem to have value,
since the issues Pasi raised come up regardless of the approach taken.
David Nelson: So what are the next steps? Discussion on the list?
Bernard: Yes.
RADIUS Extended Attributes
Open issues: 251, 290, 298.
These issues largely concern Diameter compatibility and IANA allocation policies.
Bernard: With respect to IANA allocation policies, allocation of Extended Attributes
isn't just for when we run out of standard attributes. Couldn't someone
request allocation from the extended attributes space before then?
Glen Zorn: Yes.
The Diameter compatibility issues arise because the Extended Attributes document
does not use the VSA format recommended in RFC 2865 (one octet type field). As
a result, the procedures described in RFC 3588 cannot be applied for translating
RADIUS Extended Attributes to Diameter.
David Mitton: I had a draft long ago that covered this....
Bernard: Yes. Has their been progress on introducing that within DIME?
Glen Zorn: No.
Hannes: Does anyone really run mixed Diameter/RADIUS networks anyway?
From what I have seen, they do not.
Glen Zorn: I have not seen it either.
David Nelson: So why do we require Diameter Compatibility boilerplate in all
of our documents? Is this really necessary?
Bernard: If nobody is doing translation, maybe it is not necessary. In any
case, Diameter will have its own equivalent of the RADIUS Extended
Attributes features (e.g. grouping), so you'd probably want to
allocate separate Diameter AVPs anyway.
David Nelson: So maybe this is a non-problem? Should we check with DIME?
Bernard: Probably.
|