Subject: RE: [Isms] authoritative

From: "Kaushik Narayan \(kaushik\)" <[email-masked]>
Date: Mon, 3 Oct 2005 16:05:39 -0700

Hi David,

I agree that the notion of authoritative engines have a significant
influence on USM but much lesser bearing on the general SNMP
architecture. Fundamentally it is tied to synchronization of the clock
(engineTime and engineBoots need to be synchronized from the
authoritative engine). There isn't  a need to synchronize clocks at the
SNMP layer with a transport mapped security model.

Also the notion of authoritative is not completely consistent with a
reliable transport, since with notification-type, the authoritative
engine depends on the Class of the message, i.e. agent is authoritative
for SNMP Traps and the Reciever is authoritative for Informs. You might
have the same information being transferred between two SNMP engines via
different messages and have different engines being treated as
authoritative.

Also it creates a tricky issue with any TMSM since for UnConfirmed
Notification-Type messages (Traps), the security model will have no idea
of which endpoint to send the trap (the SNMP engine ID passed down would
identify itself)  

I recommend that we deprecate the notion of authoritative engines for
all transport mapped security models not just SSHSM.

Regards,
  kaushik! 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of David B Harrington
Sent: Monday, October 03, 2005 5:26 AM
To: 'Tom Petch'; [email-masked]; 'David T. Perkins'
Cc: [email-masked]
Subject: RE: [Isms] authoritative

Hi Tom,

You analysis and my analysis are very similar, and we've reached similar
conclusions about how to preserve the ASIs when using SSH.

Unfortunately, many standards are defined capturing the solution, but
not the thinking that led to the solution. So it is unclear what
requirements were being met by having an authoritative engine, and it's
been a long time since those discussions, and my recall of the
requirements is fuzzy.

To the rest of the WG, what are the reasons we need to maintain the
concept of authoritative? Does the authoritative securityEngineID need
to be passed in the message when using SSH or other external security
substrate?

Two proponents of the authoritative engine were Steve Waldbusser and
Jeff Case. I have asked them to join in this discussion, in the hopes
they can recall the requirements in more detail than I.

David Harrington
[email-masked]

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Tom Petch
> Sent: Monday, October 03, 2005 5:46 AM
> To: [email-masked]; 'David T. Perkins'
> Cc: [email-masked]
> Subject: Re: [Isms] authoritative
> 
> I work from the principle that if it is not needed, don't do it:-)
> 
> Authoritative engine id does not appear in the body of VACM [RFC3415] 
> and only appears as a gloss for securityEngineID in ARCH [RFC3411] and

> MPP [RFC3412] so in that sense, the term seems to add nothing and can 
> be dispensed with.
> 
> In MPP, when generatng a message, securityEngineID is taken from 
> snmpEngineID for Response and Internal Class PDU and from the target 
> entity's snmpEngineID for Confimed and Notification Class, which in 
> turn is determined in
an
> implementation dependent manner .
> 
> The only time I see it used is in MPP, on receipt of a Confirmed Class

> PDU, when the securityEngineID must match the snmpEngineID else the 
> message is discarded.
> So it appears to provide an additonal check that the message really 
> got to the intended engine.
> 
> All of which I am sure you know already.
> 
> In the case of SSH, I expect the secure, authenticated tunnel to 
> provide the assurance that the message has been delivered to the 
> intended engine.  To preserve the ASI, the ssh security model could 
> take it from snmpEngineID thereby ensuring the MPP check succeeds.  
> More complicatedly, it could be passed transparently in the security 
> parameters.
> 
> Tom Petch
> 
> ----- Original Message -----
> From: "David B Harrington" <[email-masked]>
> To: "'Tom Petch'" <[email-masked]>; "'David T. Perkins'"
> <[email-masked]>
> Cc: <[email-masked]>
> Sent: Saturday, October 01, 2005 8:59 PM
> Subject: RE: [Isms] authoritative
> 
> 
> > Hi Tom,
> >
> > Can you rephrase this into
> > "Here are the requirements that led to its being part of STD62"
and
> > "Here's why those requirements do not apply to SNMPv3 with SSHSM"?
> >
> > David Harrington
> > [email-masked]
> >
> >
> >
> > > -----Original Message-----
> > > From: Tom Petch [mailto:[email-masked]]
> > > Sent: Saturday, October 01, 2005 6:05 AM
> > > To: David T. Perkins; David B Harrington
> > > Cc: [email-masked]
> > > Subject: Re: [Isms] authoritative
> > >
> > > <inline>
> > > Tom Petch
> > > ----- Original Message -----
> > > From: "David T. Perkins" <[email-masked]>
> > > To: "David B Harrington" <[email-masked]>
> > > Cc: <[email-masked]>
> > > Sent: Saturday, October 01, 2005 9:09 AM
> > > Subject: Re: [Isms] authoritative
> > >
> > >
> > > > We (dbh and I) have gone over this multiple times, and it seems 
> > > > like we still disagree whether or not "authoritative engines" is

> > > > a SNMPv3 concept or a USM concept. I believe it is purely a USM 
> > > > concept and has no requirement to be in other security models.
> > >
> > > Agree absolutely, it is an unnecessary complication; scrap it!
> > >
> >
> >
> 
> 
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/isms
> 

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

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