Re: [Cfrg] how can CFRG improve cryptography in the Internet?

[Paul Lambert <[e-mail]>]

On 2/12/14, 9:35 AM, "Hannes Tschofenig" <[e-mail]> 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.
>>>
>>>
>>> .
>>>
>> 
>