Subject: AD review of draft-ietf-radext-management-authorization-05.txt

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 4 Sep 2008 18:12:04 +0200

Please my below my AD comments for
draft-ietf-radext-management-authorization-05.txt. In general this is a
well-written and rather straight forward document, in good shape for
IETF Last Call. I suggest that the editors discuss my comments before
suggesting a resolution about whether a Revised ID is needed before the
IETF last Call or not. 

1. section 2, page 4: replace 'NETCONF(XML over/SSH/BEEP/SOAP)' by
'NETCONF(XML over SSH or BEEP or SOAP)'

2. section 5.2 and the following refer to 'a transport with equal or
better protection'. I am wondering whether such a hierarchy of the
Management-Transport-Protection is or will be always possible. Actually
we may have a problem already, as SNMP allows any combination of
authentication and privacy modes, and it is not clear which is the
'better' between (auth, noPriv) and (noAuth, priv). 

3. Related to the previous comment and in the same section - the
Confidentiality-Protection value is missing from the enumeration of
Value in the definition of the Management-Transport-Protection attribute

4. Section 5.3 

   No precedence relationship is defined for multiple occurrences of the
   Management-Policy-Id (TBA-4) Attribute.  NAS behavior in such cases
   is undefined.  Therefore, two or more occurrences of this attribute
   SHOULD NOT be included in an Access-Accept or CoA-Request.

I am wondering if a MUST NOT would not be in place here. How can
interoperability of different vendors solutions be ensured if two or
more occurrences of the attribute are included in an Access-Accept or
CoA-Request and no standard precedence algorithm is in place? Any reason
to allow this at all ever? 

5. Last paragraph in Section 5.3, page 11 

.  It is recommended that
   the message contain UTF-8 encoded 10646 [RFC3629] characters.

It looks to me that RECOMMENDED needs to be capitalized here. 

6. Section 9 - page 17 - I do not see 0+ being used in Table 9, so it
can be dropped by now from the table clarification list

7. Section 10 - I suspect the first Note ends after '... As an RFC'. 

8. Section 10, same comment as in Section 3 related to the values of the
Management-Transport-Protection attribute

9. I am wondering if Section 11 should not say something about the
option No-Protection of the Management-Transport-Protection attribute
being NOT RECOMMEDED in any critical configuration, or secure sensible
environment

Regards,

Dan

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: "David B. Nelson" <[email-masked]>
Date: Thu, 4 Sep 2008 13:29:54 -0400

Dan Romascanu writes...

> 'NETCONF(XML over SSH or BEEP or SOAP)'

Sure.  Purely editorial.

> 'better' between (auth, noPriv) and (noAuth, priv).

OK, since the options are limited, maybe an enumeration of what's allowed
and what's not wouldn't be intractable.   For example:

   When a NAS receives a Management-Transport-Protection (TBA-3)
   Attribute in an Access-Accept packet, it MUST deliver the management
   access over a transport with at least the specified protection
   properties.  Additional protection MAY optionally be provided.
   For example, if No-Protection is specified then either Integrity-
   Protection or Integrity-Confidentiality-Protection MAY be provided.
   If Integrity-Protection is specified then Integrity-Confidentiality-
   Protection MAY be provided.  If the minimum protection cannot be
   provided the NAS MUST disconnect the session.
 
> Value in the definition of the Management-Transport-Protection attribute

Based on WG review comments from the IETF-71 meeting and the WGLC, this was
removed.  It was thought that providing confidentiality without integrity
would pose potential security risks.

We would need to see if there is WG consensus to add this back in.

> to allow this at all ever?

It would be good to discuss this.  In the presence of additional
documentation, this practice might be acceptable.  If the only form of
documentation for such procedures that we anticipate having would be another
Standards Track RFC that Updates this one, then MUST NOT would seem
appropriate.  OTOH, if we think there might be an Informational RFC that
suggests a way to handle the precedence, for certain areas of applicability,
then perhaps SHOULD NOT is better.

> It looks to me that RECOMMENDED needs to be capitalized here.

Sure.
 
> can be dropped by now from the table clarification list

It *could* be dropped, but this text had become standard RADIUS
"boilerplate", and my personal preference would be to leave it for
consistency with other RFCs.  I'm open to either approach.

> 7. Section 10 - I suspect the first Note ends after '... As an RFC'.

Yes.  Is there a better way to phrase this?

> Management-Transport-Protection attribute

See above.

> being NOT RECOMMEDED in any critical configuration, or secure sensible

Sure.  I see no objection, unless anyone else sees a problem with that text.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 4 Sep 2008 21:43:16 +0200

> > 'better' between (auth, noPriv) and (noAuth, priv).

SNMP only allows _some_ combinations of authentication and privcay
modes and SNMP in particular does not have (noAuth, priv), see for
example RFC 3411 section 3.4.3. And for the three possible
combinations, I think it is obvious how to define the relation
'better'. Furthermore, if there are two security modes for some
hypothetical protocol where the relation 'better' is undefined, then
the text in the ID I think is still fine. So I do not see any reason
to change something here.

>    provided the NAS MUST disconnect the session.

I believe this text is not needed. However, it points out something
else: the document sometimes talks about authentication and sometimes
it talks about integrity protection. For me, these two things are not
necessarily the same. Is this distinction there for a specific reason
or do we actually mean authentication and integrity protection?

/js 

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 4 Sep 2008 22:42:31 +0200

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Juergen 
> Schoenwaelder
> Sent: Thursday, September 04, 2008 10:43 PM
> To: David B. Nelson
> Cc: [email-masked]
> Subject: Re: AD review of 
> draft-ietf-radext-management-authorization-05.txt
> 
> > > Management-Transport-Protection is or will be always possible. 
> > > Actually we may have a problem already, as SNMP allows any 
> > > combination of authentication and privacy modes, and it 
> is not clear 
> > > which is the 'better' between (auth, noPriv) and (noAuth, priv).
> 
> SNMP only allows _some_ combinations of authentication and 
> privcay modes and SNMP in particular does not have (noAuth, 
> priv), see for example RFC 3411 section 3.4.3. And for the 
> three possible combinations, I think it is obvious how to 
> define the relation 'better'. Furthermore, if there are two 
> security modes for some hypothetical protocol where the 
> relation 'better' is undefined, then the text in the ID I 
> think is still fine. So I do not see any reason to change 
> something here.

Juergen is correct with respect to SNMP, I missed that. Actually the
quoted section in 3411 says 'These three values are ordered such that
noAuthNoPriv is less than authNoPriv and authNoPriv is less than
authPriv'. 

Yet do we assume that this is the finite set of transport-protection for
any protocol in the future, and an hierarchy will always be possible to
define? 

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 4 Sep 2008 23:03:34 +0200

See in-line. Agreement parts removed. 

Dan

> [mailto:[email-masked]] On Behalf Of David B. Nelson
> Sent: Thursday, September 04, 2008 8:30 PM
> To: [email-masked]
> Subject: RE: AD review of 

...

> combination 
> > of authentication and privacy modes, and it is not clear 
> which is the 

I am taking back this comment wrt. SNMP, as per Juergen's clarification.

However Juergen raised the issue of authentication and integrity as
separate protection items. Again, the hierarchy is unclear to me if we
accept this. 

> Based on WG review comments from the IETF-71 meeting and the 
> WGLC, this was removed.  It was thought that providing 
> confidentiality without integrity would pose potential security risks.
> 

My take is that security risks need to be documented, but they are not a
reason for exclusion of a specific state - we do have a No-protection
value after all which is less secure than anything else. The question is
whether an encrypted channel with no authentication or integrity makes
sense. 

> > CoA-Request and no standard precedence algorithm is in place? Any 
> > reason to allow this at all ever?
> 
> It would be good to discuss this.  In the presence of 
> additional documentation, this practice might be acceptable.  
> If the only form of documentation for such procedures that we 
> anticipate having would be another Standards Track RFC that 
> Updates this one, then MUST NOT would seem appropriate.  
> OTOH, if we think there might be an Informational RFC that 
> suggests a way to handle the precedence, for certain areas of 
> applicability, then perhaps SHOULD NOT is better.

If we live the SHOULD NOT I believe that the text should make more clear
that interoperability cannot be guaranteed in the absence of another
specification that handles the precedence algorithms. 

..

> It *could* be dropped, but this text had become standard 
> RADIUS "boilerplate", and my personal preference would be to 
> leave it for consistency with other RFCs.  I'm open to either 
> approach.

OK

> Yes.  Is there a better way to phrase this?

Maybe just place the note between two lines of dashes. 

> 
> > 8. Section 10, same comment as in Section 3 related to the 
> values of 
> > the Management-Transport-Protection attribute
> 
> See above.
> 

...

---

From: "David B. Nelson" <[email-masked]>
Date: Thu, 4 Sep 2008 17:47:10 -0400

Juergen Schoenwaelder writes...

> However, it points out something else: the document sometimes talks
> about authentication and sometimes it talks about integrity protection.

Does it?  The few instances of the word "authentication" in the draft do not
reference the provisioning of protected management services.  RADIUS is all
about authentication and authorization.  However, this draft really only
talks about authorization.

Integrity protection, as used here, is *not* the same as authentication, as
used in SNMP.  Integrity protection requires the sharing of cryptographic
keys, but it does not require authenticated principals.  Integrity
protection could be used, for example, with anonymous Diffie-Hellman key
agreement.  In SNMP the proof of identity of the principals (authentication)
is conflated with tamper-resistance of the protected messages (integrity).
In this document we assume that integrity protection and authentication as
separate concerns.  Authentication is part of the base RADIUS protocol.

In SNMP we have auth and noAuth, as well as priv and noPriv.  There is no
analog to auth or noAuth in this document.  In the ISMS RADIUS Usage
document, we specifically call that out.  Perhaps it would improve that
document to include the text above about separation of authentication from
integrity.

I think we need to be careful not to apply the SNMP model too closely here,
because while SNMP is an important use case, this document is intended to be
more general that just the SNMP usages.

---

From: "David B. Nelson" <[email-masked]>
Date: Thu, 4 Sep 2008 17:50:57 -0400

Dan Romascanu writes...
 
> Yet do we assume that this is the finite set of transport-protection
> for any protocol in the future, and an hierarchy will always be 
> possible to define?

Unless the basic elements of cryptographic messaging change: authentication,
message integrity, message confidentiality, message non-repudiation, etc.,
were to change, I think the answer is yes, this set of protection properties
is expected to be complete.

---

From: "David B. Nelson" <[email-masked]>
Date: Thu, 4 Sep 2008 17:54:57 -0400

Dan Romascanu writes...

> The question is whether an encrypted channel with no authentication
> or integrity makes sense.

The answer from several WG members with expertise in this area was that
encrypted messages without message integrity do not make sense.

Please see my previous message about disambiguating the term
"authentication" as used in RADIUS from the term "authentication" as used in
SNMP.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 5 Sep 2008 08:26:08 +0200

> any protocol in the future, and an hierarchy will always be possible to

My point is that even if there are two transport options A and B where
A 'is better than' B is not defined, the statement in question does
the right thing.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 5 Sep 2008 08:27:54 +0200

> document to include the text above about separation of authentication from

This explanation perfectly makes sense and I am in favour of adding
clarifying text.

/js

---

From: "David B. Nelson" <[email-masked]>
Date: Fri, 5 Sep 2008 07:48:41 -0400

> This explanation perfectly makes sense and I am in favour of adding

OK, great.  I was suggesting that we add that text to the ISMS RADIUS Usage
draft, as that's where SNMP-specific discussion belongs.  Just to clarify,
is that what you are in favor of?  Or do you think it needs to [also] be in
the RADIUS Management Authorization draft?

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 5 Sep 2008 14:04:31 +0200

> the RADIUS Management Authorization draft?

I think a one sentence explanation that authentication is assumed to
be always provided by this all happening in the RADIUS context might
be generally useful where we talk about Management-Transport-Protection.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 5 Sep 2008 14:09:30 +0200

> Sent: Friday, September 05, 2008 12:55 AM
> > The question is whether an encrypted channel with no 
> authentication or 
> > integrity makes sense.
> 
> The answer from several WG members with expertise in this 
> area was that encrypted messages without message integrity do 
> not make sense.
> 
> "authentication" as used in RADIUS from the term 
> "authentication" as used in SNMP.
> 

Yes, I got it now. The clarification proposed in the exchange of
messages between you and Juergen would be fine. 

Dan