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