Subject: [stir] Problem with STIR signing of fingerprints?

From: Jonathan Lennox <[email-masked]>
Date: Thu, 7 Apr 2016 12:26:09 +0000

An issue occurred to me when pondering the STIR signing of fingerprints.

It seems like it’s perfectly reasonable for a B2BUA to strip an m= block from an offer, in case it doesn’t want to allow it to pass (e.g., removing m=video).  And I think this shouldn’t break STIR.

However, since the two m= blocks can have different fingerprints, this would mean that the passport object computed by the verifier wouldn’t have all the fingerprints included in the passport object created by the offerer, so it wouldn’t match.

This occurred to me because I was talking to Martin Thomson — he mentioned that his rule for the WebRTC identity assertions (draft-ietf-rtcweb-security-arch section 5.6) just required that the fingerprints in the received offer be a *subset* of the fingerprints in the identity, for much the same reason.

Presumably, the “canon” request procedure can solve this, but the verifier still then needs to confirm that the fingerprints in the canon are indeed a superset of the fingerprints in the offer.  Supporting this means that STIR’s fingerprint list needs to be easily parseable, not just hashable.  (I suggest copying the same JSON format as IdP uses.)

Incidentally, this problem occurred to me in the context of thinking about an attack on STIR where a B2BUA *moves* fingerprints between m= blocks, e.g. because it has a collision or a stolen private key for one of them, so it moves all the other fingerprints to an m= block it knows the receiver will reject.  Stolen private keys can probably never be solved, but I think the best way to prevent this attack otherwise is just to have 4572bis say that you never use a fingerprint with a weak hash, period.  (I’ll send a note to mmusic to this effect.)

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 7 Apr 2016 12:04:16 -0400

> This occurred to me because I was talking to Martin Thomson — he mentioned that his rule for the WebRTC identity assertions (draft-ietf-rtcweb-security-arch section 5.6) just required that the fing…

Wouldn't this open things up for a bid-down attack on fingerprint 
strength? (This couldn't take it below the weakest that the receiver 
will accept, but still an attack.)

And if this is to be supported, what else might "reasonably" be done? 
What about reordering m-lines?

	Thanks,
	Paul

> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir
>