Internet DRAFT - draft-aoun-middlebox-token-authentication

draft-aoun-middlebox-token-authentication





    MIDCOM Working Group                                         C.Aoun 
    Internet Draft                                     Nortel Networks 
    Category: Informational                                   June 2002 
    Expires on December 2002                                            
  
         Potential solution for authorization token authentication 
     
          <draft-aoun-middlebox-token-authentication-00.txt> 
                                       
      
 Status of this Memo  
     
    This document is an Internet-Draft and is in full conformance with 
    all provisions of Section 10 of RFC2026.  
         
    Internet-Drafts are working documents of the Internet Engineering 
    Task Force (IETF), its areas, and its working groups.  Note that 
    other groups may also distribute working documents as Internet-
    Drafts.  
         
    Internet-Drafts are draft documents valid for a maximum of six 
    months and may be updated, replaced, or obsoleted by other 
    documents at any time. It is inappropriate to use Internet-Drafts 
    as reference material or to cite them other than as "work in 
    progress."  
         
    The list of current Internet-Drafts can be accessed at  
         http://www.ietf.org/ietf/1id-abstracts.txt  
    The list of Internet-Draft Shadow Directories can be accessed at  
         http://www.ietf.org/shadow.html.  
         
 Abstract  
     
    This document describe a potential solution that could be used to 
    authenticate authorization tokens used in the context of Middle Box 
    discovery and control.  
     
   
 Table of Contents 
     
    1. Introduction..................................................2 
    2. Conventions used in this document.............................2 
    3. Used terminology and acronyms.................................2 
    4. Used concepts.................................................3 
    5. Practical example in a small network..........................4 
    6. Security Considerations.......................................7 
    7. Conclusion....................................................7 
    8. References....................................................8 
    9. Author's Addresse.............................................8 
    10. Intellectual Property Statement..............................8 
  
  
 Aoun   Informational    Expires - January 2003                [Page 1] 

             Potential solution for authorization            June 2002 
                token authentication  
  
  
    11. Full Copyright Statement.....................................9 
        
 1. Introduction  
         
    This document describes a potential solution that could be used to 
    authenticate authorization tokens used in the context of Middle Box 
    discovery and control. 
     
    [Caoun] and [Caoun2] discuss proposals that will allow Midcom 
    agents, as defined in [MDCMFW] to locate and communicate with 
    Middle Box deployed on the media path between application 
    endpoints. 
     
    One of the major security issues in [Caoun] and [Caoun2] is how to 
    authenticate the authorization tokens sent by the Discovery Client 
    or Combo Clients without having any prior relation with the end 
    points hosting these functions. 
     
    This draft tries to answer this issue. The model is primarily 
    inspired from the GSM network authentication model, analogy could 
    be also found with Kerberos [Kerberos].     
         
 2. Conventions used in this document  
         
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",  
     "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in  
     this document are to be interpreted as described in RFC-2119.  
     
 3. Used terminology and acronyms 
     
    MB: Middle Box- ref to the used terminology in [FRMWRK] 
     
    MA: Midcom Agent - ref to the used terminology in [FRMWRK] 
     
    AC: Application Client 
     
    AS: Application Server- In this document the used terminology 
    covers the application server function as well as its host. 
     
    AP: Application Proxy 
     
    DC: Discovery Client - Entity responsible for sending/receiving 
    discovery messages 
     
    DN: Discovery Node - Function that sits in a Middle Box, updates a 
    discovery message. 
     
    CC: Combo Client - Entity responsible for sending/receiving combo 
    protocol messages 
  
 Aoun   Informational    Expires - January 2003                [Page 2] 

             Potential solution for authorization            June 2002 
                token authentication  
  
  
     
    CN: Combo Node - Function that sits in a Middle Box, updates (and 
    replies to)  combo protocol messages. 
              
    AH: Application Host- Computing platform hosting an application   
     
     
 4. Used concepts 
     
    The authorization framework to allow MAs to request policy rules in 
    the combo model ([Caoun2]) or to discover the MBs (as discussed in 
    [Caoun]) is based on [Lhamer]). 
     
    The authorization token will have 2 parts, one part that is sent in 
    clear and signed, it provides the contact information of the 
    authorizing entity (the Application Policy server); the other part 
    is encrypted with temporary session key created or allocated by the 
    Application Policy server. The encrypted part of the token includes 
    the discovery request if used as in [Caoun] or the policy rule 
    request/discovery when used as in [Caoun2]. 
     
    Upon request for an application session, the AH will request its AP 
    to find the remote end AH contact information; the AP will then 
    request the Policy Server to check for application specific 
    policies (subscriber services etc) and in the same time to provide 
    an authorization token specific to this application session. 
     
    Once the PS has generated the authorization token, it will send it 
    to the AP, which in turn will send it through the application 
    protocol. 
     
    When the CC hosted on the AH sends the discovery message or the 
    combo protocol message it includes the token in it, the token can't 
    be modified or replaced by the AH as the MB's policy server will 
    query the authorizing policy server: 
     
          -When an MB is traversed by the message, it will extract the 
    authorization token and query the authorizing policy server (either 
    directly or through its policy server). As there is an existing 
    relation between the application server policy domain and the MB 
    policy domain, the MB policy server should have already a security 
    association with the authorizing policy server; therefore the MB's 
    policy server could request securely the authorizing policy server 
    to provide the temporary key used to encrypt the token. The same 
    key will be used to update the token and re-encrypt the token (and 
    sign) when required. 
     
  
 Aoun   Informational    Expires - January 2003                [Page 3] 

             Potential solution for authorization            June 2002 
                token authentication  
  
  
    As there is an interaction with an AH that is in a different policy 
    domain, the remote AH application policy server will need to 
    provide an authorization token to be used with the remote end MB 
    policy server. 
     
 5. Practical example in a small network 
     
      +--Foo.com-----------------+             	+--Bar.com-----------+  
      | +++++              DMZ   |		      +DMZ           +++++ + 
      | +MA1+-        MB1        |       		+    MB4       +MA2+ + 
      | +AC +              PS1   |The NET		+PS2           +AC + + 
      | +CC +         MB2        |       		+    MB5       +CC + + 
      | +++++             AP1    |       		+ AP2          +++++ + 
      | AH1           MB3        |       		+    MB6       AH2   + 
      +--------------------------+              +--------------------+ 
           
    In the used example for simplicity reasons, the application and the 
    MBs have the same policy server in both the foo.com and bar.com 
    policy domains. 
     
    MB1 and MB5 apply NAT and packet filtering on the traversed packet 
    stream. Discovery model A concepts are used without the edge MB 
    concept. 
     
    The shown message sequences are similar to those found in [Caoun2] 
    when the combo model is used, with the addition of the token 
    exchange messages, and the temporary session key requests. 
        
     
     
  
 Aoun   Informational    Expires - January 2003                [Page 4] 

             Potential solution for authorization            June 2002 
                token authentication  
  
  
    AC1/CC1    MB1     AP1    PS1    PS2     AP2      MB5     AC2/CC2     
     
    1- App session request 
    ------------------ > 
                       
                      2- App session remote end information 
                      ------------------------ > 
     
                      3-Remote end contact information(CC2 contact 
                      info) 
                      < ------------------------ 
     
                     4-Token request(local AH information, remote AH 
                     information) 
                       -------> 
                                
                               5-Token_request(remote end contact 
                               information_ack) 
                               ------ > 
                                 
                                     6- Request_session_match(remote 
                               end contact information) 
                                       ----- > 
     
                                     7- Session_match_ack 
                                     < ------- 
                             
                               8- Token_ack(CC2Token) 
                               < ------- 
     
                          9-Token_ack(CC1Token, CC2Token)  
                         < ------ 
     
                         10- Token_ack 
                         ------ > 
     
    11- App_session_ack(CC1Token, CC2Token) 
    < -------------------                   
     
    12- App_session_ack 
    -------------------- > 
     
    13-Combo_resrcreqst(CC1Token,CC2Token,CC2) 
       --------->  
     
                 
                 
                 
                 
  
 Aoun   Informational    Expires - January 2003                [Page 5] 

             Potential solution for authorization            June 2002 
                token authentication  
  
  
    AC1/CC1    MB/CN1    AP1    PS1     PS2    AP2   MB/CN5     AC2/CC2     
                      
                      
                14- Policy_check(CC1Token,CC2Token) 
                --------------->  
              
                15- Policy_check(valid_request,CC1Token_tempkey) 
                < --------------   
     
              16- Combo_resrcreqst (CC1Token,CC2Token,CC2,{CN1,NAT, 
              updated stream information}) 
                --------------------------------------->   
     
                                     17-Policy_check(CC1Token,CC2Token) 
                                         <--------------  
                                  18-Tempsession_keyreqst(CC1Token) 
                                  < ----- 
                 
                                  19-Tempsession_keyreqst(CC1Token, 
                                  tempkey) 
                                  ------- >    
                                         
                               20-
                         Policy_check(valid_request,CC1Token_tempkey) 
                                          ------------ > 
                    
                                        21- Combo_resrcreqst 
                   (CC1Token,CC2Token,CC2,{CN1,NAT, updated stream 
                   information}) 
                                                       ------------->  
              
                                  22-Combo_resrcreqst_returnpath  
    (CC1Token,CC2Token,CC2, {Combo_resrcreqst(CC1Token,CC2Token,CC2, 
    {CN1,NAT, updated stream information}}) 
                                                       < ----------- 
                                  23-Policy_check(CC1Token,CC2Token) 
                                         <--------------  
     
                                  24- Policy_check(valid_request, 
                                  CC2Token_tempkey) 
                                         ------------- > 
     
    25- Combo_resrcreqst_returnpath  
           (CC1Token,CC2Token,CC2,{CN7,NAT, updated stream 
         information},{Combo_resrcreqst(CC1Token,CC2Token,CC2, 
         {CN3,NAT, updated stream information}) 
                < -------------------------------- 
     
    26-Policy_check(CC1Token,CC2Token) 
  
 Aoun   Informational    Expires - January 2003                [Page 6] 

             Potential solution for authorization            June 2002 
                token authentication  
  
  
            -------------->  
     
    27-Tempsession_keyreqst(CC1Token) 
                                  ------ > 
                 
                                  28-Tempsession_keyreqst(CC2Token, 
                                  tempkey) 
                                  < -------    
     
    25-Policy_check(valid_request, CC2Token_tempkey) 
           <--------------   
     
 26- Combo_ resrcreqst_returnpath  
    (CC1Token,CC2Token,CC2,{CN7,NAT, updated stream 
    information},{Combo_resrcreqst(CC1Token,CC2Token,CC2, {CN3,NAT, 
    updated stream information}) 
    < --- 
     
    Each time an MB is traversed by a combo protocol message, it 
    analyses the associated authorization token, looks for the 
    authorizing policy server; sends a query to its own policy server 
    to get in touch with the authorizing policy server. The local MB 
    policy server will get an answer from the authorizing policy server 
    and see if the AH is authorized to request for policy rules 
    installation. In the example this will be the case in messages 14 
    and 15 and 23 and 24. 
     
    The local policy server will also provide the used key to decrypt 
    the token and allow the MB to re-encrypt the token after updating 
    it if required. 
     
     
 6. Security Considerations  
     
    This draft proposes one of the fixes to the security issues by 
    providing means to keep the AH completely in the dark and prevent 
    it from modifying the token. 
     
    One of the current assumptions of the draft is that the MB policy 
    servers have a pre-established security association with the 
    Application Policy server authorizing the application traversal. 
     
    The pre-established security association could use pre-shared keys 
    or PKI. The next version of the draft will discuss the various 
    scenarios to establish these associations. 
     
     
 7. Conclusion 
         
  
 Aoun   Informational    Expires - January 2003                [Page 7] 

             Potential solution for authorization            June 2002 
                token authentication  
  
  
    The draft provides a simple mechanism based on transitive trust to 
    secure the authorization token and prevent the AH to modify it. 
     
 8. References  
  
      [Caoun]   C.Aoun,L-N Hamer " Potential Solutions to the  
                 Middle Box discovery problem ",  
                draft-aoun-midcom-discovery-01.txt, work in progress 
     
      [Caoun2]  C.Aoun, "Middle Box discovery integration solutions 
                within the Midcom architecture",   
               draft-aoun-middlebox-discovery-comparison-00.txt, work 
                in progress 
           
      [FRMWRK]  P.Srisuresh et all," MIDCOM Architecture & Framework", 
                Internet draft, draft-ietf-midcom-framework-07.txt  
     
     [Kerberos] J. Kohl, C. Neuman, "The Kerberos Network  
                Authentication Service (V5)", RFC 1510, September 1993 
                 
      [LHamer]  Hamer, L-N. and Gage, B, "Framework for session setup  
                with media authorization",  
                Internet-Draft, draft-hamer-rap-session-auth-03.txt, 
                February 2002 
                 
     
        
 9. Author's Addresse  
         
    Cedric Aoun 
    Nortel Networks 
    FRANCE 
     
    Email: cedric.aoun@nortelnetworks.com 
     
     
 10. Intellectual Property Statement 
    The IETF takes no position regarding the validity or scope of any 
    intellectual property or other rights that might be claimed to 
    pertain to the implementation or use of the technology described in 
    this document or the extent to which any license under such rights 
    might or might not be available; neither does it represent that it 
    has made any effort to identify any such rights.  Information on 
    the 
    IETF's procedures with respect to rights in standards-track and 
    standards-related documentation can be found in RFC 2026.  Copies 
    of 
    claims of rights made available for publication and any assurances 
    of licenses to be made available, or the result of an attempt made 
  
 Aoun   Informational    Expires - January 2003                [Page 8] 

             Potential solution for authorization            June 2002 
                token authentication  
  
  
    to obtain a general license or permission for the use of such 
    proprietary rights by implementors or users of this specification 
    can be obtained from the IETF Secretariat. 
        
    The IETF invites any interested party to bring to its attention any 
    copyrights, patents or patent applications, or other proprietary 
    rights which may cover technology that may be required to practice 
    this standard.  Please address the information to the IETF 
    Executive 
    Director. 
     
 11. Full Copyright Statement 
     
    Copyright (C) The Internet Society (2000).  All Rights Reserved. 
        
    This document and translations of it may be copied and furnished to 
    others, and derivative works that comment on or otherwise explain 
    it 
    or assist in its implementation may be prepared, copied, published 
    and distributed, in whole or in part, without restriction of any 
    kind, provided that the above copyright notice and this paragraph 
    are included on all such copies and derivative works.  However, 
    this 
    document itself may not be modified in any way, such as by removing 
    the copyright notice or references to the Internet Society or other 
    Internet organizations, except as needed for the purpose of 
    developing Internet standards in which case the procedures for 
    copyrights defined in the Internet Standards process must be 
    followed, or as required to translate it into languages other than 
    English.  The limited permissions granted above are perpetual and 
    will not be revoked by the Internet Society or its successors or 
    assigns.  This document and the information contained 
    herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND 
    THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, 
    EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 
    THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 
    ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 
    PARTICULAR PURPOSE." 
     
   
  
     
  
 Aoun   Informational    Expires - January 2003                [Page 9]