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

[Thomas Muldowney]

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