home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_q_t / draft-ietf-roamops-dnsrr-01.txt < prev    next >
Text File  |  1997-03-03  |  42KB  |  988 lines
  1.  
  2.  
  3.  
  4.      ROAMOPS Working Group                                    Bernard Aboba
  5.      INTERNET-DRAFT                                   Microsoft Corporation
  6.      <draft-ietf-roamops-dnsrr-01.txt >
  7.      1 March 1997
  8.  
  9.  
  10.                 The Roaming Relationship (RR) Record in the DNS
  11.  
  12.  
  13.      1.  Status of this Memo
  14.  
  15.      This document is an Internet-Draft.  Internet-Drafts are working docu-
  16.      ments of the Internet Engineering Task Force (IETF),  its  areas,  and
  17.      its  working groups.  Note that other groups may also distribute work-
  18.      ing documents as Internet-Drafts.
  19.  
  20.      Internet-Drafts are draft documents valid for a maximum of six  months
  21.      and  may  be updated, replaced, or obsoleted by other documents at any
  22.      time.  It is inappropriate to use Internet-Drafts as  reference  mate-
  23.      rial or to cite them other than as ``work in progress.''
  24.  
  25.      To  learn  the  current status of any Internet-Draft, please check the
  26.      ``1id-abstracts.txt'' listing contained in the Internet-Drafts  Shadow
  27.      Directories   on   ds.internic.net   (US  East  Coast),  nic.nordu.net
  28.      (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
  29.  
  30.      The  distribution  of  this memo is unlimited.  It is filed as <draft-
  31.      ietf-roamops-dnsrr-01.txt>, and  expires September  1,  1997.   Please
  32.      send comments to the authors.
  33.  
  34.  
  35.      2.  Abstract
  36.  
  37.      This  document  describes  the  use  of  the Roaming Relationship (RR)
  38.      record in the DNS for the description of roaming relationships. In the
  39.      absence  of  DNS  security, RR records may be used for determining the
  40.      existence of a roaming relationship path between the local ISP and the
  41.      user's home domain, as well as the location of an appropriate account-
  42.      ing agent. However, since the RR records are not secured, other  meth-
  43.      ods  (such  as  hierarchical  authentication  routing) must be used in
  44.      order to validate the roaming relationship path. When DNS security  is
  45.      implemented,  the roaming relationship path is authenticated via digi-
  46.      tal signatures, and as a result, additional services may be  provided,
  47.      such as non-repudiation of proxied authentications and signed receipts
  48.      for accounting record transfers.
  49.  
  50.  
  51.      3.  Introduction
  52.  
  53.      Considerable interest has arisen recently in a set  of  features  that
  54.      fit  within  the  general  category of "roaming capability" for dialup
  55.      Internet users.  Interested parties have included:
  56.  
  57.           Regional Internet Service Providers  (ISPs)  operating  within  a
  58.  
  59.  
  60.  
  61.      Aboba                                                         [Page 1]
  62.  
  63.  
  64.  
  65.  
  66.  
  67.      INTERNET-DRAFT                                            1 March 1997
  68.  
  69.  
  70.           particular  state  or  province, looking to combine their efforts
  71.           with those of other regional providers to  offer  dialup  service
  72.           over a wider area.
  73.  
  74.           National  ISPs  wishing to combine their operations with those of
  75.           one or more ISPs in another nation to  offer  more  comprehensive
  76.           dialup service in a group of countries or on a continent.
  77.  
  78.           Businesses  desiring  to  offer  their  employees a comprehensive
  79.           package of dialup services on a global basis.  Those services may
  80.           include  Internet  access  as  well as secure access to corporate
  81.           intranets via a Virtual Private Network (VPN), enabled by tunnel-
  82.           ing protocols such as PPTP, L2F, or L2TP.
  83.  
  84.      This  document  describes  the  use  of  the Roaming Relationship (RR)
  85.      record in the DNS for the description of  inter-domain  roaming  rela-
  86.      tionships,  as  required  for  enabling  of  roaming  and other inter-
  87.      provider services. In the absence of DNS security, RR records  may  be
  88.      used  for  determining the existence of a roaming relationship between
  89.      the local ISP and the user's home domain, as well as the  location  of
  90.      an appropriate accounting agent. However, since the RR records are not
  91.      secured, other methods (such as hierarchical  authentication  routing)
  92.      must  be used in order to validate the roaming relationship path. When
  93.      DNS security is implemented as described in [13],  the  roaming  rela-
  94.      tionship  path  is  authenticated  via  digital  signatures,  and as a
  95.      result, additional services may be provided, such  as  non-repudiation
  96.      of  proxied  authentications and signed receipts for accounting record
  97.      transfers. The latter capability is  described  in  references  [5]  -
  98.      [11].
  99.  
  100.  
  101.      3.1.  Terminology
  102.  
  103.      This document frequently uses the following terms:
  104.  
  105.      roaming relationship path
  106.                The roaming relationship path is the series of roaming rela-
  107.                tionships that link together a local  ISP  and  user's  home
  108.                domain.  The roaming relationship path may or may not be the
  109.                same as the authentication route, depending on  whether  the
  110.                local proxy is able to directly contact the home authentica-
  111.                tion server.
  112.  
  113.      authentication route
  114.                The route that an  authentication  will  take  in  traveling
  115.                between  the  local  ISP's authentication proxy and the home
  116.                authentication server. Where RADIUS proxy authentication  is
  117.                used, the authentication route follows the roaming relation-
  118.                ship path.
  119.  
  120.      Network Access Server
  121.                The Network Access Server (NAS) is the device  that  clients
  122.                dial in order to get access to the network.
  123.  
  124.  
  125.  
  126.  
  127.      Aboba                                                         [Page 2]
  128.  
  129.  
  130.  
  131.  
  132.  
  133.      INTERNET-DRAFT                                            1 March 1997
  134.  
  135.  
  136.      RADIUS server
  137.                This  is  a  server which provides for authentication/autho-
  138.                rization via the protocol described in [3], and for account-
  139.                ing as described in [4].
  140.  
  141.      RADIUS proxy
  142.                In order to provide for the routing of RADIUS authentication
  143.                and accounting requests, a RADIUS proxy may employed. To the
  144.                NAS, the RADIUS proxy appears to act as a RADIUS server, and
  145.                to the RADIUS server, the proxy appears to act as  a  RADIUS
  146.                client.
  147.  
  148.      RADIUS domain
  149.                In order to provide for the routing of RADIUS authentication
  150.                and accounting requests, the userID field used in PPP and in
  151.                the   subsequent   RADIUS   authentication   and  accounting
  152.                requests, may contain structure. This structure  provides  a
  153.                means  by  which  the  RADIUS  proxy  will locate the RADIUS
  154.                server that is to receive the request.
  155.  
  156.  
  157.      3.2.  Requirements language
  158.  
  159.      This specification uses the same words as [14] for defining  the  sig-
  160.      nificance of each particular requirement.  These words are:
  161.  
  162.  
  163.      MUST      This  word,  or  the adjectives "REQUIRED" or "SHALL", means
  164.                that the definition is an absolute requirement of the speci-
  165.                fication.
  166.  
  167.      MUST NOT  This phrase, or the phrase "SHALL NOT", means that the defi-
  168.                nition is an absolute prohibition of the specification.
  169.  
  170.      SHOULD    This word, or the adjective "RECOMMENDED", means that  there
  171.                may  exist  valid  reasons  in  particular  circumstances to
  172.                ignore a particular item, but the full implications must  be
  173.                understood and carefully weighed before choosing a different
  174.                course.
  175.  
  176.      SHOULD NOT
  177.                This phrase means that there may exist valid reasons in par-
  178.                ticular   circumstances  when  the  particular  behavior  is
  179.                acceptable or even useful, but the full implications  should
  180.                be  understood  and the case carefully weighed before imple-
  181.                menting any behavior described with this label.
  182.  
  183.      MAY       This word, or the adjective "OPTIONAL", means that  an  item
  184.                is  truly  optional.   One  vendor may choose to include the
  185.                item because a particular marketplace requires it or because
  186.                the  vendor feels that it enhances the product while another
  187.                vendor may omit the same item.  An implementation which does
  188.                not include a particular option MUST be prepared to interop-
  189.                erate with another implementation  which  does  include  the
  190.  
  191.  
  192.  
  193.      Aboba                                                         [Page 3]
  194.  
  195.  
  196.  
  197.  
  198.  
  199.      INTERNET-DRAFT                                            1 March 1997
  200.  
  201.  
  202.                option,  though  perhaps  with reduced functionality. In the
  203.                same vein an implementation which does include a  particular
  204.                option  MUST be prepared to interoperate with another imple-
  205.                mentation which does  not  include  the  option.(except,  of
  206.                course, for the feature the option provides)
  207.  
  208.      An  implementation is not compliant if it fails to satisfy one or more
  209.      of the must or must not requirements for the protocols it  implements.
  210.      An  implementation  that  satisfies all the must, must not, should and
  211.      should not requirements for its protocols is said to be  "uncondition-
  212.      ally compliant"; one that satisfies all the must and must not require-
  213.      ments but not all the should or should not requirements for its proto-
  214.      cols is said to be "conditionally compliant."
  215.  
  216.  
  217.      4.  The Roaming Relationship (RR) Record
  218.  
  219.      In order to enable roaming, it is necessary for a local provider to be
  220.      able to determine whether a roaming relationship path  exists  between
  221.      itself  and the user's home domain, so as to enable the local provider
  222.      to be paid for the use of its resources. These  roaming  relationships
  223.      are  typically  of  two  types:  the relationship between a firm and a
  224.      provider, in  which  the  firm  delegates  roaming  authority  to  the
  225.      provider; or the relationship between a provider and a roaming associ-
  226.      ation, in which the provider agrees to allow members of the consortium
  227.      to  access  its  network resources, in exchange for compensation. How-
  228.      ever, it is also possible for a company or even an individual to  form
  229.      a  direct  relationship  with a roaming consortia, or for consortia to
  230.      form a relationship with another consortia.
  231.  
  232.      Inter-domain roaming relationships may extend to several  levels.  For
  233.      example, BIGCO may delegate roaming authority to ISPA, who may in turn
  234.      join roaming association ISPGROUP.  When  Fred  dials  into  ISPB  and
  235.      attempts  to  authenticate as fred@bigco.com, it is necessary for ISPB
  236.      to determine whether it has a means for being paid for  the  resources
  237.      consumed  by  Fred. This is accomplished by tracing the web of roaming
  238.      relationships backwards from the bigco.com domain, in order to  deter-
  239.      mine  whether  a path of roaming relationships exists between ISPB and
  240.      BIGCO.
  241.  
  242.      Please note that the task of determining the path of roaming relation-
  243.      ships  is  orthogonal  to  the  issue of authentication routing. Where
  244.      authentication proxy  chaining  is  used,  authentication  routing  is
  245.      required  in  order  to  improve scalability. However, when public key
  246.      authentication is available, it  is  possible  for  an  authentication
  247.      proxy  to  directly  contact  a  home authentication server.  However,
  248.      regardless of how the authentication is routed, it is still  necessary
  249.      for  the  local  ISP to determine the path of roaming relationships so
  250.      that it can determine whether it can be paid for the transaction.
  251.  
  252.      The purpose of the Roaming Relationship (RR)  record  is  to  document
  253.      inter-domain  roaming relationships. Where DNS Security is enabled, it
  254.      is possible for these relationships to be authenticated via use of the
  255.      KEY  and  SIG RRs. In order to authenticate the existence of a roaming
  256.  
  257.  
  258.  
  259.      Aboba                                                         [Page 4]
  260.  
  261.  
  262.  
  263.  
  264.  
  265.      INTERNET-DRAFT                                            1 March 1997
  266.  
  267.  
  268.      relationship, the domain to which roaming authority has been delegated
  269.      signs the KEY RR of the domain which has done the delegation. The sig-
  270.      nature includes an expiration date, as well as the KEY RR itself,  and
  271.      it  is  expected  that  the  expiration dates SHOULD NOT be far in the
  272.      future. As a result, it is expected that the  roaming  authority  will
  273.      update  the SIG RR periodically in order to enable the relationship to
  274.      continue.
  275.  
  276.      Please note that Roaming Relationship (RR) records may be retrieved in
  277.      a  variety  of ways. When hierarchical authentication routing is being
  278.      used, RR records are typically retrieved by the local ISP's  authenti-
  279.      cation  proxy,  and used both for the determination of a roaming rela-
  280.      tionship, and for use in  authentication  routing.   When  public  key
  281.      authentication,  IPSEC and DNS security are available, then it is pos-
  282.      sible for the local ISP's authentication proxy  to  contact  the  home
  283.      domain's  authentication  server  directly. In this case, hierarchical
  284.      authentication routing is not necessary, and it is  possible  for  the
  285.      home domain's authentication server to return signed Roaming Relation-
  286.      ship resource records to  the  local  ISP's  authentication  proxy  as
  287.      attributes  within the authentication reply. If this is done, then the
  288.      local ISP's authentication proxy may not need to look up  any  Roaming
  289.      Relationship  resource records itself, and as a result, the total time
  290.      required for the authentication will be decreased.  This  will  lessen
  291.      the probability of a timeout.
  292.  
  293.  
  294.      4.1.  Roaming Relationship resource record RDATA format
  295.  
  296.      The RDATA for a Roaming Relationship resource record is as follows:
  297.  
  298.      0                   1                   2                   3
  299.      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
  300.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  301.      |              Preference       |              Flags            |
  302.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  303.      /                                                               /
  304.      /                            Domain                             /
  305.      /                                                               /
  306.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  307.  
  308.  
  309.      4.1.1.  Preference
  310.  
  311.      The  Preference  field,  which is two octets, specifies the preference
  312.      given to this record versus other records of the same type and  owner.
  313.      Lower values are preferred.
  314.  
  315.  
  316.      4.1.2.  Flags
  317.  
  318.      The flags field, which is two octets, is as follows:
  319.      0                   1
  320.      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
  321.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  322.  
  323.  
  324.  
  325.      Aboba                                                         [Page 5]
  326.  
  327.  
  328.  
  329.  
  330.  
  331.      INTERNET-DRAFT                                            1 March 1997
  332.  
  333.  
  334.      |U P C S I F H R R R R R R R R R|
  335.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  336.  
  337.      U  =  User. If U=1, then the Roaming Relationship record represents an
  338.      individual user or account. The user name is represented the same  way
  339.      as in the SOA or RP resource records. As a result, fred@bigco.com will
  340.      be represented as fred.bigco.com. Since the DNS was not  intended  for
  341.      use as a user database, it is expected that this flag will only be set
  342.      on rare occasions.
  343.  
  344.      P = Provider. If P=1, then the Roaming Relationship record  represents
  345.      delegation  of roaming authority from a non-ISP to an ISP or a roaming
  346.      consortia.
  347.  
  348.      C = Consortia. If C=1, then the Roaming Relationship record represents
  349.      delegation of roaming authority from an ISP to a roaming consortia.
  350.  
  351.      S  =  Accounting  agent. If S=1, then a accounting agent exists within
  352.      the domain.
  353.  
  354.      I = Internet access. If I=1, then the Roaming Relationship record  may
  355.      be  used  for provisioning of Internet access. In roaming applications
  356.      this bit MUST be set.
  357.  
  358.      F = Fax. If F=1, then the Roaming Relationship record may be used  for
  359.      provisioning of Internet fax.
  360.  
  361.      H  = H.323. If H=1, then the Roaming Relationship may be used for pro-
  362.      visioning of H.323 conferencing.
  363.  
  364.      R = Reserved.
  365.  
  366.  
  367.      4.1.3.  Domain
  368.  
  369.      The domain field represents the domain name to which roaming authority
  370.      has been delegated by the owner name.
  371.  
  372.  
  373.      4.2.  Use of the Roaming Relationship (RR) Record
  374.  
  375.      The Roaming Relationship (RR) record uses semantics similar to that of
  376.      the Mail Exchange (MX) record, in that it includes a priority as  well
  377.      as  the  domain  to which roaming authority has been delegated. The RR
  378.      record is of the form:
  379.  
  380.      bigco.com.  IN RR
  381.                     10          ;priority
  382.                     P I         ;flags. P = Provider, I = Internet Access
  383.                     ispa.com.   ;domain with roaming authority
  384.  
  385.      Here 10 refers to the priority of the RR record, and ispa.com  is  the
  386.      domain  to which BIGCO has delegated roaming responsibilities. The use
  387.      of a priority field allows multiple relationships to  be  represented,
  388.  
  389.  
  390.  
  391.      Aboba                                                         [Page 6]
  392.  
  393.  
  394.  
  395.  
  396.  
  397.      INTERNET-DRAFT                                            1 March 1997
  398.  
  399.  
  400.      with authenticating ISPs checking the relationships in ascending order
  401.      of priority. Thus, an RR record of priority 10 would be checked before
  402.      a record of priority 20. As described in the previous section, letters
  403.      are used to denote flag bits.
  404.  
  405.      Routes for a given domain SHOULD be given different priorities, so  as
  406.      to  allow  for predictable behavior. Since routes at the same priority
  407.      will be round-robined, this will  result  in  alternation  of  routes.
  408.      Unless  there  is  a good reason for balancing the load this way, this
  409.      approach SHOULD NOT be used.
  410.  
  411.  
  412.      5.  Examples
  413.  
  414.  
  415.      5.1.  Example One
  416.  
  417.      Let us assume that Fred is an employee of BIGCO, who  has  established
  418.      roaming relationships with ISPA and ISPC, both of which are members of
  419.      roaming consortia ISPGROUP1. BIGCO also has a relationship with clear-
  420.      ing  houses ISPGROUP2 and ISPGROUP3. ISPB is a member of the ISPGROUP1
  421.      roaming consortia.
  422.  
  423.      The Roaming Relationship records for BIGCO appear as follows:
  424.  
  425.      bigco.com. IN RR 10 P I ispa.com.
  426.      bigco.com. IN RR 20 P I ispc.com.
  427.      bigco.com. IN RR 30 P I ispgroup3.com.
  428.      bigco.com. IN RR 40 P I ispgroup2.com.
  429.  
  430.      The RR records for ISPA, ISPB, ISPC,  ISPGROUP1,  ISPGROUP2  and  ISP-
  431.      GROUP3 appear as follows:
  432.  
  433.      ispa.com. IN RR 10 C I ispgroup1.com.
  434.  
  435.      ispb.com. IN RR 10 C I ispgroup1.com.
  436.  
  437.      ispc.com. IN RR 10 C I ispgroup1.com.
  438.  
  439.      ispgroup1.com. IN RR 10 C I S ispgroup1.com.
  440.  
  441.      ispgroup2.com. IN RR 10 C I S ispgroup2.com.
  442.  
  443.      ispgroup3.com. IN RR 10 C I S ispgroup3.com.
  444.  
  445.  
  446.      5.1.1.  Sequence of events
  447.  
  448.      Fred  logs into ISPB as fred@bigco.com; as a result the ISPB authenti-
  449.      cation proxy receives this  NAI.  ISPB's  authentication  proxy  first
  450.      checks  for  the  presence of a user record for fred.bigco.com. If so,
  451.      then it retrieves the RR resource records for the domain to whom  Fred
  452.      has  delegated  roaming authority. If there is no user record, then it
  453.      checks its configuration files to see whether bigco.com is one of  the
  454.  
  455.  
  456.  
  457.      Aboba                                                         [Page 7]
  458.  
  459.  
  460.  
  461.  
  462.  
  463.      INTERNET-DRAFT                                            1 March 1997
  464.  
  465.  
  466.      domains  with  whom  it  has a direct roaming relationship. This check
  467.      will fail since BIGCO has no direct roaming relationship with ISPB. As
  468.      a  result,  ISPB's authentication proxy will need to retrieve resource
  469.      records either from its own cache or from the bigco.com zone.
  470.  
  471.      Assuming that ISPB's authentication proxy does not support public  key
  472.      authentication  and  IPSEC,  then  hierarchical authentication routing
  473.      will be used. In this case, ISPB's authentication proxy will  need  to
  474.      retrieve  RR  resource  records  from  the  bigco.com zone.  If ISPB's
  475.      authentication proxy supports public  key  authentication  and  ISPEC,
  476.      then  rather  than immediately retrieving RR resource records, it will
  477.      retrieve the SRV, KEY and SIG resource records for the bigco.com zone.
  478.      Using  the SRV resource record, ISPB's authentication proxy can locate
  479.      the authentication proxy for the bigco.com domain.  The  SIG  resource
  480.      records  for  the  bigco.com  zone  can  then be retrieved in order to
  481.      determine whether the bigco.com authentication server supports  IPSEC.
  482.      If  so,  then  ISPB's  authentication  proxy may contact the bigco.com
  483.      authentication server directly. In this case, only the IPSEC AH header
  484.      need  be used, since only authentication services are required. In its
  485.      authentication reply, the bigco.com authentication server  may  return
  486.      the  RR records for its zone as well as those of the zones to which it
  487.      has delegated roaming authority, in the form of attributes within  the
  488.      Access-Reply.  If  so,  then ISPB's authentication proxy will be saved
  489.      the work of having to retrieve these resource records itself prior  to
  490.      forwarding the authentication reply on to the NAS.
  491.  
  492.      Once  the  RR resource records have been retrieved by one mechanism or
  493.      another, a depth first search is performed  in  order  to  select  the
  494.      roaming  relationship  path.  In this case, ISPB determines whether it
  495.      has a direct roaming relationship with ISPA (priority 10  record  from
  496.      the  bigco.com  zone). If not, then it looks at the RR records for the
  497.      ispa.com domain, and determines whether it has a direct roaming  rela-
  498.      tionship  with  any  of the domains to whom ISPA has delegated roaming
  499.      responsibility. In this case, ISPB determines that  it  has  a  direct
  500.      roaming  relationship  with  ISPGROUP1  (priority  10  record from the
  501.      ispa.com  zone).  As  a  result,   the   roaming   relationship   path
  502.      bigco.com/ispa.com/ispgroup1.com/ispb.com is selected. Since ISPGROUP1
  503.      operates a accounting agent within its domain, accounting records  for
  504.      the transaction will be sent to ISPGROUP1's accounting agent.
  505.  
  506.      If ISPA had not been a member of the ISPGROUP1 roaming consortia, then
  507.      the depth-first search would have terminated, and ISPB  would  proceed
  508.      to  check for a business relationship on the branch represented by the
  509.      priority 20 record in the bigco.com zone (ispc.com). In this case  the
  510.      roaming  relationship  path  bigco.com/ispc.com/ispgroup1.com/ispb.com
  511.      would have been selected.
  512.  
  513.      If ISPB were a member of the ISPGROUP3 roaming consortia,  and  not  a
  514.      member of the ISPGROUP1 or ISPGROUP2 consortia, then the breadth-first
  515.      search would fail on both the priority  10  and  20  branches  of  the
  516.      bigco.com   tree.   In  this  case,  the  business  relationship  path
  517.      bigco.com/ispgroup3.com/ispb.com would have been selected.
  518.  
  519.  
  520.  
  521.  
  522.  
  523.      Aboba                                                         [Page 8]
  524.  
  525.  
  526.  
  527.  
  528.  
  529.      INTERNET-DRAFT                                            1 March 1997
  530.  
  531.  
  532.      5.2.  Example Two
  533.  
  534.      Let us assume that BIGCO has branch offices in multiple locations. The
  535.      BIGCO  branch  office in Illinois has a contract with ISPA, which is a
  536.      member of ISPGROUP1 while the branch office in Israel has  a  contract
  537.      with  ISPC, which is a member of ISPGROUP2. As a result, it is desired
  538.      that Fred be able to login either from Illinois or from  Israel,  with
  539.      the  authentication being done by the appropriate ISP. When logging in
  540.      from Illinois, Fred uses the POPs of ISPB, while in  Israel,  he  uses
  541.      the POPs of ISPD.
  542.  
  543.      In this case, the RR records for BIGCO will appear as follows:
  544.  
  545.      bigco.com. IN RR 10 P I ispa.com.
  546.      bigco.com. IN RR 20 P I ispc.com.
  547.  
  548.      The records for ISPA, ISPB, ISPC, ISPD, ISPGROUP1 and ISPGROUP2 appear
  549.      as follows:
  550.  
  551.      ispa.com.  IN RR 10 C I ispgroup1.com.
  552.  
  553.      ispb.com.  IN RR 10 C I ispgroup1.com.
  554.  
  555.      ispc.com.  IN RR 10 C I ispgroup2.com.
  556.  
  557.      ispd.com.  IN RR 10 C I ispgroup2.com.
  558.  
  559.      ispgroup1.com.  IN RR 10 C I S ispgroup1.com.
  560.  
  561.      ispgroup2.com.  IN RR 10 C I S ispgroup2.com.
  562.  
  563.  
  564.      5.2.1.  Sequence of events
  565.  
  566.      While in the United States, Fred logs into ISPB as fred@bigco.com;  as
  567.      a  result  the  ISPB  authentication  proxy  receives this NAI. ISPB's
  568.      authentication proxy first checks for the presence of  a  user  record
  569.      for  fred.bigco.com.  If so, then it retrieves the RR resource records
  570.      for the domain to whom Fred has delegated roaming authority. If  there
  571.      is  no  user  record,  then  it  checks its configuration files to see
  572.      whether bigco.com is one of the domains with  whom  it  has  a  direct
  573.      roaming  relationship.  This check will fail since BIGCO has no direct
  574.      roaming relationship with ISPB. As  a  result,  ISPB's  authentication
  575.      proxy will need to retrieve resource records either from its own cache
  576.      or from the bigco.com zone.
  577.  
  578.      Once the RR resource records have been retrieved by one  mechanism  or
  579.      another,  a  depth  first  search  is performed in order to select the
  580.      roaming relationship path. In this case, ISPB  determines  whether  it
  581.      has  a  direct roaming relationship with ISPA (priority 10 record from
  582.      the bigco.com zone). If not, then it looks at the RR records  for  the
  583.      ispa.com  domain, and determines whether it has a direct roaming rela-
  584.      tionship with any of the domains to whom ISPA  has  delegated  roaming
  585.      responsibility.  In  this  case,  ISPB determines that it has a direct
  586.  
  587.  
  588.  
  589.      Aboba                                                         [Page 9]
  590.  
  591.  
  592.  
  593.  
  594.  
  595.      INTERNET-DRAFT                                            1 March 1997
  596.  
  597.  
  598.      roaming relationship with  ISPGROUP1  (priority  10  record  from  the
  599.      ispa.com   zone).   As   a   result,  the  roaming  relationship  path
  600.      bigco.com/ispa.com/ispgroup1.com/ispb.com is selected. Since ISPGROUP1
  601.      operates  a accounting agent within its domain, accounting records for
  602.      the transaction will be sent to ISPGROUP1's accounting agent.
  603.  
  604.      While in Israel, Fred logs into ISPD as fred@bigco.com; as  a  result,
  605.      the ISPD authentication proxy receives this NAI. ISPD's authentication
  606.      proxy then checks its configuration files to see whether bigco.com  is
  607.      one  of  the  domains  with whom it has a direct roaming relationship.
  608.      This check will fail since BIGCO has no  direct  roaming  relationship
  609.      with  ISPD.  As  a  result,  ISPD's  authentication proxy will need to
  610.      retrieve resource records either  from  its  own  cache  or  from  the
  611.      bigco.com zone.
  612.  
  613.      Once  the Roaming Relationship resource records have been retrieved by
  614.      one mechanism or another, a depth first search is performed  in  order
  615.      to select the roaming relationship path. In this case, ISPD determines
  616.      whether it has a direct roaming relationship with  ISPA  (priority  10
  617.      record  from  the  bigco.com  zone).  If  not, then it looks at the RR
  618.      records for the ispa.com domain, and etermines whether it has a direct
  619.      roaming  relationship  with  any of the domains to whom ISPA has dele-
  620.      gated roaming responsibility. In this case, ISPD  determines  that  no
  621.      roaming relationship path exists going through ISPA.
  622.  
  623.      As a result, ISPD checks for a roaming relationship on the ISPC branch
  624.      (priority 20 record from the bigco.com  zone).  First,  it  determines
  625.      whether  there  is a direct roaming relationship between ISPD and ISPC
  626.      (there is not). Then it looks at  the  RR  records  for  the  ispc.com
  627.      domain,  and  determines  whether it has a direct roaming relationship
  628.      with any of the domains to whom ISPC has delegated  roaming  responsi-
  629.      bility.  In  this  case,  ISPD determines that it has a direct roaming
  630.      relationship with ISPGROUP2 (priority  10  record  from  the  ispc.com
  631.      zone).    As    a    result,    the    roaming    relationship    path
  632.      bigco.com/ispc.com/ispgroup2.com/ispd.com is selected. Since ISPGROUP2
  633.      operates  a accounting agent within its domain, accounting records for
  634.      the transaction will be sent to ISPGROUP2's accounting agent.
  635.  
  636.  
  637.  
  638.      5.3.  Example Three
  639.  
  640.      Let us assume that Fred wishes to travel to a  country  which  is  not
  641.      served by the roaming consortia that BIGCO's provider ISPA has joined.
  642.      In this case, Fred will wish to make use of the user roaming relation-
  643.      ship resource record.
  644.  
  645.      In this case, the RR records for BIGCO will appear as follows:
  646.  
  647.      bigco.com.      IN RR 10 P I   ispa.com.
  648.      fred.bigco.com. IN RR 10 U I   ispe.com.
  649.  
  650.      The  records  for  ISPA, ISPB, ISPD, ISPGROUP1 and ISPGROUP2 appear as
  651.      follows:
  652.  
  653.  
  654.  
  655.      Aboba                                                        [Page 10]
  656.  
  657.  
  658.  
  659.  
  660.  
  661.      INTERNET-DRAFT                                            1 March 1997
  662.  
  663.  
  664.      ispa.com.  IN RR 10 C I ispgroup1.com.
  665.  
  666.      ispb.com.  IN RR 10 C I ispgroup1.com.
  667.      ispb.com.  IN RR 10 C I ispgroup2.com.
  668.  
  669.      ispe.com.  IN RR 10 C I ispgroup2.com.
  670.  
  671.      ispgroup1.com.  IN RR 10 C I S ispgroup1.com.
  672.  
  673.      ispgroup2.com.  IN RR 10 C I S ispgroup2.com.
  674.  
  675.  
  676.      5.3.1.  Sequence of events
  677.  
  678.      While traveling, Fred logs into ISPB as fred@bigco.com;  as  a  result
  679.      the ISPB authentication proxy receives this NAI. ISPB's authentication
  680.      proxy  first  checks  for  the  presence  of   a   user   record   for
  681.      fred.bigco.com.  If  so, then it retrieves the RR resource records for
  682.      the domain to whom Fred has delegated roaming authority. In this case,
  683.      a  user  record  exists for fred@bigco.com, so that the authentication
  684.      proxy determines whether it has a  direct  roaming  relationship  with
  685.      ISPE  (priority  10 record from the fred.bigco.com zone). If not, then
  686.      it looks at the RR records for the  ispe.com  domain,  and  determines
  687.      whether  it  has a direct roaming relationship with any of the domains
  688.      to whom ISPE has delegated roaming responsibility. In this case,  ISPB
  689.      determines  that  it  has a direct roaming relationship with ISPGROUP2
  690.      (priority 10 record from the ispe.com zone). As a result, the  roaming
  691.      relationship  path  fred.bigco.com/ispe.com/ispgroup2.com/ispb.com  is
  692.      selected. Since ISPGROUP2  operates  a  accounting  agent  within  its
  693.      domain,  accounting  records  for the transaction will be sent to ISP-
  694.      GROUP2's accounting agent.
  695.  
  696.      Please note that even though Fred  has  a  user  Roaming  Relationship
  697.      record,  the  authentication  conversation  will  still  be  conducted
  698.      between ISPB's authentication proxy and BIGCO's authentication server.
  699.  
  700.  
  701.      6.  Prevention of looping topologies
  702.  
  703.      Since  it is possible to create looping topologies using Roaming Rela-
  704.      tionship records, a mechanism must  be  provided  to  prevent  endless
  705.      loops.  As  a result, it is recommended that authentication proxies be
  706.      configured with a default maximum of four hops. This would support the
  707.      scenario  of an authentication passing from a NAS to an authentication
  708.      proxy, from the proxy to ISPGROUP, from ISPGROUP  to  ISPA,  and  from
  709.      ISPA to BIGCO.
  710.  
  711.  
  712.      7.  Use of the RR Record Without DNS Security
  713.  
  714.      When  Roaming  Relationship  resource records are utilized without DNS
  715.      security, no assurance can be provided as to the authenticity  of  the
  716.      roaming relationships represented by these records. As a result, it is
  717.      necessary to verify the validity of the roaming relationship  path  by
  718.  
  719.  
  720.  
  721.      Aboba                                                        [Page 11]
  722.  
  723.  
  724.  
  725.  
  726.  
  727.      INTERNET-DRAFT                                            1 March 1997
  728.  
  729.  
  730.      another  means. This can be accomplished by causing the authentication
  731.      to be routed along the roaming relationship path.
  732.  
  733.      As an example, let  us  assume  that  the  roaming  relationship  path
  734.      bigco.com/ispc.com/ispgroup2.com/ispd.com  is  selected.  If this path
  735.      has not been authenticated via DNS Security, then  ISPD's  authentica-
  736.      tion  proxy  will  forward  it's  authentication request to ISPGROUP2,
  737.      including the business relationship path as a source route.  ISPGROUP2
  738.      will then in turn forward the authentication to ISPC, who will forward
  739.      it to BIGCO. At each step of the way, a pre-existing relationship will
  740.      need to exist between hops in order for this authentication forwarding
  741.      to proceed. As a result, the act of authenticating Fred via the  roam-
  742.      ing  relationship  path  acts  to validate the roaming relationship as
  743.      determined from the RR resource records.
  744.  
  745.      Note that such hop by hop forwarding is required  even  if  IPSEC  and
  746.      public key authentication is available for use between the local ISP's
  747.      authentication proxy and the home authentication server,  as  long  as
  748.      the roaming relationship path has not been authenticated via DNS Secu-
  749.      rity. This is because while the  authentication  end-points  might  be
  750.      able to communicate securely without need for hierarchical authentica-
  751.      tion routing, the local ISP still needs to validate the roaming  rela-
  752.      tionship path.
  753.  
  754.      Please  also  note  that  DNS  Security will also typically be used in
  755.      order to enable signed receipts to be returned by the accounting agent
  756.      in  response to receipt of digitally signed accounting record bundles.
  757.      Accounting agent support for MIME Security Multiparts is indicated via
  758.      use  of  the  Email bit within the KEY resource record flag field. DNS
  759.      Security may also be used  to  indicate  that  a  home  authentication
  760.      server  supports  IPSEC.  This  is  indicated via use of the IPSEC bit
  761.      within the KEY resource record flag field.
  762.  
  763.  
  764.      8.  Use of the RR Record With DNS Security
  765.  
  766.      When used in concert with DNS Security, RR  resource  records  may  be
  767.      authenticated.  When used along with IPSEC, this permits direct commu-
  768.      nication between the local ISP's authentication  proxy  and  the  home
  769.      authentication  server.  In  addition, support for DNS Security allows
  770.      for provision of  additional  services,  such  as  non-repudiation  of
  771.      authentication  replies,  as well as for return of signed receipts for
  772.      accounting record transfers. This is accomplished via use of the  KEY,
  773.      and SIG resource records.
  774.  
  775.  
  776.      8.1.  Use of KEY Resource Record
  777.  
  778.      The  KEY  resource record is used in order to allow a public key to be
  779.      associated with a zone.
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786.  
  787.      Aboba                                                        [Page 12]
  788.  
  789.  
  790.  
  791.  
  792.  
  793.      INTERNET-DRAFT                                            1 March 1997
  794.  
  795.  
  796.      8.1.1.  Flag Field
  797.  
  798.      No additional flags need to be defined for use in roaming.  When  used
  799.      to  secure  Roaming  Relationship  resource  records, bit 0 of the Key
  800.      resource record flag field MUST be cleared, indicating that use of the
  801.      key  is  allowed  for  authentication.  Bit 1 may or may not be set to
  802.      indicate use for confidentiality. If the Roaming  Relationship  record
  803.      is  for  a user, then bit 5 will be set, indicating the use of the KEY
  804.      for a user or account. Bits 6 and 7 (none-zone entity and  zone  bits)
  805.      may  or may not be set. If the KEY resource record is for an authenti-
  806.      cation server supporting IPSEC, then bit 8 will be  set.  If  the  KEY
  807.      resource  record  is  for a accounting server supporting MIME Security
  808.      Multiparts, then bit 9 will be set. Bits 12-15,  the  signatory  bits,
  809.      may or may not be set.
  810.  
  811.  
  812.      8.1.2.  Protocol field
  813.  
  814.      When  used  to secure Roaming Relationship resource records, the value
  815.      192 will be used in the protocol octet, in order to denote  experimen-
  816.      tal  use. Should roaming technology be deployed on a widespread basis,
  817.      then a value between 1 and 191 will be assigned by IANA.
  818.  
  819.  
  820.      8.2.  Use of the SIG Resource Record
  821.  
  822.      Since the Roaming Relationship record is signed by the  zone  to  whom
  823.      roaming  authority  has been delegated, rather than the parent zone, a
  824.      zone that has delegated roaming responsibility will typically have  at
  825.      least  two  SIG records, one signed by the superzone, and at least one
  826.      additional SIG record,  signed  by  the  provider(s)  to  who  roaming
  827.      authority has been delegated.
  828.  
  829.      The  SIG  resource record used for roaming will have a type covered of
  830.      RR. It will also contain a signature expiration date and the time when
  831.      the  record was signed. Since the roaming relationship will be assumed
  832.      to be in force until the signature expiration, ISPs or roaming consor-
  833.      tia  will  typically  only  sign  records  for  short periods of time.
  834.      Finally, the SIG resource record will contain the domain to whom roam-
  835.      ing  responsibility  has  been  delegated,  and will be signed by that
  836.      domain.
  837.  
  838.  
  839.      8.2.1.  Example
  840.  
  841.      BIGCO delegates roaming authority to ISPA. As a result, ISPA  provides
  842.      the following SIG resource record in the bigco.com zone:
  843.  
  844.      bigco.com.      SIG RR 1 2 (; type-cov=RR, alg=1, labels=2
  845.                      1997040102030405    ; signature expiration
  846.                      1997030112130408    ; time signed
  847.                      31273               ; key footprint
  848.                      ispa.com.           ; signer
  849.      Z2fWBj8L=wevdKjOwJbakr2s4Ns=/Mox32X1rQntZPud1Fws/yIpbj7WBtIBug2w5ZrN
  850.  
  851.  
  852.  
  853.      Aboba                                                        [Page 13]
  854.  
  855.  
  856.  
  857.  
  858.  
  859.      INTERNET-DRAFT                                            1 March 1997
  860.  
  861.  
  862.      2sWgTDnrOZd9=/U94gor9k8XCsV5gOr1+2SuGnU/ ;signature (640 bits)
  863.  
  864.      In  order  to  secure the bigco.com zone, there will also be other SIG
  865.      resource records. Given the size of these records, it is possible that
  866.      the  resource records will exceed the maximum DNS UDP packet size, and
  867.      a TCP transfer will be required to return all of the  associated  zone
  868.      records.
  869.  
  870.  
  871.      9.  Acknowledgements
  872.  
  873.      Thanks  to  Glen  Zorn  of  Microsoft, Pat Calhoun of USR, and Michael
  874.      Robinson of Global One for many useful  discussions  of  this  problem
  875.      space.
  876.  
  877.  
  878.      10.  References
  879.  
  880.      [1]  B. Aboba, J. Lu, J. Alsop, J. Ding.  "Review of Roaming Implemen-
  881.      tations." draft-ietf-roamops-imprev-01.txt, Microsoft, Aimnet,  i-Pass
  882.      Alliance, Asiainfo, January, 1997.
  883.  
  884.      [2]   B.  Aboba, G. Zorn.  "Dialing Roaming Requirements." draft-ietf-
  885.      roamops-roamreq-02.txt, Microsoft, January, 1997.
  886.  
  887.      [3]  C. Rigney, A. Rubens, W. Simpson, S. Willens.  "Remote  Authenti-
  888.      cation  Dial  In  User Service (RADIUS)." RFC 2058, Livingston, Merit,
  889.      Daydreamer, January, 1997.
  890.  
  891.      [4]  C. Rigney.  "RADIUS Accounting." RFC 2059,  Livingston,  January,
  892.      1997.
  893.  
  894.      [5]   R. Fajman. "An Extensible Message Format for Message Disposition
  895.      Notifications."  draft-ietf-receipt-mdn-02.txt, National Institute  of
  896.      Health, November, 1996.
  897.  
  898.      [6]  M.  Elkins.  "MIME  Security with Pretty Good Privacy (PGP)." RFC
  899.      2015, The Aerospace Corporation, October, 1996.
  900.  
  901.      [7] G. Vaudreuil. "The Multipart/Report Content Type for the Reporting
  902.      of  Mail System Administrative Messages." RFC 1892, Octel Network Ser-
  903.      vices, January, 1996.
  904.  
  905.      [8] J. Galvin., et al. "Security Multiparts for MIME: Multipart/Signed
  906.      and Multipart/Encrypted." RFC 1847, Trusted Information Systems, Octo-
  907.      ber, 1995.
  908.  
  909.      [9] D. Crocker. "MIME Encapsulation of EDI Objects." RFC  1767,  Bran-
  910.      denburg Consulting, March, 1995.
  911.  
  912.      [10]  M.  Jansson,  C. Shih, N. Turaj, R. Drummond. "MIME-based Secure
  913.      EDI." draft-ietf-ediint-as1-02.txt, LiNK, Actra, Mitre Corp,  Drummond
  914.      Group, November, 1996.
  915.  
  916.  
  917.  
  918.  
  919.      Aboba                                                        [Page 14]
  920.  
  921.  
  922.  
  923.  
  924.  
  925.      INTERNET-DRAFT                                            1 March 1997
  926.  
  927.  
  928.      [11] C. Shih, M. Jansson, R. Drummond, L. Yarbrough. "Requirements for
  929.      Inter-operable  Internet  EDI."  draft-ietf-ediint-req-01.txt,  Actra,
  930.      LiNK, Drummond Group, May, 1995.
  931.  
  932.      [12]  A. Gulbrandsen, P. Vixie.  "A DNS RR for specifying the location
  933.      of services (DNS SRV)." RFC 2052,  Troll  Technologies,  Vixie  Enter-
  934.      prises, October 1996.
  935.  
  936.      [13]  D.  Eastlake,  3rd, C. W. Kaufman.  "Domain Name System Security
  937.      Extensions." Draft-ietf-dnnsec-secext-10.txt, CyberCash, Iris, August,
  938.      1996.
  939.  
  940.      [14]  S.  Bradner.  "Key words for use in RFCs to Indicate Requirement
  941.      Levels." draft-bradner-key-words-02.txt, Harvard  University,  August,
  942.      1996.
  943.  
  944.      [15]  C.  Malmud,  M.  Rose.  "Principles of Operation for the TPC.INT
  945.      Subdomain: General Principles and Policy."  RFC 1530, Internet  Multi-
  946.      casting Service, Dover Beach Consulting, Inc., October, 1993.
  947.  
  948.  
  949.  
  950.  
  951.      11.  Authors' Addresses
  952.  
  953.      Bernard Aboba
  954.      Microsoft Corporation
  955.      One Microsoft Way
  956.      Redmond, WA 98052
  957.  
  958.      Phone: 206-936-6605
  959.      EMail: bernarda@microsoft.com
  960.  
  961.  
  962.  
  963.  
  964.  
  965.  
  966.  
  967.  
  968.  
  969.  
  970.  
  971.  
  972.  
  973.  
  974.  
  975.  
  976.  
  977.  
  978.  
  979.  
  980.  
  981.  
  982.  
  983.  
  984.  
  985.      Aboba                                                        [Page 15]
  986.  
  987.  
  988.