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

[David McGrew <[e-mail]>]

Hi Hannes,

On 02/12/2014 12:35 PM, Hannes Tschofenig wrote:
> Hi David,
>
> there are really no crypto issues with RADIUS and Diameter.

certainly that's true if RFC 6614 is used (TLS for RADIUS).   There are 
issues with the crypto defined in the original RFC 2865 RADIUS, on the 
other hand.  (Encryption is done using MD5 as a keystream generator, 
with a secret that may be vulnerable to a dictionary attack, with 
incomplete authentication.)

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

Agreed.   We don't need a new crypto design to solve these problems.   
Some applied cryptanalysis on the currently-fielded systems might 
motivate people to upgrade to the newer, mandated mechanisms - that's 
what I was hoping when I mentioned RADIUS, anyway.

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

Not good :-(

David

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