Re: [radext] Adam Roach's Discuss on draft-ietf-radext-coa-proxy-05: (with DISCUSS and COMMENT)

[Alan DeKok <[e-mail]>]

On Aug 14, 2018, at 1:16 PM, Adam Roach <[e-mail]> wrote:
> You've described what you mean, without saying why you need it, and so I'm not sure what you mean achieves what you think you need -- and I have have a creeping suspicion that it does not.

  Let me back up.

  The scheme could work just as well if Operator-NAS-Identifier contained the actual IP address of the NAS.

  The main reason to make it private is that there is no compelling reason to make it public.  And as a general rule, keeping private things private is a good idea.

> I *think* the idea here is hiding things like how many NASes you have deployed in your network [1]. If that's the case, you'll minimally need some guidance here about each token being encrypted separately, using a unique nonce.

  I don't think that's necessary.  See below.

> I'll note that the creation of opaque tokens that don't differ between requests (as you seem to suggest above) doesn't achieve the goal of hiding the number of NASes -- it's not harder to count unique opaque tokens than it is to count IP addresses.

  Of course.  That being said... Access-Request and Accounting-Request packets typically contain the MAC address of the NAS.  So the number of NASes is already public information.

>>> The document says that the token "SHOULD be verifiable by the Visited Network." What does this mean, and why do you need it?
>>   The visited network needs to know that the token maps to an actual NAS.
>> 
>>   If the token is an encrypted blob, it can decrypt the blob and verify it that way.
> 
> Sorry, verify it how?

  It's probably better to just not refer to verifying the value.

> Let's say my token generation scheme is to take the IP address of the NAS, pack it up in network byte order, and run it through some encryption algorithm. So, I get a blob in a Disconnect-Request message, run it through decryption, and get four bytes:  136, 35, 8, and 43. That looks like a valid IP address to me. I still can't tell whether I generated the blob, or whether someone else just created a random blob and that's what it happened to decrypt to -- because most four-byte sequences are valid IPv4 addresses.
> 
> And, as for needing to know that it maps to an actual NAS: why? If the something is messing up these tokens and the worst thing that happens is that the transaction fails, that seems to be fine.

  Sure.

  To be honest, this is really getting into details which I don't think matter in the real world.  CoA packets are only accepted from trusted parties.  Or transitively, from parties they trust.  All of those parties have access to all of the user session identification information.  If the parties mangle the Operator-NAS-Identfifier, then the transaction fails.  So they have no reason to do so.  And much of the information about a NAS (and their number) is already public.

  Which means that there is substantially less reason to make the Operator-NAS-Identifier unique, verifiable, etc.  Just encrypt the IP address, and it's fine.  Or, create an opaque token per NAS, store token/IP in a table, and it's fine.

  Any security issues with the contents of Operator-NAS-Identifier are largely mitigated by the utter crap-fest that's the rest of RADIUS.  Which means that it doesn't really matter how the values of Operator-NAS-Identifier are created, stored, or used.

  Alan DeKok.