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