Subject: [tram] WGLC draft-ietf-tram-turn-third-party-authz-03

From: Simon Perreault <[email-masked]>
Date: Wed, 10 Sep 2014 08:18:33 -0400

TRAMsters,

This email initiates a two-week working-group last call on this draft:

http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-03

Please read it now. Substantial comments should be addressed to the group.
Nits should be sent directly to the authors.

Thanks,
Simon & Gonzalo

---

From: Oleg Moskalenko <[email-masked]>
Date: Sat, 13 Sep 2014 01:04:25 -0700

While reading the token encryption / decryption process description, I
failed to figure out how we handle the initialization vector (IV) of the
symmetric encryption algorithm (like AES_256_CBC). If we do not know what
was the IV used when we were encrypting the token, then we cannot decrypt
it. I see no provision for the IV in the token structure.

We have three options:

1) Authorization server and TURN server are agreeing upon a static IV,
out-of-band. A bad unsecure option.
2) The IV is always all zeros. Even a worse option than the first one.
3) Each encrypted message carries its own random IV.

The third option is the most secure, recommended option.

I would rewrote the token structure as:

struct {
  uint16_t iv_length;
  opaque iv[iv_length];
  opaque {
    uint16_t key_length;
    opaque mac_key[key_length];
    uint64_t timestamp;
    uint32_t lifetime;
  } encrypted_block;
  opaque mac[mac_length];
} token;

Thanks
Oleg

On Wed, Sep 10, 2014 at 5:18 AM, Simon Perreault <[email-masked]>
wrote:

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

---

From: Oleg Moskalenko <[email-masked]>
Date: Sat, 13 Sep 2014 01:45:40 -0700

If we limit ourselves to AES encryption only, then the block size is always
128 bits and the IV size is always 16 bytes. The proposed token structure
would be:

struct {
  opaque iv[16];
  opaque {
    uint16_t key_length;

Thanks
Oleg

On Sat, Sep 13, 2014 at 1:04 AM, Oleg Moskalenko <[email-masked]>
wrote:

>> Please read it now. Substantial comments should be addressed to the
>> group. Nits should be sent directly to the authors.
>>
>> Thanks,
>> Simon & Gonzalo
>>

---

From: Brandon Williams <[email-masked]>
Date: Sat, 13 Sep 2014 13:46:25 -0400

I agree that the token should include space for an IV. That will make it 
a little longer, but that can't really be avoided.

There's no need to dictate the encryption algorithm or to specify the 
length of the IV in the message. Since both sides already know the 
encryption algorithm and the IV length is dictated by the encryption 
algorithm, iv can be variable length without an explicit length field.

--Brandon

On 09/13/2014 04:45 AM, Oleg Moskalenko wrote:
> If we limit ourselves to AES encryption only, then the block size is
> always 128 bits and the IV size is always 16 bytes. The proposed token
> structure would be:
>
> struct {
>    opaque iv[16];
>    opaque {
>      uint16_t key_length;
> On Sat, Sep 13, 2014 at 1:04 AM, Oleg Moskalenko <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     While reading the token encryption / decryption process description,
>     I failed to figure out how we handle the initialization vector (IV)
>     of the symmetric encryption algorithm (like AES_256_CBC). If we do
>     not know what was the IV used when we were encrypting the token,
>     then we cannot decrypt it. I see no provision for the IV in the
>     token structure.
>
>     We have three options:
>
>     1) Authorization server and TURN server are agreeing upon a static
>     IV, out-of-band. A bad unsecure option.
>     On Wed, Sep 10, 2014 at 5:18 AM, Simon Perreault
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         TRAMsters,
>
>         Please read it now. Substantial comments should be addressed to
>         the group. Nits should be sent directly to the authors.
>
>         Thanks,
>         Simon & Gonzalo
>
>         [email-masked] <mailto:[email-masked]>

-- 
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.

---

From: Oleg Moskalenko <[email-masked]>
Date: Sat, 13 Sep 2014 13:19:20 -0700

> On Sep 13, 2014, at 10:46 AM, Brandon Williams <[email-masked]> wrote:
> 
> I agree that the token should include space for an IV. That will make it a little longer, but that can't really be avoided.
> 
> There's no need to dictate the encryption algorithm or to specify the length of the IV in the message. Since both sides already know the encryption algorithm and the IV length is dictated by the encryption algorithm, iv can be variable length without an explicit length field.

I agree. As most implementations will probably support AES only, and all AES algorithms have 128 block size ( regardless the key length), the IV length 16 bytes will be the de-facto standard, but we leave the door open to other algorithms.

Oleg

---

From: Oleg Moskalenko <[email-masked]>
Date: Sun, 14 Sep 2014 02:55:11 -0700

I have an additional note on AEAD algorithms. In AEAD, they usually are
referring to the IV as "nonce". In the draft document the AEAD "nonce" is
stored in the "mac" field of the structure. So if we put the IV in the "iv"
field for non-AEAD algorithms, but we put IV into "mac" algorithms (and
what in "iv" ?) then we have a sort of mess. I'd propose to re-define the
structure, in a more consistent and logical way, with "mac" field as an
optional field, as:

struct {
  opaque iv[iv_length]; //also can be called "nonce"
  opaque {
    uint16_t key_length;
    opaque mac_key[key_length];
    uint64_t timestamp;
    uint32_t lifetime;
  } encrypted_block;
  opaque mac[mac_length]; //optional field
} token;

where:

1) iv_length is defined by the encryption algorithm. For example, non-AES
algorithms use iv_length 16, and AEAD AES algorithms use iv_length 12. In
the case of AEAD algorithms, this field can also be called "nonce".
2) The field mac is optional. When AEAD is used, then the mac field has
zero length.

I'd change the corresponding wording in the AEAD-related text, concerning
"mac" and "nonce" (see the end of section 6.2).

Thanks
Oleg

On Sat, Sep 13, 2014 at 1:19 PM, Oleg Moskalenko <[email-masked]>
wrote:

> I agree. As most implementations will probably support AES only, and all
> AES algorithms have 128 block size ( regardless the key length), the IV
> length 16 bytes will be the de-facto standard, but we leave the door open
> to other algorithms.
>
> Oleg
>
>
> >
> > --Brandon
> >

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sun, 14 Sep 2014 16:43:03 +0000

Hi Oleg,

IV was not added to the token because the Authorization server for every new token produced does not generate identical data.

-Tiru

From: tram [mailto:[email-masked]] On Behalf Of Oleg Moskalenko
Sent: Saturday, September 13, 2014 1:34 PM
To: Simon Perreault
Cc: [email-masked]
Subject: Re: [tram] WGLC draft-ietf-tram-turn-third-party-authz-03

While reading the token encryption / decryption process description, I failed to figure out how we handle the initialization vector (IV) of the symmetric encryption algorithm (like AES_256_CBC). If we do not know what was the IV used when we were encrypting the token, then we cannot decrypt it. I see no provision for the IV in the token structure.
We have three options:
1) Authorization server and TURN server are agreeing upon a static IV, out-of-band. A bad unsecure option.
2) The IV is always all zeros. Even a worse option than the first one.
3) Each encrypted message carries its own random IV.
The third option is the most secure, recommended option.
I would rewrote the token structure as:
struct {
  uint16_t iv_length;
  opaque iv[iv_length];
  opaque {
    uint16_t key_length;
    opaque mac_key[key_length];
    uint64_t timestamp;
    uint32_t lifetime;
  } encrypted_block;
  opaque mac[mac_length];
} token;
Thanks
Oleg

On Wed, Sep 10, 2014 at 5:18 AM, Simon Perreault <[email-masked]> wrote:
TRAMsters,

Please read it now. Substantial comments should be addressed to the group. Nits should be sent directly to the authors.

Thanks,
Simon & Gonzalo

---

From: Oleg Moskalenko <[email-masked]>
Date: Sun, 14 Sep 2014 11:21:01 -0700

Hi Tiru

thanks for the explanation. I understand the reasoning.

Regards,
Oleg

On Sun, Sep 14, 2014 at 9:43 AM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:

> Hi Oleg,
>
> IV was not added to the token because the Authorization server for every
> new token produced does not generate identical data.
>
> -Tiru
>

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 21 Sep 2014 05:37:01 -0600

> Nits should be sent directly to the authors.

Before even starting talking about the details about 3rd party authorization,
I have an issue about how this authorization scheme is presented in this draft.

RFC 5389 defines two authentication mechanisms, a Short-Term Credential
Mechanism (STCM) in section 10.1 and a Long-Term Credential Mechanism (LTCM)
in section 10.2.  None of these mechanisms are tied to a specific STUN usage,
although, even at the time RFC 5389 was written, it was clear that STCM was
designed to be used with ICE and LTCM with TURN.  The RFC 5389 authors, who
are IETF veterans, knew that the IETF does not provides protocol for
applications, but building blocks, and these two sections reflects exactly that.

Now my beef with draft-ietf-tram-turn-third-party-authz is that it is written
as providing a protocol for an application, but not as a building block.  It
should have be written in the same spirit than section 10.1 or 10.2 of RFC
5389, i.e. as a generic authentication mechanism with different properties
than these two.

So my advice is to completely rewrite this draft to make it independent of
TURN, and make it just another STUN Credential Mechanism (let's call it 3rd
Party Credential Mechanism, 3PCM).

Then we can have a separate section (or, better, a separate draft) that
modifies TURN to use 3PCM as a replacement for LTCM.

I'll do a more complete review if and when this rewrite will be done.  Until
then I do not support the publication of this draft in this form.

Thanks.

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

---

From: Oleg Moskalenko <[email-masked]>
Date: Sun, 21 Sep 2014 10:03:11 -0700

I am not sure that "3PCM" can be distinguished as an independent
replacement for "LTCM". I rather view 3PCM as a
variation/extension/evolution of LTCM.

A third-party authorization server can be used with LTCM as-is, but that
would be somewhat complicated and unnatural. The 3PCM draft proposed an
extension to LTCM that allows natural convenient way of using a third-party
server.

The draft could be re-worded to eliminate tight connection to TURN, if
that's absolutely necessary.

Oleg

On Sun, Sep 21, 2014 at 4:37 AM, Marc Petit-Huguenin <[email-masked]>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> group.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQIcBAEBCAAGBQJUHrhcAAoJECnERZXWan7EbKIP/jM282eKSOYViBY8qeUsCfO8
> 4U+Ar3CGWXqeUCbsB8K7DvQppZY+R7b9/j7yv0sVWgIo9vTlt758Vf660Ag4XFK0
> hhJC55g9PeNRqRcKQlpp2m9/rMpuHPY95GKd7+PaczJ2Q/8NIUb0/XeBIX9+V5MM
> 48Y4pd/bfndwPHEUWHh+ypljqcClzaYsAA/jxmoO5vJPnipNIficvSxj4MB703Yq
> UPxc98hDsu3yU+5/aAjLkCz1tbj41uGmTenYCywFHTEYRAZZPw+1u0qHffsOEcOK
> JIIk9EELcaWZ0YE2aAKUfnKs/G45+/JCKAYw1/jr4CjdatgV8GJPMfq+gbUW15n+
> N9744LbUxarokc/N0Ey07gB2rihtVhoQLeC9YGUj6KGoNNb2PukCTE7l8FbRIMWX
> OrfuppEhZjn2KzZyPw9mvtoeoDHz+lYwyYRKHsrz/mw7n8OVy+gwSHsvlLRGiI1D
> h6vPkTHeqI5jThgfcK5ffVGMNrHIhoSghMzWE2Lul54pm3f/kDucQ8klluqL1mAt
> MdrmO95jyGs7QlOrHpVRM+vgnWrufG8332Q26BL0vPqWwTKE3i0tiGYinS2xiaL0
> FaRFvhUuuzv+jwapsKJfWhgo9Nb0MiO0ElF34RFooCzkFToCn3FvUzCZirbny1TS
> HdCDNaA9A5U63rVgkv8e
> =62Q8
> -----END PGP SIGNATURE-----
>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 22 Sep 2014 05:05:00 +0000

Third party authorization is relevant to TURN server usage and don't see a need for STUN server on the Internet to support it.  If at all there is a use case for third party authorization in future with STUN 
server then the mechanism proposed in the draft will also work with STUN server.

-Tiru

> -----Original Message-----
> From: tram [mailto:[email-masked]] On Behalf Of Marc Petit-
> Huguenin
> Sent: Sunday, September 21, 2014 5:07 PM
> To: [email-masked]

---

From: Simon Perreault <[email-masked]>
Date: Mon, 22 Sep 2014 08:51:55 -0400

> variation/extension/evolution of LTCM.

Does that really matter?

Whether you're using 3PCM or LTCM is easily determined by looking at the
packets. That's what matters. If the protocol is different, then as far as
we're concerned they're different things.

> extension to LTCM that allows natural convenient way of using a third-party

Correct, but again I don't see why that matters.

> that's absolutely necessary.

I don't think it's "absolutely necessary", but I think it's very desirable.
I've been saying it since the beginning: this authentication mechanism is
for STUN, not for TURN. I fully agree with Marc's comment. Although I don't
think the draft needs a "rewrite". A careful search & replace should be
sufficient to make the text TURN-agnostic.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Mon, 22 Sep 2014 08:54:33 -0400

On Mon, Sep 22, 2014 at 1:05 AM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:

> Third party authorization is relevant to TURN server usage and don't see a
> need for STUN server on the Internet to support it.
>

That's irrelevant IMHO.

> If at all there is a use case for third party authorization in future with
> STUN

Exactly! That's the very reason why this extension needs to be described in
terms of STUN.

Simon

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Mon, 22 Sep 2014 13:04:45 +0000

>5389, i.e. as a generic authentication mechanism with different properties

The only piece of the draft that follows a protocol is the "Token". Im
afraid it has to be this way because token construction has to be very
clearly defined, so all parties play nice. The solution will not be
interoperable otherwise.

Most of everything else is non-prescriptive, but only explains how things
are to work with OAuth. It's quite like a building block:
For example, the draft does not prescribe any protocol for interactions
between the Authorization-Server and the Turn Client to obtain a token.
The draft only provides an example of how this could be achieved.
Similarly, for Key-Establishment, the draft does not prescribe a specific
means to establish keys between the Authorization-Server and the TURN
Server. It only suggests possible means for this establishment.

>Party Credential Mechanism, 3PCM).

Will it suffice if we mentioned that the draft explains the solution with
TURN as an example, but is equally applicable for other STUN usages.

-Prashanth

---

From: Simon Perreault <[email-masked]>
Date: Mon, 22 Sep 2014 09:12:09 -0400

> TURN as an example, but is equally applicable for other STUN usages.

Not really. It is more than "equally applicable to other STUN usages": it
is usage-agnostic. What would be more appropriate IMHO would be to define
the extension in terms of the base STUN protocol, make no mention of any
STUN usage, then in a separate section show an example using TURN.

Simon

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Mon, 22 Sep 2014 13:51:39 +0000

Sure, we'll update the next revision accordingly.

-Prashanth

From: Simon Perreault <[email-masked]<mailto:[email-masked]>>
Date: Monday, September 22, 2014 6:42 PM
To: Prashanth Patil <[email-masked]<mailto:[email-masked]>>
Cc: Marc Petit-Huguenin <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [tram] FW: WGLC draft-ietf-tram-turn-third-party-authz-03

On Mon, Sep 22, 2014 at 9:04 AM, Prashanth Patil (praspati) <[email-masked]<mailto:[email-masked]>> wrote:
Will it suffice if we mentioned that the draft explains the solution with
TURN as an example, but is equally applicable for other STUN usages.

Not really. It is more than "equally applicable to other STUN usages": it is usage-agnostic. What would be more appropriate IMHO would be to define the extension in terms of the base STUN protocol, make no mention of any STUN usage, then in a separate section show an example using TURN.

Simon