[AFS3-std] DNS SRV Resource Records for AFS

[Russ Allbery]

Jeffrey Altman <jaltman@secure-endpoints.com> writes:

> The URL for this draft is
> http://www.ietf.org/id/draft-allbery-afs-srv-records-00.txt

Thanks, sorry.  Should have included that.

> The only change I would make is to the security considerations section.
> Remove the reference to Kerberos as any authentication/privacy method
> supported by an Rx security class is sufficient to remove the
> vulnerability.

On the principle of finding more things as soon as one actually publishes
a document, there are a few other fixes I have already accumulated.  So
that people know what's pending, here's the current diff.  I'll give
people a chance to comment before submitting a -01 version.

Index: srv-records.xml
===================================================================
--- srv-records.xml	(revision 6186)
+++ srv-records.xml	(working copy)
@@ -67,7 +67,7 @@
       in which that file is located, and then contacts that file server
       directly to access the file.  A client may also need to contact a
       PTS server for that cell to register before accessing files in that
-      cell.</t>
+      cell or to query protection database information.</t>
 
       <t>An AFS client therefore needs to determine, for a given AFS cell,
       the VLDB and possibly the PTS servers for that cell.
@@ -201,7 +201,7 @@
       <t>Several AFS implementations use a weighted algorithm that assigns
       numbers to each server when the client first contacts that AFS cell
       and then prefers the server with the lowest weight unless that
-      server goes down.  Clients using this algorithm should assign their
+      server goes down.  Clients using this algorithm SHOULD assign their
       weights as follows:
         <list style="numbers">
           <t>Sort targets by priority and assign a base weight to each
@@ -255,9 +255,9 @@
       servers on non-standard ports.</t>
 
       <t>Clients SHOULD query DNS SRV RRs by default but SHOULD then fall
-      back on AFSDB RRs if no DNS SRV RRs are found.  All servers listed
-      in an AFSDB RR of &lt;subtype> 1 SHOULD be treated as equivalent to
-      the following pair of DNS SRV RRs:</t>
+      back on AFSDB RRs if no DNS SRV RRs are found.  In the absence of
+      DNS SRV RRs, an AFSDB RR of &lt;subtype> 1 SHOULD be treated as
+      equivalent to the following pair of DNS SRV RRs:</t>
 
       <figure>
         <artwork>
@@ -339,10 +339,9 @@
       compromise the security of the client and trick it into taking
       actions under the attacker's control.</t>
 
-      <t>This attack can be ameliorated if the client is authenticated
-      using the Kerberos-based authentication provided by the AFS
-      protocol, since the client can then detect a failure to authenticate
-      to the attacker's servers and thereby detect possible impersonation.
+      <t>This attack can be ameliorated if the client is authenticated,
+      since the client can then detect a failure to authenticate to the
+      attacker's servers and thereby detect possible impersonation.
       However, this applies only to authenticated AFS access, and much AFS
       access is unauthenticated.  Furthermore, clients after failure to
       authenticate may fall back to unauthenticated access, which the

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>