Subject: [radext] Eric Rescorla's No Objection on draft-ietf-radext-coa-proxy-05: (with COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Wed, 15 Aug 2018 08:15:07 -0700

Eric Rescorla has entered the following ballot position for
draft-ietf-radext-coa-proxy-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-radext-coa-proxy/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D5085

I concur with Adam's DISCUSS (but marking no-objection to let him
manage this). Specifically, you need to describe what the security
expectations are for the Operator-NAS-Identifier. Need it be
unguessable? Should separate identifiers that refer to the same NAS be
unlinkable? "Cryptographically strong" is not a sufficiently specific
term to determine what the requirements are here.

COMMENTS
S 6.
>      issues.
>   
>      The Operator-NAS-Identifier SHOULD be created by the Visited Network
>      such that its contents are opaque to all other parties.  This ensures
>      that anyone observing unencrypted RADIUS traffic gains no information
>      about the internals of the Visited Network.

See above about the requirements here. Does there need to be an
unlinkable identifier each time?

---

From: Alan DeKok <[email-masked]>
Date: Wed, 15 Aug 2018 11:26:36 -0400

> term to determine what the requirements are here.

  I've rewritten the problem text in order to (a) avoid these issues, and (b) discuss the security implications in more detail.

> unlinkable identifier each time?

  No.

  External parties already know the identity and number of NASes in a Visited Network.  The Operator-NAS-Identifier attribute here is opaque simply because there is no compelling reason for giving it a public meaning.

  As such, there is no need for integrity checks, replay detection, privacy, etc.

  Alan DeKok.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 15 Aug 2018 09:12:44 -0700

On Wed, Aug 15, 2018 at 8:26 AM, Alan DeKok <[email-masked]> wrote:

>   I've rewritten the problem text in order to (a) avoid these issues, and
> (b) discuss the security implications in more detail.
>
> > COMMENTS
> > S 6.
> >>     issues.
> >>
>   External parties already know the identity and number of NASes in a
> Visited Network.  The Operator-NAS-Identifier attribute here is opaque
> simply because there is no compelling reason for giving it a public meaning.
>

OK, well, the text needs to say this, because the existing text implies
otherwise.

-Ekr

---

From: Alan DeKok <[email-masked]>
Date: Wed, 15 Aug 2018 12:14:21 -0400

On Aug 15, 2018, at 12:12 PM, Eric Rescorla <[email-masked]> wrote:
> OK, well, the text needs to say this, because the existing text implies otherwise.

  I will issue a new version shortly with the offending text removed, and the above text added.

  Alan DeKok.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 15 Aug 2018 09:37:52 -0700

Fantastic. Thanks!

-Ekr

---

From: Adam Roach <[email-masked]>
Date: Wed, 15 Aug 2018 14:47:23 -0500

Alan --

Thanks for the new text. This is a nice set of improvements overall, but 
I still
have concerns relating to the contents of the Operator-NAS-Identifier 
attribute.

---------------------------------------------------------------------------

§3.4:

 >  Length
 >
 >     4 to 23.
 >
 >     Implementations supporting this attribute MUST be able to handle
 >     between one (1) and thirty-two (32) octets of data.

It seems to me that "4 to 23" needs updating here.

I'll note that 32 octets is still too short for modern block-based ciphers
(the "more than" in my "more than 32 bytes" suggestion probably should have
said "much more than."). For example, if someone wanted to use GCM here (as
the text still says "encrypt"), you'd need 32 bytes for the ciphertext, 4 to
32 bytes for the tag, and something on the order of 12 bytes for the IV. 
So it
would be more like 76 bytes rather than 32.

Alternately, and this is my suggestion, remove "encrypt" entirely from this
section, replacing it with "obfuscate." Concretely:

       The second method is to obfuscate the NAS IP address using 
information
       known locally by the Visited network; for example, by XORing it 
with a
       bitmask.  The output of that obfuscation operation is data that 
can be
       used as the value of Operator-NAS-Identifier.  On reception of a CoA
       packet, the locally-known information can be used to un-obfuscate the
       value of Operator-NAS-Identifier, in order to determine the 
actual NAS
       IP address.

Given that we've established that actual encryption isn't necessary 
here, this
seems easier than expanding the field to be large enough to actually encrypt
stuff.

---------------------------------------------------------------------------

§2.1:

 >  In order to determing the "next hop" for a packet, the proxying

Nit: "...determine..."

Thanks!

/a

On 8/15/18 11:37, Eric Rescorla wrote:
> Fantastic. Thanks!
>
> -Ekr
>
>
> On Wed, Aug 15, 2018 at 9:14 AM, Alan DeKok <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     On Aug 15, 2018, at 12:12 PM, Eric Rescorla <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >

---

From: Alan DeKok <[email-masked]>
Date: Wed, 15 Aug 2018 15:51:54 -0400

On Aug 15, 2018, at 3:47 PM, Adam Roach <[email-masked]> wrote:
> 
> Alan --
> 
> Thanks for the new text. This is a nice set of improvements overall, but I still
> have concerns relating to the contents of the Operator-NAS-Identifier attribute.
> 

  Yes.  I'll fix that.

>       The second method is to obfuscate the NAS IP address using information
>       known locally by the Visited network; for example, by XORing it with a
>       bitmask.  The output of that obfuscation operation is data that can be
>       value of Operator-NAS-Identifier, in order to determine the actual NAS
>       IP address.
> 
> Given that we've established that actual encryption isn't necessary here, this

  That sounds better.

  Fixed.

  Alan DeKok.