Subject: CGA signatures and related-protocol attacks

From: "Tuomas Aura" <[email-masked]>
Date: Wed, 30 Jul 2003 09:40:36 -0700

While the CGA specification for SEND only talks about
the uses of CGA in SEND, there are other protocols that
will use the same CGA keys and addresses. This raises 
the question of related-protocol attacks. In such attacks, 
CGA-signed messages from one protocol could be replayed
in another protocol. The reason why the problem arises in 
CGA and not in most other security systems is that 
CGA-based protocols use a different key for each different
purpose. Most other systems use a different key for each 
different purpose. 

This means that messages from another protocol (perhaps 
designed by someone with no knowledge of or interest in 
SEND) can potentially break SEND. Thus, we need to address 
this problem even if we are only interested in the security 
of SEND and not in the other protocols.

Please note that it is dangerous to assume that the
structures of the signed messages in the related protocols
are different. In the end, the signed messages are just 
sequences of bits and it is possible, for example, to 
replay a random value as an integer or visa versa.

The standard way to prevent the related-protocol attacks
is to type-tag the signed messages with a protocol/message 
identifier. That is, the (pseudo)messages that are signed 
in SEND could begin with unique type tags. This tag could
either be a short (e.g. 32-bit) IANA-allocated value or 
a fixed 128-bit number chosen randomly by us at the protocol 
design time. The IANA-allocated type tags are more in line 
with the way Internet protocols are typically designed. 
The random type tag provides better protection against 
designers of other protocols who do not know about the 
need for the type tag. It is extremely unlikely that any 
other protocol would ever sign a message that matches
the 128 random bits. 

There is also the editorial question of whether the type
tag should be part of the CGA or SEND document. If it is
an IANA-allocated short value, then it seems the CGA documents 
should define a new IANA registry and the SEND document 
should define an entry in the registry. If the type tag 
is a 128-bit randomly chosen value, then it would be 
sufficient to define this value in the SEND document.

Proposed solution: 

Define a randomly chosen 128-bit tag for each SEND message
type (NS, NA, RS, RA, Redirect). Define these tag values in 
the SEND document. One of these 5 tags should be prepended 
to every (pseudo)message that is to be to be signed in SEND,
regardless of whether the authorization is based on CGA or 
certificates. If we want, we can create an IANA registry for
these values as long as they are at least 128 bits long and 
chosen randomly.

Note that it is never necessary to transfer the type tags
over the wire. They are simply part of the pseudo-message
that is signed.

Opinions?

Tuomas

--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------

---

From: Michael Richardson <[email-masked]>
Date: Wed, 30 Jul 2003 13:41:42 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Tuomas" == Tuomas Aura <[email-masked]> writes:
    Tuomas> While the CGA specification for SEND only talks about
    Tuomas> the uses of CGA in SEND, there are other protocols that
    Tuomas> will use the same CGA keys and addresses. This raises 
    Tuomas> the question of related-protocol attacks. In such attacks, 
    Tuomas> CGA-signed messages from one protocol could be replayed
    Tuomas> in another protocol. The reason why the problem arises in 
    Tuomas> CGA and not in most other security systems is that 
    Tuomas> CGA-based protocols use a different key for each different
    Tuomas> purpose. Most other systems use a different key for each 
    Tuomas> different purpose. 

  I think that there is a "not" missing somewhere?

    Tuomas> Define a randomly chosen 128-bit tag for each SEND message
    Tuomas> type (NS, NA, RS, RA, Redirect). Define these tag values in 
    Tuomas> the SEND document. One of these 5 tags should be prepended 
    Tuomas> to every (pseudo)message that is to be to be signed in SEND,
    Tuomas> regardless of whether the authorization is based on CGA or 
    Tuomas> certificates. If we want, we can create an IANA registry for
    Tuomas> these values as long as they are at least 128 bits long and 
    Tuomas> chosen randomly.

  Sure.  

    Tuomas> Note that it is never necessary to transfer the type tags
    Tuomas> over the wire. They are simply part of the pseudo-message
    Tuomas> that is signed.

    Tuomas> Opinions?

  There was a long debate in IPsec about possible similar way to exploit
EAP - i.e. a web server that you authenticated to via EAP/HTTPS might be
able to use your credentials to do IPsec. This was a real attack because
the inner-EAP was never bound to the outer protocol.

  I think that you are describing a similar (but not identical) type of
thing.

]      Out and about in Ottawa.    hmmm... beer.                |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy");  [
--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------