Subject: [tram] STUN Origin Open Issue Resolution Proposal

From: Alan Johnston <[email-masked]>
Date: Sun, 17 Aug 2014 13:45:19 -0500

Based on the discussion on the two Open Issues (Integrity Protection and
Size of Attribute) discussed on this list, and the XMPP Origin issue
discussed on the XMPP list (thanks to Peter Saint-Andre for his text), here
is my proposed changes to the draft.

Let me know if you have concerns about this new text.  I plan to revise the
draft in the next few days with these changes.

- Alan -

Proposed changes to draft-ietf-tram-stun-origin-00:

OLD:

For a Jabber client [RFC6120] using STUN and TURN, the ORIGIN attribute is
the Jabber ID (JID) [RFC6122] of the Jabber Server that the client is using.

NEW:

   For an XMPP client [RFC6120] using STUN and TURN, the ORIGIN
   attribute is an XMPP URI [RFC5122] representing the domainpart
   of the client's Jabber ID (JID) [RFC6122]; for example, if the
   client's JID is "[email-masked]/balcony" then the ORIGIN
   attribute would be "xmpp:im.example.com".

Add to TURN Usage section:

   Including the ORIGIN attribute in the Send method is NOT RECOMMENDED.

OLD:

   It MUST contain a
   UTF-8 [RFC3629] encoded sequence of characters less than 268 bytes.
   The value of 268 is chosen to be larger than the maximum 253
   character domain name plus 8 characters for the URI scheme plus 5
   characters for the port number.  Senders MAY include multiple ORIGIN
   attributes in a request, and receivers MUST support parsing and
   receiving multiple ORIGIN attributes.

NEW:

It MUST contain a UTF-8 [RFC3629] encoded sequence of characters.  Senders
MAY include multiple ORIGIN attributes in a request, and receivers MUST
support parsing and receiving multiple ORIGIN attributes.  The size and
number of ORIGINs included in a STUN message can have a major impact on the
size of a STUN packet, and could potentially cause UDP fragmentation.  HTTP
origins are less than 267 characters (the maximum 253 character domain name
plus 8 characters for the URI scheme plus 5 characters for the port
number).  It is NOT RECOMMENDED that an ORIGIN attribute be included if the
total size (including type, length, and padding) is larger than 272 octets.
 Multiple ORIGIN attributes SHOULD NOT be included if the total size of
these attributes exceeds 272 octets.

OLD:

The STUN MESSAGE-INTEGRITY attribute can provide integrity protection for
all attributes present in a STUN request.  However, MESSAGE-INTEGRITY is
not present in the initial STUN message sent, so the initial ORIGIN
attribute will not have integrity protection and hence could be modified or
removed from a STUN request without the server knowing.  Subsequent STUN
requests containing the MESSAGE-INTEGRITY attribute will provide integrity
protection for the contents of the ORIGIN attribute.  The strength of this
protection is a function of the secret used to generate the
MESSAGE-INTEGRITY value.

NEW:

While the STUN MESSAGE-INTEGRITY attribute can provide integrity protection
for all attributes present in a STUN request, MESSAGE-INTEGRITY is not
present in the initial STUN message sent. As a result, an ORIGIN attribute
could be modified or removed from a STUN request without the server
knowing. DTLS or TLS transport SHOULD be used when integrity protection for
the ORIGIN attribute is important.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 18 Aug 2014 06:29:53 +0000

Updated text looks good. Comment on UDP fragmentation, if this problem is restricting various TURN drafts then why not consider enhancing TURN to handle fragmentation (similar to the way it’s done in EAP-TLS, DTLS handshake etc.).

-Tiru

From: tram [mailto:[email-masked]] On Behalf Of Alan Johnston
Sent: Monday, August 18, 2014 12:15 AM
To: [email-masked]
Subject: [tram] STUN Origin Open Issue Resolution Proposal

Based on the discussion on the two Open Issues (Integrity Protection and Size of Attribute) discussed on this list, and the XMPP Origin issue discussed on the XMPP list (thanks to Peter Saint-Andre for his text), here is my proposed changes to the draft.

Let me know if you have concerns about this new text.  I plan to revise the draft in the next few days with these changes.

- Alan -

OLD:

For a Jabber client [RFC6120] using STUN and TURN, the ORIGIN attribute is the Jabber ID (JID) [RFC6122] of the Jabber Server that the client is using.

NEW:

   For an XMPP client [RFC6120] using STUN and TURN, the ORIGIN
   attribute is an XMPP URI [RFC5122] representing the domainpart
   of the client's Jabber ID (JID) [RFC6122]; for example, if the
   client's JID is "[email-masked]/balcony<http://[email-masked]/balcony>" then the ORIGIN
   attribute would be "xmpp:im.example.com<http://im.example.com/>".

OLD:

   It MUST contain a

NEW:

It MUST contain a UTF-8 [RFC3629] encoded sequence of characters.  Senders MAY include multiple ORIGIN attributes in a request, and receivers MUST support parsing and receiving multiple ORIGIN attributes.  The size and number of ORIGINs included in a STUN message can have a major impact on the size of a STUN packet, and could potentially cause UDP fragmentation.  HTTP origins are less than 267 characters (the maximum 253 character domain name plus 8 characters for the URI scheme plus 5 characters for the port number).  It is NOT RECOMMENDED that an ORIGIN attribute be included if the total size (including type, length, and padding) is larger than 272 octets.  Multiple ORIGIN attributes SHOULD NOT be included if the total size of these attributes exceeds 272 octets.

OLD:

The STUN MESSAGE-INTEGRITY attribute can provide integrity protection for all attributes present in a STUN request.  However, MESSAGE-INTEGRITY is not present in the initial STUN message sent, so the initial ORIGIN attribute will not have integrity protection and hence could be modified or removed from a STUN request without the server knowing.  Subsequent STUN requests containing the MESSAGE-INTEGRITY attribute will provide integrity protection for the contents of the ORIGIN attribute.  The strength of this protection is a function of the secret used to generate the MESSAGE-INTEGRITY value.

NEW:

While the STUN MESSAGE-INTEGRITY attribute can provide integrity protection for all attributes present in a STUN request, MESSAGE-INTEGRITY is not present in the initial STUN message sent. As a result, an ORIGIN attribute could be modified or removed from a STUN request without the server knowing. DTLS or TLS transport SHOULD be used when integrity protection for the ORIGIN attribute is important.