Re: Re: Urgent - Time synchronization packet - does encryption required

Hi Dave,

If a user say "PrivUser" is configured in the Agent is AuthPriv SecurityLevel user and the TimeSynchronization packet is comes from the manager is with following details,

  i)   Agent authoritative EngineID.
  ii)  UserName is "PrivUser" i.e the correct userName.
  iii) EngineTime and EngineBoot value is zero.
  with AuthNoPriv security level i.e PDU is not encrypted .

 In this case,  how the PDU is processed whether it is dropped or not.

 As per RFC3414, 3.2 Processing of Incoming PDU section (5), will be applicable or not. It means that the PDU is dropped because of the unsupported security Level.

 Please clarify me as, the unSupportted SecurityLevel will be issued incase if the user is configured in the Agent is authNoPriv security level but the PDU comes from the manager is AuthPriv SecurityLevel for the same user.

Look forward your response.

Cheers
Ravikumar

  Ho

-- Dave Shield wrote : 
On 22/11/2007, Devirani R R <deviranir@adve...> wrote:
> Could you please clarify whether the 'Time Synchronization' packet
> should be encrypted or not. What should be the security level.

It probably doesn't matter.
The expectation of the Time Synchronization step is that the request
will fail (with notInTimeWindow - see section 3.2. 7a), before the
processing gets as far as decrypting the core PDU (3.2, 8a)


> My understanding is that the 'Time Synchronization' packet requires
> only authentication and not encryption.

It *requires* authentication, otherwise the time window calculations will
be skipped.   It *allows* encryption, but doesn't require it.

The advantage of sending an encrypted request at this stage is that if
you happen to provide a valid engineTime/Boots pair, then the remote
agent can actually process the enclosed request, and return the
required information immediately.   Similarly for the initial engineID probe.

By sending the real request as the probe, then the best case scenario
is one request/response transaction.   Worst case is three, just as in
the RFC3414 Elements of Procedure.

Dave

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Net-snmp-users mailing list
Net-snmp-users@list...
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users


--
This message was sent on behalf of [email protected] at openSubscriber.com
http://www.opensubscriber.com/message/[email protected]/8044049.html

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users