radius capabilities
play

RADIUS Capabilities A short presentation (with math) Alan DeKok - PowerPoint PPT Presentation

RADIUS Capabilities A short presentation (with math) Alan DeKok Infoblox, Inc. IETF 64 Capabilities presentation Goals Establish a common set of requirements for capabilities. Establish a common set of terminology for capabilities. Focus


  1. RADIUS Capabilities A short presentation (with math) Alan DeKok Infoblox, Inc. IETF 64

  2. Capabilities presentation Goals Establish a common set of requirements for capabilities. Establish a common set of terminology for capabilities. Focus on requirements, independent of representation and implementation. End up with requirements that can be manipulated symbolically. IETF 64 2 DeKok

  3. Capabilities presentation Requirements for RADIUS Capabilities are advertised in packets. No existing clients or servers send capabilities in a packet. Capability aware systems must be inter- operable with existing systems. Capabilities may traverse capability-unaware intermediaries. Multi-round capability negotiation is itself a capability that can be negotiated. IETF 64 3 DeKok

  4. Capabilities presentation Base Assumptions Client and server each have a set of individual capabilities: C = { c i } Goal is to agree on the intersection of capabilities: C Interoperable = C Client ∩ C Server Capabilities are further divided into mandatory and supported sets M and S : M I = M C ∩ M S S I = S C ∩ S S IETF 64 4 DeKok

  5. Capabilities presentation Compatibility Requirements Both client and server have C ⊇ { c RADIUS } i.e. capabilities include at least normal RADIUS. If no capabilities are in a packet, capability- aware systems must use M = S = { c RADIUS } This lets newer systems use the same capability algorithms for all conversations. IETF 64 5 DeKok

  6. Capabilities presentation Proposal for Negotiation Negotiation is one round of advertising. Client sends M c and S c to server. Server has it's own M S and S S . Server decides on M I and S I . If M I ≠ M S , the server rejects the request . Otherwise, it sends M I and S I to client. Further exchanges (if any) are based on mutually agreed upon capabilities. IETF 64 6 DeKok

  7. Capabilities presentation Additional Requirements Mandatory is subset of supported M ⊆ S This makes later analysis easier . Supported is subset of full capabilities S ⊆ C i e not all capabilities have to be advertised . . If M = S = { c RADIUS }, that information does not have to be advertised in a packet. IETF 64 7 DeKok

  8. Capabilities presentation Summary The requirements presented here try to satisfy all parties. Mathematical approach helps to minimize communication issues. Mathematical approach helps to simplify analysis, using standard tools (sets, intersection, etc). Mathematical approach may help to ensure correctness of design and implementation. IETF 64 8 DeKok

  9. Capabilities presentation Recommendations Establish WG opinion on assumptions and approach presented here. Work out differences with Emile's presentation. Continue with mathematical approach. Derive additional relationships. IETF 64 9 DeKok

  10. Capabilities presentation Additional notes Capabilities must be tied to a client-server relationship Client -> Proxy -> Server Server says: Who sent the capability? Client or Proxy? Client says: Who ACK'd the capability? Proxy or server? Client must advertise more than { c RADIUS }, otherwise it is indistinguishable from existing implementations. IETF 64 10 DeKok

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend