Subject: [midcom] STUN Message validation question

From: "Panayiotis A. Thermos" <[email-masked]>
Date: Mon, 29 Jul 2002 17:31:45 -0400

The STUN proposal states that a STUN client can
validate  server responses by using the server's
certificate. Specificaly page 15, section 8.3,towards
the end of the second paragraph it states

"... If the certificate used for the signature is a
site certificate, the client SHOULD validate that
the domain it used to perform the STUN query is a
sub-domain of the domain in the site certificate.
In other words, if the client queries stun.example.com,
the client SHOULD validate that the signature was
certified as coming from example.com..."

I'm confused how the client can verify the server's
information during the discovery phase when it
sends a CHANGE-IP and CHANGE-PORT message and it
receives responses from another STUN server.

Please correct me if my following assumptions are not
correct.

Based on the current verbiage of the proposal the STUN
client will receive a response from another STUN server
and continue to follow it's discovery process.

If the client decides to verify the information used by the
second server there are two cases"

     a) the STUN client will use the initial COOKIE  that
        was received from the initial STUN request with
        the first server.

     b) the second server includes a COOKIE in it's response
        so the client will use this COOKIE to authenticate
         the STUN message.

In case (a) the client will be using the wrong COOKIE and thus
the second server will not sign the response.

In case (b) it means that the client will have to send another
STUN message (based on the STUN proposal) to the second
server to verify the authenticity of the response from the
second server. And in order for the client to verify the response
it will have to compare the attributes from the first response
and the second response from the second server and I quote from
the STUN proposal,

"....If the other attributes in the response match the first response,
     and the signature is valid, the client can trust that the
     information has not been tampered with, and is authentic."

But the attributes will not be the same since the initial request
asked for "CHANGE-IP" and "CHANGE-PORT". So the client will
send the same request with "CHANGE-IP" and "CHANGE-PORT" to the
second server (in order to verify it) and the second server will
see "CHANGE-IP" and "CHANGE-PORT" and send it to another server.
This will cause a domino effect while the client is trying to verify
if what it received ws correct and there is a posibility of falling
in to an infinite loop.

One idea would be to have the first server tell the second server
to automaticaly sign the response to the client without having
the client initiate a new COOKIE exchange with the second server.

Peter Thermos

_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: "Cullen Jennings" <[email-masked]>
Date: Tue, 30 Jul 2002 11:25:00 -0700

Lets make sure we are both talking about the same draft. The latest draft
is:

http://search.ietf.org/internet-drafts/draft-ietf-midcom-stun-01.txt

This substantially changes the security stuff from the previous draft.

In the new one, the certificate check only has to do with the TLS connection
that is used to get the OTP.

Cullen

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Panayiotis A. Thermos
> Sent: Monday, July 29, 2002 2:32 PM
> To: [email-masked]
> Subject: [midcom] STUN Message validation question
>
>