[standards-jig] A late security comment on JEP-0020

David Waite mass at akuma.org
Wed May 15 18:27:33 UTC 2002


I might be off my rocker, but I thought this is exactly how SSL 
negotiates such things. You just don't say you will accept a wimpy 
scheme if it is too wimpy for your uses.

How can you protect cryptographic negotiation from man in the middle 
attacks, without requiring a CA or public-key infrastructure?

-David Waite

Thomas Muldowney wrote:

>This is part of what some of us were arguing about JEP-20 when it first
>came out.  While it does provide a clean syntax for many applications,
>it is not necessarily suited for more rigid systems like crypto.  I
>think it sort of stalled out at that point, but from what I could gather
>most everyone liked the general syntax.
>
>--temas
>
>
>On Wed, 2002-05-15 at 12:27, Paul Lloyd wrote:
>  
>
>>Hi,
>>
>>I'd like to make on comment on the negotiation feature presented in JEP-0020.
>>
>>The examples are interesting because they present the negotiation of
>>various security related algorithms/properties. Unfortunately, the
>>protocol is at odds with current accepted practices for the
>>negotiation of such items because the values are not protected
>>in any way, cryptographically or otherwise; one result of this lack
>>of protection is that an active attacker can launch a downgrade attack.
>>
>>For example, client A just wants some crypto:
>>
>>   <iq type="get" id="1" from="A at tld" to="B at tld">
>>      <query xmlns="jabber:iq:negotiate">
>>         <feature type="jabber:crypto:cipher">
>>            <option>beefy algorithm</option>
>>            <option>wimpy algorithm</option>
>>         </feature>
>>      </query>
>>   </iq>
>>
>>Client B wants strong crypto and sends:
>>
>>   <iq type="result" id="1" from="B at tld" to="A at tld">
>>      <query xmlns="jabber:iq:negotiate">
>>         <feature type="jabber:crypto:cipher">
>>            <option>beefy algorithm</option>
>>         </feature>
>>      </query>
>>   </iq>
>>
>>But an active attacker modifies the response:
>>
>>   <iq type="result" id="1" from="B at tld" to="A at tld">
>>      <query xmlns="jabber:iq:negotiate">
>>         <feature type="jabber:crypto:cipher">
>>            <option>wimpy algorithm</option>
>>         </feature>
>>      </query>
>>   </iq>
>>
>>An even more striking example would be for the attacker to simply
>>forge an error response indicating the crypto feature isn't supported.
>>Client A may still chose to proceed and expose data that would otherwise
>>have been properly protected.
>>
>>Obviously, we can imagine further checks downstream that can be used
>>to detect such attacks; the point is rather that the negotiation of such
>>important items should be inherently protected from the start.
>>
>>Comments encouraged,
>>
>>
>>  |\/\/\/|        "I DIDN'T DO IT, MAN!"
>>  |      |
>>  |      |        Paul Lloyd
>>  | (o)(o)        Infrastructure Strategic Engineering
>>  C      _)       Strategy and Architecture Leadership Team
>>   | ,___|        voice:          650-236-3704
>>   |   /          FAX:            650-236-3632
>>  /____\          MSN Messenger:  paul_lloyd at hp.com
>> /      \         plloyd at corp.hp.com
>>_______________________________________________
>>Standards-JIG mailing list
>>Standards-JIG at jabber.org
>>http://mailman.jabber.org/listinfo/standards-jig
>>    
>>
>
>
>_______________________________________________
>Standards-JIG mailing list
>Standards-JIG at jabber.org
>http://mailman.jabber.org/listinfo/standards-jig
>  
>






More information about the Standards mailing list