From kent@BBN.COM Fri May 7 22:12:39 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA01786 (5.65c/IDA-1.4.4 for ); Fri, 7 May 1993 18:14:51 -0400 Received: from CCV1.BBN.COM by interlock.ans.net with SMTP id AA07614 (InterLock SMTP Gateway 1.1 for ); Fri, 7 May 1993 18:11:53 -0400 Message-Id: <199305072211.AA07614@interlock.ans.net> To: dee@skidrow.ljo.dec.com Cc: Hilarie Orman , namedroppers@nic.ddn.mil, ipsec@ans.net Subject: Re: DNS Security In-Reply-To: Your message of Fri, 09 Apr 93 13:55:40 -0400. <9304091755.AA01477@skidrow.ljo.dec.com> Date: Fri, 07 May 93 18:12:39 -0400 From: Steve Kent Hilarie makes a good point with regard to DNS; Donald's argument about providing security at the application layer vs. a lower layer is a traditional one that has yet to be resolved. Directory services can have security requirements that make them poor candidates for lower layer security protocols. For example, if I send a requuest to a local directory server and it forwards that request to another server, only an authentication facility at the application layer can provide source-to-desitination authentication of the request and the response. Steve From atkinson@itd.nrl.navy.mil Fri May 7 15:52:35 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA01507 (5.65c/IDA-1.4.4 for ); Fri, 7 May 1993 19:53:47 -0400 Received: from itd.nrl.navy.mil by interlock.ans.net with SMTP id AA34887 (InterLock SMTP Gateway 1.1 for ); Fri, 7 May 1993 19:51:46 -0400 Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA21840; Fri, 7 May 93 19:52:35 EDT Date: Fri, 7 May 93 19:52:35 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9305072352.AA21840@itd.nrl.navy.mil> To: , Kent@itd.nrl.navy.mil, Steve@itd.nrl.navy.mil Subject: Re: DNS Security Cc: , Steve, If instead of forwarding the DNS request, the local directory server were to issue a "DNS redirect", then I think one can get by without application layer security and might be just fine with lower layer security. Such a redirect might be cached at the requestor and there might be some small reduction in load on the local server if this were to be done. So the "DNS redirect" concept might be worth exploring. As you say, placement of security mechanisms is a traditional subject for debate. My own general philosophy on this is to try to mostly keep security below the networking programming interface (e.g. sockets) in order to avoid having to rewrite all of my applications. I accept that email/ messaging is an exception to this general philosophy. DNS might also be an exception to this, but that isn't clear to me at this time. As long as I'm wading towards the swamp, I'll go ahead and note that the local consensus is that generic user-to-user security should be implemented at the transport layer or between the transport layer and the API. The commonly used APIs (sockets and XTI/TLI) offer transport layer interfaces. We strongly desire MLS properties (not everyone thinks they need MLS) and so we need full user-to-user separation/ protection rather than just system-to-system separation/protection. The network layer gives us system-to-system but not user-to-user. Transport layer and above provide user-to-user, but above the API we would incur the costs of rewriting all of our applications. Recent work at NRL indicates that our network security approach also helps partition the problems into pieces that can be tackled with existing formal methods technology. We think that MLS networks really need B3/A1 assurance, so the ability to apply formal methods to critical components is very important to us. Not all of this last paragraph might be applicable to the IETF since the IETF isn't particularly trying to work on MLS networking. Regards, Ran atkinson@itd.nrl.navy.mil From kent@BBN.COM Mon May 10 14:01:31 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA10875 (5.65c/IDA-1.4.4 for ); Mon, 10 May 1993 10:05:16 -0400 Received: from CCV1.BBN.COM by interlock.ans.net with SMTP id AA30085 (InterLock SMTP Gateway 1.1 for ); Mon, 10 May 1993 10:00:49 -0400 Message-Id: <199305101400.AA30085@interlock.ans.net> To: Ran Atkinson Cc: kent@BBN.COM, Kent@itd.nrl.navy.mil, Steve@itd.nrl.navy.mil, ipsec@ans.net, namedroppers@nic.ddn.mil Subject: Re: DNS Security In-Reply-To: Your message of Fri, 07 May 93 19:52:35 -0400. <9305072352.AA21840@itd.nrl.navy.mil> Date: Mon, 10 May 93 10:01:31 -0400 From: Steve Kent Ran, If one were to limit directory interaction to referrals rather than chaining (to use X.500 terminology), then the particular example I cited would not require application layer security. However, I think there are other examples in this application where application layer security is required (strongly encouraged?), but I'll have to think a bit before giving a good example. As you note, arguments about where to provide security services in a protocol stack are fodder for long running debates. The argument you made about transport layer security for MLS applications is one that has been made before. I'll repeat the counterargument, for those who may not be familair with the debate. If one has an MLS host and wishes to provide security on a per-process basis, then it is feasible to trust the host to keep the processes connections separate after demuxing for security level at layer 3. This is not a conclusive argument, just another data point in the debate. Steve From smb@research.att.com Mon May 10 06:29:46 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07224 (5.65c/IDA-1.4.4 for ); Mon, 10 May 1993 10:33:28 -0400 Received: from research.att.com by interlock.ans.net with SMTP id AA30020 (InterLock SMTP Gateway 1.1 for ); Mon, 10 May 1993 10:31:31 -0400 Message-Id: <199305101431.AA30020@interlock.ans.net> From: smb@research.att.com Received: by bigbird.zoo.att.com; Mon May 10 10:29:49 EDT 1993 To: Steve Kent Cc: Ran Atkinson , Kent@itd.nrl.navy.mil, Steve@itd.nrl.navy.mil, ipsec@ans.net, namedroppers@nic.ddn.mil Subject: Re: DNS Security Date: Mon, 10 May 93 10:29:46 EDT Ran, If one were to limit directory interaction to referrals rather than chaining (to use X.500 terminology), then the particular example I cited would not require application layer security. However, I think there are other examples in this application where application layer security is required (strongly encouraged?), but I'll have to think a bit before giving a good example. A name server needs application-level security to assure that it is truly entitled to speak for a given set of names. Consider something like the DNS. I want to know that a given host X is really the server for the foo.com domain, a decision that is left up to the .com server. All network-level security tells me is that the response I get is really from X -- but I'm not questioning that here; I simply want to know if I can trust X in this context. Put another way, network-level security provides identification and authentication, but not authorization. Any network-wide application the requires the latter requires application-level security features. Note that that phrase runs the gamut from certificates to .rhosts files -- but both of those are application-specific constructs. From huitema@mitsou.inria.fr Mon May 10 15:31:37 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06802 (5.65c/IDA-1.4.4 for ); Mon, 10 May 1993 11:29:59 -0400 Received: from mitsou.inria.fr by interlock.ans.net with SMTP id AA03765 (InterLock SMTP Gateway 1.1 for ); Mon, 10 May 1993 11:27:52 -0400 Received: by mitsou.inria.fr (5.65c/IDA-1.2.8) id AA09574; Mon, 10 May 1993 17:31:39 +0200 Message-Id: <199305101531.AA09574@mitsou.inria.fr> To: Steve Kent Cc: Ran Atkinson , Kent@itd.nrl.navy.mil, Steve@itd.nrl.navy.mil, ipsec@ans.net, namedroppers@nic.ddn.mil Subject: Re: DNS Security In-Reply-To: Your message of "Mon, 10 May 93 10:01:31 EDT." <9305101401.AA26738@nic.ddn.mil> Date: Mon, 10 May 93 17:31:37 +0200 From: Christian Huitema Steve, One can in fact apply the "end to end argument" here. As the source of the data is not the DNS but some user admin, then the records of a secure DNS should be signed by this admin, not the DNS server. This is exactly what is done for "certificates"... Christian Huitema From kent@BBN.COM Mon May 10 18:52:14 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA09666 (5.65c/IDA-1.4.4 for ); Mon, 10 May 1993 16:33:41 -0400 Received: from CCV1.BBN.COM by interlock.ans.net with SMTP id AA29408 (InterLock SMTP Gateway 1.1 for ); Mon, 10 May 1993 16:30:57 -0400 Message-Id: <199305102030.AA29408@interlock.ans.net> To: Christian Huitema Cc: Steve Kent , Ran Atkinson , ipsec@ans.net, namedroppers@nic.ddn.mil Subject: Re: DNS Security In-Reply-To: Your message of Mon, 10 May 93 17:31:37 +0200. <199305101531.AA09574@mitsou.inria.fr> Date: Mon, 10 May 93 14:52:14 -0400 From: Steve Kent I think that Christian and Steve Bellovin have both provided reasonable examples of why application-specific security facilities can be more useful for the DNS/directory application (as compared to lower layer, more generic security facilities). Steve