Clarification of when authentication is used

Jeffrey C Honig <jch@nr-tech.cit.cornell.edu> Tue, 02 August 1994 19:57 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12926; 2 Aug 94 15:57 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12922; 2 Aug 94 15:57 EDT
Received: from atlas.xylogics.com by CNRI.Reston.VA.US id aa15564; 2 Aug 94 15:57 EDT
Received: by atlas.xylogics.com id AA23514 (5.65c/UK-2.1-940401); Tue, 2 Aug 1994 15:56:09 -0400
Received: from MITCHELL.CIT.CORNELL.EDU by atlas.xylogics.com with SMTP id AA24943 (5.65c/UK-2.1-940401); Tue, 2 Aug 1994 15:56:00 -0400
Received: from mitchell.cit.cornell.edu (MITCHELL.CIT.CORNELL.EDU [132.236.200.25]) by mitchell.cit.cornell.edu (8.6.9/8.6.9) with ESMTP id PAA28181 for <ietf-rip@xylogics.com>; Tue, 2 Aug 1994 15:53:13 -0400
Message-Id: <199408021953.PAA28181@mitchell.cit.cornell.edu>
To: ietf-rip@xylogics.com
Subject: Clarification of when authentication is used
Organization: Information Technologies/Network Resources; Cornell University, Ithaca, NY
X-Mailier: MH-E [version 4.1+] MH [version 6.8.1]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 02 Aug 1994 15:53:12 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Jeffrey C Honig <jch@nr-tech.cit.cornell.edu>

My implementation of RIP assumed that both RIP REQUESTs and RESPONSEs
would need to be authenticated.  With the MD5 work it only seems to
make sense to authenticate RESPONSEs.  RFC1388 needs some
clarification of this point as it does not explain when authentication
should be used, just the details of how to use it.


It may make sense to authenticate all RESPONSEs and those REQUESTs
that come from routers (i.e. port 520).  Other REQUESTSs would not
need authentication (it could be ignored) and the RESPONSEs would not
contain authentication.  This would prevent someone from being able to
obtain the simple password, or a sample MD5 authenticated packet, by
sending a REQUEST and then analyzing the RESPONSE.


How much interest is there in having support for two keys to allow
keys to be changed?  To do this as efficiently as possible it would be
desirable to have the authentication entry at the end of the packet
instead of in the begining.


Thanks.

Jeff