[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Follow up on Authorize Only issue
- To: "Bernard Aboba" <firstname.lastname@example.org>
- Subject: RE: Follow up on Authorize Only issue
- From: "Glen Zorn \(gwz\)" <email@example.com>
- Date: Sun, 23 Jul 2006 09:02:01 -0700
- Authentication-results: sj-dkim-4.cisco.com; header.Fromfirstname.lastname@example.org; dkim=pass ( sig from cisco.com verified; );
- Cc: <email@example.com>, <firstname.lastname@example.org>
- Dkim-signature: a=rsa-sha1; q=dns; l=1751; t=1153670523; x=1154534523; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; email@example.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20<firstname.lastname@example.org> |Subject:RE=3A=20Follow=20up=20on=20Authorize=20Only=20issue; X=v=3Dcisco.com=3B=20h=3DgYUCFFU2lrC1AfD+49l4JpczLFs=3D; b=D7rhSGItymYOuz6XgSOOBnoycpvDMjHY3jiVtXhsg0fdydjH67/Fl1/PyU3QjoJnZQjBeFSg Q/KqZRlAcM/I/TaXdlc1y126A2IqdJYCuuIoyVANAZkXyklS0tC26xAT;
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,
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 email@example.com with
the word 'unsubscribe' in a single line as the message text body.