Subject: [Isms] AD review comments for draft-ietf-isms-radius-usage-05

From: <[email-masked]>
Date: Tue, 7 Apr 2009 09:56:27 +0200

I've now done my AD review for draft-ietf-isms-radius-usage-05.  All
my comments are very minor, so I've requested the secretariat to start
IETF last call (these can be considered as the first last call
comments):

- Section 2.3 equates "secure transport" with "authPriv". While SSHTM
requires encryption, can't some future secure transport model provide
integrity/authentication only? Perhaps this could be rephrased as
"...SNMP over a secure transport which provides both integrity and
encryption (i.e. authPriv)".

- I'd suggest removing NAS-IP-Address from the table in Section 3
(otherwise, we probably should add NAS-IPv6-Address and
NAS-Identifier, too).

- The table in Section 3 lists Management-Policy-Id, but this
attribute is not mentioned anywhere else in the document.  Perhaps the
document should just say something like "[I-D.ietf-radext-management-
authorization] defines Management-Policy-Id and
Management-Privilege-Level attributes. How these are mapped into
e.g. an SNMP Access Control Model is beyond the scope of this
document" ?

- The table shows the User-Password attribute, but it's possible that
some SNMP transport model could support other authentication
mechanisms with RADIUS (like EAP or Digest). Perhaps Section 3
should say something like "SSH integration with RADIUS traditionally
uses passwords (with the User-Password attribute), but other secure 
transports could use other authentication mechanisms (such as EAP or 
HTTP Digest), and would include appropriate authentication attributes
instead of User-Password" ?

Best regards,
Pasi

---

From: "Dave Nelson" <[email-masked]>
Date: Tue, 7 Apr 2009 08:44:44 -0400

Pasi Eronen writes...
 
> - Section 2.3 equates "secure transport" with "authPriv".
> While SSHTM requires encryption, can't some future secure
> transport model provide integrity/authentication only?

Possibly...

> Perhaps this could be rephrased as "...SNMP over a secure
> transport which provides both integrity and encryption 
> (i.e. authPriv)".

OK.  That makes sense.

> - I'd suggest removing NAS-IP-Address from the table in
> Section 3 (otherwise, we probably should add NAS-IPv6-Address
> and NAS-Identifier, too).

Hmmm...  I'm trying to remember why that attribute was included.  Either
suggestion may be OK, but let's think for a while as to whether there is a
use case for this information.

> attribute is not mentioned anywhere else in the document.  Perhaps
> the document should just say something like "[I-D.ietf-radext-
> management-authorization] defines Management-Policy-Id and
> Management-Privilege-Level attributes. How these are mapped
> into e.g. an SNMP Access Control Model is beyond the scope of
> this document" ?

We purged any [veiled] references to access control authorization from this
draft in the very last revision, and this item was missed.  We should
probably remove the attribute from the table.

> - The table shows the User-Password attribute, but it's possible
> that some SNMP transport model could support other authentication
> mechanisms with RADIUS (like EAP or Digest).

Ahem.  I realize there has been a recent change of Security AD staff, but
when this work was beginning we were *firmly* informed that the
applicability statement for EAP prohibited it from being used for anything
except network access authentication, and certainly not for application
authentication, e.g. for SNMP.  There was a bit of a fuss, but it soon
subsided.  Are you now telling us this would be OK?

If so, then we could consider adding it as possibility.

I suppose some *could* use Digest Authentication...

> Perhaps Section 3 should say something like "SSH integration with
> RADIUS traditionally uses passwords (with the User-Password 
> attribute), but other secure transports could use other authentication
> mechanisms (such as EAP or HTTP Digest), and would include appropriate 
> authentication attributes instead of User-Password" ?

Yes, that would make sense, assuming we are really allowed to use EAP.

---

From: <[email-masked]>
Date: Mon, 27 Apr 2009 09:07:58 +0200

Dave Nelson wrote:
> Hmmm...  I'm trying to remember why that attribute was included.
> Either suggestion may be OK, but let's think for a while as to
> whether there is a use case for this information.

The information is certainly needed (and including one of
NAS-IP-Address/NAS-IPv6-Address/NAS-Identifier is required
by the RADIUS specs)... but I'm not sure if we really
need to include it in this table.

> We purged any [veiled] references to access control authorization
> from this draft in the very last revision, and this item was missed.
> We should probably remove the attribute from the table.

Ok.

> Ahem.  I realize there has been a recent change of Security AD
> staff, but when this work was beginning we were *firmly* informed
> that the applicability statement for EAP prohibited it from being
> used for anything except network access authentication, and
> certainly not for application authentication, e.g. for SNMP.  There
> was a bit of a fuss, but it soon subsided.  Are you now telling us
> this would be OK?

Well... no, I'm not saying that. But we already have drafts about SNMP
transport models that don't use passwords (although certificate-based
authentication doesn't necessarily integrate with RADIUS).

> > attribute), but other secure transports could use other
> > authentication mechanisms (such as EAP or HTTP Digest), and would
> > include appropriate authentication attributes instead of
> > User-Password" ?
> 

Perhaps "SSH integration with RADIUS traditionally uses passwords
(with the User-Password attribute), but other secure transports
could use other authentication mechanisms, and would include
authentication attributes appropriate for that mechanism instead
of User-Password"?

Best regards,
Pasi