RE: Follow up on Authorize Only issue

["Glen Zorn \(gwz\)" <gwz@cisco.com>]

Bernard Aboba <> supposedly scribbled:

> The security implications of unrestricted access to *any* user
> attributes are fairly severe. 

I agree, but apparently not severe enough to warrant changing the way RADIUS handles CHAP at any time over, oh , the last 10 years.

> 
> For example, should a NAS be able to retrieve the Tunnel-Password
> attribute of any user, regardless of whether they are connected? 

Of course not, but there are arguably lots of things that shouldn't be yet are: the point is that allowing Authorize-Only in this case actually doesn't open any new security holes.

> 
> There are also VSAs that contain sensitive information.
> 
> The Call-Check Service typically provides very little information in
> the Access-Accept (all that is needed is whether to accept or reject
> the call) so there is minimal leakage.  
> 
> If this is allowed, it should follow the principle of "least
> privilege", only providing the attributes relevant to SSH. 
> 
> 
> 
> 
>> For the SSHSM usage case, the question is whether it is an
>> unacceptable security risk for a trusted NAS to be able to obtain
>> authorization information about a user that is not actually
>> "present"  at the NAS?

OK, this is becoming slightly absurd.  I am not a cryptographer, but I do know that one of the cardinal assumptions of secret-key cryptography is that the secret key stays secret.  This "trusted NAS" should not be trusted because the secret has been compromised; if the secret is no longer a secret, all bets are off. 

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>