Subject: [Isms] RE: Follow up on Authorize Only issue

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Sun, 23 Jul 2006 09:02:01 -0700

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

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: "Kaushik Narayan \(kaushik\)" <[email-masked]>
Date: Mon, 24 Jul 2006 11:07:45 -0700

Hi All,

I think the security risk is really tied to AAA use case and what
constitutes authorization.

As pointed out by several folks, there is definitely a significant
security risk if the model of authorization involves a general purpose
attribute assertion, i.e. the NAS acquiring any set of attributes tied
to the session. The other end of the spectrum is to have an
authorization assertion model wherein the AAA server is always
responding with a permit/deny (this is the TACACS+ per-command authz
model).

I think the authorization assertion model will not scale for the SNMP
use case so the only way to address this issue seems to be to restrict
the scope (what attributes can be retrieved with Authorize-only) of the
attribute assertion based on the Service-Type, I think this is what
Bernard and some others had suggested. 

regards,
  kaushik!

-----Original Message-----
From: Nelson, David [mailto:[email-masked]] 
Sent: Friday, July 21, 2006 1:44 PM
To: [email-masked]; [email-masked]
Subject: [Isms] RE: Follow up on Authorize Only issue

> authorization information about a user that is not actually "present" 
> at the NAS?

My interpretation is that three respondents (Glen, Alan, Avi) believe
that the answer is "no".  The existing RADIUS trust model collapses if
the NAS has been compromised and does nefarious or foolish things.

I'd like to determine if we have consensus on this position.  If you
*have* an opinion on this issue, please *respond* whether you agree or
disagree with this assertion.

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Tue, 25 Jul 2006 12:59:16 -0700

Nelson, David <mailto:[email-masked]> supposedly scribbled:

...

> 
> There was also a suggestion on the list that the NAS convey the
> asserted identity to the RADIUS Server for audit purposes.  This
> could be accomplished by a (new) Asserted-Identity attribute.  

How would this be different than the User-Name attribute?

~gwz

---

From: "Nelson, David" <[email-masked]>
Date: Tue, 25 Jul 2006 17:00:08 -0400

Jeff Hutzelman writes...

> If the RADIUS server wishes to log the NAS's request, it's welcome to
do
> so, but what information is relevant to that that's not a necessary
part
> of the request?

I think I've added some unintentional confusion.  Indeed, the "user
name" is necessary in the access request so that the server can perform
the profile lookup.  Someone had suggested on the list that additional
information _might_ be provided as an outcome of authentication that
could be additionally passed along for auditing purposes.  I think the
example was given of a Kerberos ticket.  Now I don't know if that makes
any sense, and the suggestion wasn't accompanied by a detailed use case.
So, maybe the auditing suggestion is a red herring.

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Tue, 25 Jul 2006 21:54:37 -0700

Jeffrey Hutzelman <mailto:[email-masked]> supposedly scribbled:

> On Tuesday, July 25, 2006 02:20:49 PM -0700 "Glen Zorn (gwz)"
> <[email-masked]> wrote:
> 
>> Actually, no, at least in current usage an authentication type
>> _always_ has an associated attribute, which can be seen as something
>> that the server doesn't understand.
> 
> Is there a requirement that a server reject a request which contains
> any attributes it doesn't understand? 
> 
> 
> 
>>> A RADIUS server which supports authorize-only will
>>> probably want to return success for the request using that feature,
>>> but still must return failure for requests using methods it doesn't
>>> understand.  To make the distinction, you need an affirmative
>>> indication from the client that it wants authorize-only;
>> 
>> Is that not provided by the Service-Type of Authorize-Only?
> 
> Not if you want to use Service-Type to actually indicate the service
> type, 
> instead of overloading it to mean something else.  As I understand
> it, this 
> attribute is _supposed_ to indicate the type of service the NAS is
> providing to the user, and overloading it to mean something else was a
> mistake.  If this attribute is used for its intended purpose, to
> allow the 
> RADIUS server to know what service to provision, then it cannot also
> be 
> used to indicate authorize-only mode.

Too late, it already is.

Hope this helps,

~gwz

---

From: "Nelson, David" <[email-masked]>
Date: Wed, 26 Jul 2006 07:45:29 -0400

Glen Zorn writes...
 
> > If this attribute is used for its intended purpose, to allow the
> > RADIUS server to know what service to provision, then it 
> > cannot also be used to indicate authorize-only mode.

> Too late, it already is.

Yes, for the Dynamic RADIUS Change of Authorization use case, as specified in RFC 3576.  It has no formally specified usage outside 3576, that I recall.  We need not use that method for the "general" authorization only case.  We could devise a new method, such as the Asserted-Identity attribute, and relegate the Service-Type = "Authorize Only" usage to CoA only.

I tend to agree with Jeff that this portion if RFC 3576 was probably a "mistake".  I can say that as I had nothing to do with that document.  Whether it was or wasn't, we are not obligated to carry that particular usage into other areas of application for RADIUS.

---

From: "Nelson, David" <[email-masked]>
Date: Wed, 26 Jul 2006 14:20:54 -0400

Juergen Schoenwaelder writes...
 
> Given our current charter, I like to see the RADIUS document we are
> chartered to produce focus on the RADIUS SSH user authentication and
> RADIUS authorization of the SSH SNMP subsystem.

We'll omit any discussion of "fine grained" access control, i.e.
anything other than whether the SSH server should offer to make a
connection to the SNMP engine, in the -01 version.

> Note that this does of course not impact the RADEXT document which
> may define all attributes needed to address all the RADIUS related 
> ISMS requirements.

OK, thanks.

> I actually like to encourage people to write a document which 
> explains how VACM can utilize RADIUS to provision the security 
> name to group name mapping and to post such a document as an 
> individual draft.

I also think that would be useful, and predict that folks are likely to
implement such a scheme, whether ISMS takes it up or not.

---

From: "Nelson, David" <[email-masked]>
Date: Wed, 26 Jul 2006 16:03:22 -0400

Avi Lior writes...

> But 3576 and WG decided not to go there.

Unless I'm mistaken, RFC 3576 was not the work product of any WG.  It
occurred after the RADIUS WG closed, and prior to the RADEXT WG opening.

> In hindsight, Authorize/Authetnication/Callcheck/etc should have used
an
> attribute specifically for that purpose.

Perhaps.

> The lesson is that we should be learning is not to overload
attributes.

I agree.
 
> I think introducing another Authorize-Only semantic is bad as well. I
> think that saying that Authorize-Only is only a 3576 think flies in
the
> nature of all RADIUS RFCs.

There are potential disadvantages, primarily in terms of how existing
RADIUS servers are implemented, but I don't see this as quite so much of
a problem.

> Finally, in view of the overloading of Service-Type, the use of
> NAS-Port-Type to provide a context for the type of service being
> requested is not ideal but it does work.

IMHO, overloading NAS-Port-Type is as bad as, if not worse than,
overloading Service-Type.  Overloading is overloading.  Overloading is
bad.  ;-)