[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



 

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Juergen 
> Schoenwaelder
> Sent: Thursday, September 04, 2008 10:43 PM
> To: David B. Nelson
> Cc: radiusext@ops.ietf.org
> Subject: Re: AD review of 
> draft-ietf-radext-management-authorization-05.txt
> 
> On Thu, Sep 04, 2008 at 01:29:54PM -0400, David B. Nelson wrote:
>  
> > > 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).
> 
> 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


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