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

["Romascanu, Dan (Dan)" <dromasca@avaya.com>]

See in-line. Agreement parts removed. 

Dan
 

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of David B. Nelson
> Sent: Thursday, September 04, 2008 8:30 PM
> To: radiusext@ops.ietf.org
> Subject: RE: AD review of 
> draft-ietf-radext-management-authorization-05.txt
> 
> Dan Romascanu writes...
> 

...

> > 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).
> 
> 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.

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. 

>  
> > 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
> 
> 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.

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. 

> 
> > 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?
> 
> 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. 

..

> > 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
> 
> 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

> 
> > 7. Section 10 - I suspect the first Note ends after '... As an RFC'.
> 
> 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.
> 

...


--
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/>