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 9:43 AM, Adam Roach <[e-mail]> wrote:
> 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.)

  In this situation, all we really care about is that the opaque token is known.  And it really should be opaque.  It's just bits, and not necessarily containing anything in particular.

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

  Yes.

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

  Maybe I'm missing something, but it's pretty hard to "attack" an opaque token.  It can be (a) modified, or (b) replayed.  If it's modified, it doesn't match anything and it gets ignored.  If it's replayed, it's still a recognized token, and that's OK.

  All of the attacks here *also* depend on systems knowing the RADIUS shared secret.  i.e. these systems are already part of a trusted network.  They are already trusted to not replay accounting packets, authentication packets, forge accounting traffic (to increase bills), etc.

  The attacks for CoA here are nothing new.  The security is terrible, but we've lived with it for 25+ years, and it's what we have.

  Finally, if trusted parties attack you, the fix is usually legal, not technical.

  I'll update the Security Considerations section with some text on why roaming consortiums are open to forging.  But I think the risks here are fairly well known.

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

  Integrity protection isn't important.

  Alan DeKok.