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

[Adam Roach <[e-mail]>]

On 8/14/18 11:11, Alan DeKok wrote:
> On Aug 14, 2018, at 11:51 AM, Adam Roach <[e-mail]> wrote:
>> I think we're getting off in the weeds here exactly because the language in the document is ambiguous. I think I made some assumptions that might not match yours. Let's try a level set.
>>
>> The document says that the token "SHOULD be cryptographically strong." What does this mean, and why do you need it?
>    The Operator-NAS-Identifier may contain information, such as an encrypted IP address.  In which case it should use sane encryption methods.
>
>    If it's just an opaque token, then the token value should be created via some sane method.  Mainly to avoid accidental re-use.

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.

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'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.


>> 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?

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.

/a

____
[1] I'm basing this in part on the text from §6: "This ensures that 
anyone observing unencrypted RADIUS traffic gains no information about 
the internals of the Visited Network."