Subject: Draft minutes of the Virtual Interim Meeting

From: Bernard Aboba <[email-masked]>
Date: Sun, 28 Jun 2009 09:41:30 -0700

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.