Subject: [Cfrg] AAA versus A+AA was -> Re: how can CFRG improve cryptography in the Internet?

From: Paul Lambert <[email-masked]>
Date: Wed, 12 Feb 2014 17:43:18 -0800

Thinking more about Hannes’ astute observations, if our RFC based
mechanisms are being assembled incorrectly - is the implementors at fault
or the architecture?

Over the last year I’ve spent some time working with others to fix
"WPA2-Enterprise”.  It had a convergence of issues that included:
 - The use of ‘secure’ RADIUS and Diameter servers for WPS2-Enterprise
   - an odd 802.1X L2 security model (not so relevant for this thread, but
including)
   - the use of many different EAP methods, some better than others
 - MSCAPv2 as a common EAP method
        (which was fielded even though it could be broken with great
difficulty)
    - imporvements in Moore’s law and cloud computing that made it
breakable by anyone
      - and increased awareness of the risks of Nation level threats
    - a lack of too much concern about MSCHAPv2 since it was within a TLS
tunnel
    - TLS server certificates that are not being checked by WPA2
supplicants
       (they are starting to be checked, one of the bandaids created)

So … “Enterprise Grade” authentication with RADIUS/Diameter is readily
attacked in many existing deployments.

I continue to wonder why we continue to build new systems on symmetric key
based authentication techniques.  Symmetric keys are the main reason we
have a triple-A (AAA -> authentication, authorization and accounting)
versus splitting up the functions and enabling a A+AA architecture where
the authentication could be performed directly by the directly
participating parties.

We should be pursuing protocols and architectures that enable functions to
be securely distributed.  RADIUS and Diameter can be used client side
certificates and with TLS and IPsec or TLS protection on each path.
Issuing real certs for clients is cumbersome and expensive. Raw keys and
self signed certs are a path … but lacks any significant adoption …
perhaps it is too may small steps away from the common usage model.

Paul

>
>
>On 2/12/14, 9:35 AM, "Hannes Tschofenig" <[email-masked]>
>wrote:
>
>>Hi David,
>>
>>there are really no crypto issues with RADIUS and Diameter.
>
>??  Perhaps because they have no crypto.
>The RADIUS/Diameter AAA architecture is flawed by the inclusion
>of so many options that insecure deployments are common.
>
>>
>>The issue is that vendors don't implement the security protocols
>>mandated in our RFCs and, if they are implemented, operators don't turn
>>them on because they rely on "physical security".
>
>Yes.  Our guidelines here are poor.  TLS or IPsec are specified
>and even when used typically leave gaps due to ³physical security"
>
>>
>>On top of that we don't have a incomplete toolbox; there is no e2e
>>security solution standardized for RADIUS/Diameter.
>
>Would this be a work item?
>
>>
>>The consequence is that highly sensitive transaction data flies around
>>in the clear or, if it is protected, then all intermediaries see it.
>>
>>I organized a few Diameter interops several years ago and the biggest
>>problem we had was with security. Very few implementations implemented
>>TLS and it took us a day at each event to configure the certificates
>>since every implementation had their own management interface which
>>nobody knew how to use. Once we got past that point we found out that
>>none of the implementations were actually checking the certificates
>>anyway.
>Yes!  A fundamental problem - X.509 :-)
>
>Al
>
>
>>
>>A couple of years have passed since that time and I really hope that the
>>situation is better now. At least there is FreeDiameter...
>>
>>Ciao
>>Hannes
>>
>>On 02/11/2014 04:16 PM, David McGrew wrote:
>>> Hi Stephen,
>>> 
>>> On 02/10/2014 03:59 PM, Stephen Farrell wrote:
>>>> I think adding energy and appropriate tasking to CFRG is a fine
>>>> idea, but this bit is a bit of a potential rathole...
>>>>
>>>> On 02/10/2014 07:18 PM, David McGrew wrote:
>>>>> Surely we don't need new crypto mechanisms to solve the problems with
>>>>> RADIUS, but analyzing and documenting security issues and helping to
>>>>> socialize them with the IETF and the user base are all in charter and
>>>>> are worth doing.
>>>> I'm not clear on this. I don't think there are non-obvious
>>>> crypto issues with RADIUS or Diameter that CFRG can tackle
>>>> to be honest. Or maybe I'm not missing something?
>>>>
>>>> I don't think CFRG should be collectively "documenting security
>>>> issues" generally, if those that are not cryptographic. Reason
>>>> being that that'd likely generate more heat than light and would
>>>> overlap with secdir and IETF WGs too much probably.
>>> 
>>> I was being too vague, sorry.  By "documenting security issues" I had
>>>in
>>> mind those cases in which some sort of cryptanalysis needs to be
>>>brought
>>> to bear in order to show that, yes, there is an actual attack that can
>>> be performed.   Sometimes some applied cryptanalysis needs to be done
>>>to
>>> make the point that some existing algorithm or parameter choice is no
>>> longer appropriate (or perhaps was never a good idea).    The
>>> standards-oriented people in CFRG could probably identify some
>>> low-hanging fruit that the cryptanalysis-oriented people would enjoy
>>> breaking.
>>> 
>>> Definitely we need to avoid the overlap that you mention.
>>> 
>>> David
>>> 
>>>>
>>>> I could maybe see re-chartering to include theorem-prover style
>>>> analyses or results in CFRG's charter, but I interpret the above
>>>> differently.
>>>>
>>>> If some CFRG folk are interested in e.g. RADIUS security,
>>>> then they are just as free as anyone to send mail to the
>>>> DIME list.
>>>>
>>>> Cheers,
>>>> S.
>>>>
>>>>
>>>> .
>>>>
>>> 
>>
>
>_______________________________________________
>Cfrg mailing list
>[email-masked]
>http://www.irtf.org/mailman/listinfo/cfrg

---

From: Paul Lambert <[email-masked]>
Date: Thu, 13 Feb 2014 09:25:44 -0800

On 2/12/14, 9:36 PM, "Peter Gutmann" <[email-masked]> wrote:

>Paul Lambert <[email-masked]> writes:
>
>>have 
>>a triple-A (AAA -> authentication, authorization and accounting) versus
>>splitting up the functions and enabling a A+AA architecture where the
>>authentication could be performed directly by the directly participating
>>parties.
>
>The reason why it's a bad idea to do that with public-key is that, at
>least in 
>the form of PKI, you start off doing the first A, and then you redo the
>first 
>A, and then you make more changes to the first A, and then you release
>first-A 
>version 3, and then you do some more of the first A, and 25-30 years
>later 
>you're still redoing the first A without ever getting around to the other
>two. 
>Symmetric-key RADIUS et al at least got around to doing all three right
>from 
>the start.

Yes Š good point, RADIUS could be relatively easily installed and then
worked well enough.

So the root of all security problems in the Internet is X.509  :-)

We have architected security based on a subtly flawed overly complex
authentication architecture.

Paul

>Peter.