Subject: [tram] Comments on draft-ietf-tram-stun-bis-01

From: Alan Johnston <[email-masked]>
Date: Tue, 17 Mar 2015 09:11:58 -0500

All,

Here are some comments on STUNbis.  Minor comments are listed below, but
the most important one is listed here:

Does the use of salted SHA256 for passwords match up with what is planned
for SIP?  See:

    https://tools.ietf.org/html/draft-yusef-sipcore-digest-scheme

Does H(A1) match up?  Also, I'm not aware if this draft is moving forward:

    https://tools.ietf.org/html/draft-veltri-sip-alt-auth

while the other one is under active discussion in SIPCORE and HTTPAUTH -
see https://tools.ietf.org/html/draft-ietf-httpauth-digest-update

I think it is important that STUNbis is aligned with the changes to digest
being worked on in SIP and HTTP.

- Alan -

Shouldn't STUNbis reference ICEbis instead of ICE?

I presume "obMatJos2" is just a random string used to indicate support for
STUNbis - it might be worth stating this in 9.2.3.

Section 11 Backwards Compatibility with RFC 3489: do we really need to
still be backwards compatible?  Is anyone still using RFC 3489 that hasn't
upgraded?  Do we leave ourselves open to any downgrade attacks by doing so?

Section 14 says only first of multiple attributes are processed. (“Any
attribute type MAY appear more than once in a STUN message. Unless
specified otherwise, the order of appearance is significant: only the first
occurrence needs to be processed by a receiver, and any duplicates MAY be
ignored by a receiver.”)  I guess this rules out multiple ORIGIN
attributes, which is fine since we had chosen that path forward.  However,
this means that no future STUN attributes can really appear more than
once.  Do we need to emphasize this more?

In Section 14.2 what are the x's in   |x x x x x x x x|?

The text in Section 15.3. Hash Agility Plan seems to be out of date now.

Section 17.5 says “The UDP port is not currently defined; however, it is
reserved for future use.”  What port?

The change log says that STUNbis normatively references
draft-ietf-tram-stun-origin, but I don't see it listed in the references.
Perhaps a mention of ORIGIN in section 9.2 or 9.2.3 would be good, too.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 19 Mar 2015 05:14:18 -0600

Thank for the comments.  See my answers inline.

>     https://tools.ietf.org/html/draft-veltri-sip-alt-auth

It is not, which is sad because I find it better than draft-yusef-sipcore-digest-scheme.  It also fits better with STUN where the hash algorithm (SHA-1 and now SHA256) has been split off the password hash algorithm (MD5) from the beginning.  draft-yusef-sipcore-digest-scheme does not even talk about the password algorithm, continuing the (I think) rather bad idea of linking the two together.

I put salted SHA256 as an example of the kind of password hash algorithm we could use, but I'll let the WG decide on what they prefer.

> Shouldn't STUNbis reference ICEbis instead of ICE?

It's an informational reference, so I have no problem in referencing ICEbis.  Will fix in -03.

> STUNbis - it might be worth stating this in 9.2.3.

Generated with apg.  I'll add some text.

> upgraded?  Do we leave ourselves open to any downgrade attacks by doing so?

This has already be changed in -02 to "backwards compatibility with RFC 5389".

> once.  Do we need to emphasize this more?

I think that the intent was that a future attribute may be defined as supporting to be inserted multiple times, and this rule just makes parsing a STUN packet more resilient (i.e. do not reject a STUN packet because there is more than one instance of a specific attribute).

I would leave the text as it is.

> In Section 14.2 what are the x's in   |x x x x x x x x|?

That's a good question.  I supposed that should all 0's.  Will change it in -03.

> The text in Section 15.3. Hash Agility Plan seems to be out of date now.

Why?

> reserved for future use.”  What port?

The port is in fact allocated now.  I will fix the text in -03.

> Perhaps a mention of ORIGIN in section 9.2 or 9.2.3 would be good, too.

Section 6.1 of -02.

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

---

From: Simon Perreault <[email-masked]>
Date: Thu, 19 Mar 2015 09:43:17 -0400

> It is not, which is sad because I find it better than draft-yusef-sipcore-digest-scheme.  It also fits better with STUN where the hash algorithm (SHA-1 and now SHA256) has been split off the passwo…

What you're saying makes sense, yet does not bring us closer to syncing
STUN and SIP auth. I don't know if it is a possible goal, but I feel it
is our duty to at least explore the possibility.

I note that the two drafts above are not working-group drafts. It would
be good to have a chat with the sipcore chairs in Dallas and reach a
common understanding of the situation...

Simon

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 19 Mar 2015 07:55:06 -0600

> common understanding of the situation...

Let's do that, but I noticed that sipcore will not have a session in Dallas.

- -- 
Marc Petit-Huguenin

---

From: Alan Johnston <[email-masked]>
Date: Thu, 19 Mar 2015 09:01:29 -0500

Marc & Simon,

Rifaat and many other SIPCORE folks will be in Dallas next week, so we
should definitely meet up and figure out a solution.

- Alan -

On Thu, Mar 19, 2015 at 8:55 AM, Marc Petit-Huguenin <[email-masked]>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> >> It is not, which is sad because I find it better than
> draft-yusef-sipcore-digest-scheme.  It also fits better with STUN where the
> hash algorithm (SHA-1 and now SHA256) has been split off the password hash
> algorithm (MD5) from the beginning.  draft-yusef-sipcore-digest-scheme does
> not even talk about the password algorithm, continuing the (I think) rather
> bad idea of linking the two together.
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQIcBAEBCAAGBQJVCtU5AAoJECnERZXWan7EHyYP/1gnBqKC/J1zuPYg+M4Xg3qV
> tXFQwAcTv9CuF+/9j0+vkSyUluopXTPP4i9hf8Ms4PRZc6QT3ZkBqpDwkZZYuXQK
> zPyxT1o2D5XV1dnjYfZXZcN68Bf/5rR23EHYRdY1j/fMPrEJkVP7vtu3Sr3xfXA7
> m4zcdKLA4u2OmK5aeDHP24+zcRAXOJ07WW6gudKSb3MAzOyn3sL4hC56tgQdJWNO
> wEyZXhIP4VdBjGy0Cs9wNrvZsgi7AR9J3HkOGZMv9gpH5ZI3yJYBHbyn3IuGa/ig
> u+rEXwXjdvBVPEmrNyd3PURop1V9szsHg2x86wn58DbH4YmRJeqXHT8uPiug+c7A
> 59rEPxiN3ajRQaN+KVEE7Zp5iQeFpPRKz6FJtd1261eMFawE0vMApGC4oaVZuEL8
> KQIGu+trEixJG8SI29UwYq5YLOOQsDBLP+q6uV6nqYgz9G8I2d4MeTZpTHQxOoGl
> 3+8OFkUJzqiteo59PP281NW4GCwS63iuRNzGHkpdb14X9SA91MJ0EEU0tcfMbro7
> u7APmH40ID8TqzfW2WQiL4ZlxxoyAIdMT4GkE13wAkxbJWQdEDJ19yfmMX6rtqnn
> lpMKsQFmZC3fyfZ43IuzJEziGcq+QDbltqetmef1kKnoDKTIHE3TX7FldUyIo7Ap
> P2FJWLCJksSm6yKh2O/2
> =5Iz6
> -----END PGP SIGNATURE-----
>