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 08:02, Alan DeKok wrote:
> On Aug 13, 2018, at 10:06 PM, Adam Roach <[e-mail]> wrote:
>> This is a concern with the general mechanism, and might be due to a
>> misunderstanding on my part (which I hope you can clear up); but if I'm not
>> wrong, then I'm concerned that the mechanism as described can introduce RADIUS
>> message routing loops in some very common deployment scenarios.
>    I don't think so, for the simple reason that clearing houses don't accept CoA packets right now.
>
>    There are other reasons.

Thanks. This (and the rest of your explanation) makes sense.

>>> The value SHOULD be cryptographically strong, and SHOULD be
>>> verifiable by the Visited Network, without requiring it to track in a
>>> database every individual value of Operator-NAS-identifier which was
>>> issued.
>> I don't think this is really phrased in a way that means what you want to say.
>> If I had to guess, you mean to say that the value must be encrypted, and that it
>> must be integrity-protected. If integrity protection is important, then you also
>> need to consider techniques to avoid replay of previously-seen tokens
>    Why is replay an issue?  The point of obfuscating the information is to hide internal / private information about the network.  e.g. private IP of the NAS.

Generally, when integrity is important, so is anti-replay. If you care 
that remote parties can't create their own novel values, it would be 
surprising not to care about them squirreling away values they've seen 
before and using them later. Conversely, if you don't care about replay, 
you probably need to think really hard about why you care about integrity.

Of course, it's completely possible that I'm misunderstanding what you 
mean by "verifiable" in the original text (which gets to the heart of my 
original comment: there are terms of art for the properties that 
cryptography provides, and you really want to use them for the purpose 
of clarity.)

>    If a home server replays a previously-seen token, then one of two things will happen:
>
> - the packet will go to the NAS which hosts the user session, and will be processed normally
>
> - the packet will go to a different NAS, and will be NAKd

Sure. If that's the answer, then it seems like it's the same answer if 
the home server creates a new, invalid token; and that would mean that 
integrity isn't needed.

I'm afraid you need to go back and figure out what your actual security 
requirements are here by asking what attacks might exist, and what their 
consequences are. The current text seems to be kind of an afterthought 
without any real analysis.

>
>> (e.g., the
>> integrity protection needs to be over not just the Operator-NAS-Identifier,
>> but also over some portion of the session that prevents its replay). Most
>> notably, this desire for encryption and integrity protection is almost
>> certainly at odds with the assertion (in §3.3) that "A twenty octet string is
>> more than sufficient to individually address all of the NASes on the planet."
>> For example, the naïve approach of appending a SHA-256 hash to the end of an
>> encrypted, salted index into a table of NAS devices would require over 32 bytes
>> at its absolute minimum. So, if integrity protection is something that any
>> operator might ever want, you need to revisit the 20-byte limit.
>    32 bytes is fine.  I'll update that.

Sorry, by "more than 32 bytes," I meant that the hash itself would take 
32 bytes. You'd also have however long the Visited domain's identifier 
for the NAS is (which you originally thought would take 20 bytes), plus 
some number of nonce bytes (to prevent other networks from simply 
counting unique token values). You're really looking at more like 96 
bytes or so.

Note that this gets somewhat smaller if integrity protection isn't 
important.

>>> Other methods are
>>> possible, but we restrict ourselves to this usage, as it is the most
>>> common one.
>> This needs to be clear whether the *description* is restricted to NAI-based
>> routing, or whether the *mechanism* is. I suspect it's the former; in any case,
>> please add text.
>    This spec documents NAI-based CoA proxying.  Other methods can be used, but aren't discussed here.
>
>    The mechanism for discovering next hop is specific to NAI-based proxying.

Okay; make this clearer, please.

Thanks!

/a