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

[Hannes Tschofenig <[e-mail]>]

Hi David,

there are really no crypto issues with RADIUS and Diameter.

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".

On top of that we don't have a incomplete toolbox; there is no e2e
security solution standardized for RADIUS/Diameter.

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.

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.
>>
>>
>> .
>>
>