Risked Based Probabilistic Routing for Ad-hoc Networks

Document Sample
Risked Based Probabilistic Routing for Ad-hoc Networks Powered By Docstoc
					            Wireless Security Potpourri


                   William A. Arbaugh
            Department of Computer Science
                 University of Maryland
                   waa @ cs.umd.edu
             http://www.cs.umd.edu/~waa
2012/10/2                                    1
        For LTS Review Purposes Only - Do Not Redistribute



                      Students
   Aram Khalili (LTS Funded)
   Nick Petroni (LTS Funded)
   Chuk Seng (LTS Funded)
   Arunesh Mishra
   Min-ho Shin (LTS Funded)
   Zhongchao Yu
   Yuan Yuan

                                                             12/15/02
                                                                   2
       For LTS Review Purposes Only - Do Not Redistribute



              Outline of Talk
 Technology
   Empirical Analysis of 802.11 hand-offs
   Neighbor graphs
      Proactive caching
      Proactive key distribution for LANs and Interworking
   Double Reverse NAT (DrNAT)
   Ad-hoc networking
      Probablistic based routing
      Secure service discovery
      Contextual based security associations


                                                            12/15/02
                                                                  3
          For LTS Review Purposes Only - Do Not Redistribute



                   Outline cont.
 Standards Activity
   TGf
      Proactive caching
      Network wide DoS found
   Tgi
      Proactive key distribution
      Numerous DoS attacks
   IETF
      EAP
      AAA
      SEND

                                                               12/15/02
                                                                     4
        For LTS Review Purposes Only - Do Not Redistribute



     One View of the Future


                                                               CDMA1x
Ad hoc extension


                                                                WLAN




                                                             12/15/02
                                                                   5
        For LTS Review Purposes Only - Do Not Redistribute



         Properties Required
   Transparency
   Security
   Ubiquity
   Performance




                                                             12/15/02
                                                                   6
       For LTS Review Purposes Only - Do Not Redistribute



    Characterize the Problem
   Roamingdelay = Layer1delay + Layer2delay
    + Layer3delay
   We want the total roaming delay to be
    less than 50ms.




                                                            12/15/02
                                                                  7
          For LTS Review Purposes Only - Do Not Redistribute



           Layer 2 (Inter-LAN)
 Layer2delay = Probe + Decision + Association
  + Authentication

     Probe – delay of scanning for next AP
     Decision - delay of initiating roam
     Associaiton – IEEE 802.11b association delay
     Authentication – IEEE 802.11 authentication delay




                                                               12/15/02
                                                                     8
      For LTS Review Purposes Only - Do Not Redistribute



                     Prism2 (Zoomair)
                     Handoff Latency - ZoomAir (prism2) on CiscoAP
                                    (umd) Breakup

               300

               250
Latency (ms)




               200                                           Reassociation Delay
                                                             Authentication Delay
               150
                                                             Decision Delay
               100                                           Probe Delay

                50

                 0
                      1   3   5      7   9   11    13   15
                                  Handoff Number



                                                          12/15/02
                     Data from Arunesh Mishra and Min-ho Shin 9
                 For LTS Review Purposes Only - Do Not Redistribute



                         Cisco Aironet 340

                 Handoff Latency - Cisco client and Cisco AP (umd)
                                     - Breakup

               500

               400
Latency (ms)




                                                                Reassociation Delay
               300
                                                                Authentication Delay
               200                                              Decision Delay
                                                                Probe Delay
               100

                 0
                     1   3   5   7   9   11   13 15   17   19
                                 Handoff Number
                                                                              12/15/02
                                                                                    10
                For LTS Review Purposes Only - Do Not Redistribute



                                     Lucent
                     Handoff Latency - Lucent on Cisco AP (umd) -
                                       Breakup

               120

               100
Latency (ms)




                80                                                 Reassociation Delay
                                                                   Authentication Delay
                60
                                                                   Decision Delay
                40                                                 Probe Delay

                20

                 0
                     1   3   5   7    9   11   13   15   17   19
                                 Handoff Number
                                                                                 12/15/02
                                                                                       11
       For LTS Review Purposes Only - Do Not Redistribute



     The Handoff Procedure
 Probe Phase                 STA
                                       PROBE PHASE
                                                          APs

   STA scans for APs
 Reassociation
  Phase
   STA attempts to
                                                          New AP        Other APs
    associate to                    REASSOCIATION PHASE


    preferred AP
                                                                IAPP




                                                                       12/15/02
                                                                             12
           For LTS Review Purposes Only - Do Not Redistribute


     The Handoff Procedure –
          Probe Phase
 Empirical Results:
     High latencies
     Large variation


 Variation in Handoff Latencies       Average Values of Handoff Latencies




                                                                  12/15/02
                                                                        13
       For LTS Review Purposes Only - Do Not Redistribute



     Why is this important?
 Hand-off times MUST be efficient to
  support synchronous connnections, e.g.
  VoIP
 ITU guidance on TOTAL hand-off
  latency is that it should be less than 50
  ms. Cellular networks try to keep it less
  than 35 ms.


                                                            12/15/02
                                                                  14
       For LTS Review Purposes Only - Do Not Redistribute


     The Handoff Proceduure-
    Reassociation Phase - IAPP
 Four IAPP Messages STA                      New AP        Old AP

   IAPP Latency > 4 *
    RTT
 Move Request and




                                                                 IAPP Messages
  Move Response
  messages over TCP




                                                            12/15/02
                                                                  15
             For LTS Review Purposes Only - Do Not Redistribute



    Neighbor Definition and Graph
   Two APs i and j are neighbors iff
      There exists a path of motion between i and j such that it is possible for a
       mobile STA to perform a reassociation
      Captures the ‘potential next AP’ relationship
      Distributed data-structure i.e. each AP or RS can maintain a list of
       neighbors

                                                             A
                            A
                                                                                 B
                                                E
                    C
                                                            E                     C
                        B
                                               D

                                1                                  D
                                                                            12/15/02
                                                                                  16
          For LTS Review Purposes Only - Do Not Redistribute


       AP Neighborhood Graph –
         Automated Learning
 Construction
    Manual configuration for each AP/RS or,
    AP can learn:
       If STA c sends Reassociate Request to AP i, with old-ap = AP j :
       Create new neighbors (i,j) (i.e. an entry in AP i, for j and vice
        versa)
       Learning costs only one ‘high latency handoff’ per edge in the
        graph
       Enables mobility of APs, can be extended to wireless networks
        with an ad-hoc backbone infrastructure
       Dynamic, i.e. stale entries time out
    Easily extended to a server



                                                                 12/15/02
                                                                       17
      For LTS Review Purposes Only - Do Not Redistribute


         Proactive Caching
             Algorithm
 Key Idea :
   Propagate security
    contexts to potential
    ‘next’ APs to
                                                                      STA 3
    eliminate IAPP latency                                                        B
    during reassociation



                                       STA’s path of motion
  1. STA associates to AP                                                2
    A
  2. AP A sends security
    context to AP B
    proactively (new IAPP           STA
                                                              1   A
    message)                                                           12/15/02

  3. STA moves to AP B –
                                                                             18
       For LTS Review Purposes Only - Do Not Redistribute


     Proactive Caching – The
            Algorithm
 When STA c associates/reassociates to AP i
   If context(c) in cache:
      Send Reassociate Response to client
      Send Move-Notify to Old-AP
   If context(c) not in cache, perform normal IAPP
    operation
   Send security context to all Neighbours(i)
 Cache Replacement : Least Recently Used
 Cache size vendor dependent
                                                            12/15/02
                                                                  19
         For LTS Review Purposes Only - Do Not Redistribute


          IAPP Messages with
           Proactive Caching
1. STA reassociates           STA             AP A                             AP B
   to AP A




                                                     Context in Cache
2. AP A has security
   context in cache
3. AP A propagates
   context to AP B                                                      Context stored
                                                                        in cache
   (all neighbors of A)
4. STA reassociates




                                                                                         Context in Cache
   to AP B which
   again has security
   context in cache

                                                                                 12/15/02
                                                                                       20
       For LTS Review Purposes Only - Do Not Redistribute


       Proactive Caching –
      Latency Improvements
 Measurements based on Soekris/OpenBSD
  platform using Prism2 HostAP driver.
 AP shared secrets preloaded on AP’s, i.e. no
  RADIUS or security block messages included.

   Basic Reassociation : 1.119 ms
   Reassociation with IAPP : 16.392 ms
   IAPP with Proactive-caching : 1.319 ms

                                                            12/15/02
                                                                  21
       For LTS Review Purposes Only - Do Not Redistribute


       Proactive Caching –
      Latency Improvements
 Measurements based on Pentium 4 laptop
  (IBM Thinkpad T23) using Prism2 HostAP
  driver.
 AP shared secrets preloaded on AP’s, i.e. no
  RADIUS or security block messages included.

   Basic Reassociation : 1.583 ms
   Reassociation with IAPP : 12.67 ms
   IAPP with Proactive-caching : 1.982 ms

                                                            12/15/02
                                                                  22
      For LTS Review Purposes Only - Do Not Redistribute


  Proactive Caching – Expected
          Performance
 Handoff latencies play a role in
  performance when mobility is high
 With LRU cache, higher the mobility,
  higher the cache-hit ratio (on average),
  implies larger number of fast-handoffs
                  Cache Hit Ratio




                                    Mobility
                                                           12/15/02
                                                                 23
      For LTS Review Purposes Only - Do Not Redistribute



    TGi Fast Roaming Goals
 Handoff to next AP SHOULD NOT
  require a complete 802.1x re-
  authentication.

 Compromise of one AP MUST NOT
  compromise past or future key material,
  i.e. back traffic protection and perfect
  forward secrecy.
                                                           12/15/02
                                                                 24
      For LTS Review Purposes Only - Do Not Redistribute



     TGi Trust Assumptions
 AAA Server is trusted
 AP to which STA is associated is
  trusted.




                                                           12/15/02
                                                                 25
      For LTS Review Purposes Only - Do Not Redistribute



            Only Two Ways
 Exponentiation support for assymmetric
  cryptographic operations at AP, or
 Trusted Third Party, i.e. Roaming
  Server




                                                           12/15/02
                                                                 26
      For LTS Review Purposes Only - Do Not Redistribute


   Proactive Key Distribution
             (TGi)
 Extend Neighbor Graphs and Proactive
  Caching to a Roaming Server
   Eliminates problems with sharing key
    material amongst multiple APs
   Easily extended to support WAN roaming
   Possibly extendable to support
    Interworking


                                                           12/15/02
                                                                 27
                  For LTS Review Purposes Only - Do Not Redistribute



         TGi Pairwise Key Hierarchy
                   Master Key (MK)




                  Pairwise Master Key (PMK) = TLS-PRF(MasterKey, “client EAP encryption”
                                                | clientHello.random | serverHello.random)




                  Pairwise Transient Key (PTK) = EAPoL-PRF(PMK, AP Nonce | STA Nonce |
                                                          AP MAC Addr | STA MAC Addr)




       Key                 Key Encryption          Temporal Key – PTK bits 256–n – can
 Confirmation              Key (KEK) – PTK           have cipher suite specific structure
Key (KCK) – PTK              bits 128–255
   bits 0–127                                                                   12/15/02
                                                                                      28
      For LTS Review Purposes Only - Do Not Redistribute



              Key Locations
                                        MK
                                        PMK

                     RADIUS (AAA)



         PMK
AP1      PTK         AP2

      MK
      PMK
      PTK                                                  12/15/02
                                                                 29
            For LTS Review Purposes Only - Do Not Redistribute



                  Roaming Example
   Given the following infrastructure with associated neighbor graph with
    STA about to associate to AP A.


                                                     A
                                                                       B
                         A
                                          E
                 C
                                                    E                   C
                     B
                                         D
                                                           D


                                                                   12/15/02
                                                                         30
    For LTS Review Purposes Only - Do Not Redistribute



           Pre Association


                   RADIUS (AAA)




A         B                   C            D             E


                                                             12/15/02
                                                                   31
      For LTS Review Purposes Only - Do Not Redistribute


    Post Authentication and 4-
           handshake
                                        MK
                                        PMK

                     RADIUS (AAA)



    PMK
    PTK
A           B                   C            D             E

          MK
          PMK                                                  12/15/02
          PTK                                                        32
           For LTS Review Purposes Only - Do Not Redistribute



              Pre-authentication
 Full 802.1X
                                             MK
Authentication
                                             PMK
     Via
  Next AP                 RADIUS (AAA)



      PMK
      PTK
A                B                   C            D             E

            MK
            PMK                                                     12/15/02
            PTK                                                           33
      For LTS Review Purposes Only - Do Not Redistribute



    Problems with Pre-Auth
 Expensive in terms of computational
  power for client, and time (Full EAP-TLS
  can take seconds depending on load at
  RADIUS Server).
 Requires well designed and overlapping
  coverage areas
 Edge cases

                                                           12/15/02
                                                                 34
        For LTS Review Purposes Only - Do Not Redistribute



    Proactive Key Distribution
              MK,PMK
                                          MK
                                          PMK

Roam Server            RADIUS (AAA)



    PMK
    PTK
A             B                   C            D             E

          MK
          PMK                                                    12/15/02
          PTK                                                          35
                For LTS Review Purposes Only - Do Not Redistribute


         Proactive Key Distribution
            Post Authentication
                            MK         Roam Server
                           PMKA
PMKB=TLS-PRF(MK, PMKA, APB-MAC-Addr,
             STA-MAC-Addr)
PMKE=TLS-PRF(MK, PMKA, APE-MAC-Addr,
             STA-MAC-Addr)
                                                           RADIUS (AAA)
                                                        PMKE
                                              PMKB



        PMKA
         PTK
A                      B PMKB             C            D             E      PMKE

                 MK
                PMKA                                                     12/15/02
                 PTK                                                           36
          For LTS Review Purposes Only - Do Not Redistribute


      Proactive Key Distribution
         STA Roam to AP B
                     MK         Roam Server
                    PMKA
    Old and new     PMKB
                    PMKE
    AP’s inform
                            RS builds                RADIUS (AAA)
         RS
                         Neighbor Graph

     PMKA
      PTK
A                 B PMKB            C            D             E   PMKE

            PMKB=TLS-PRF(MK, PMKA, APB-MAC-ADDR,
                              STA-MAC-ADDR)  12/15/02
            PTK via standard 4-way handshake       37
          For LTS Review Purposes Only - Do Not Redistribute


    Proactive Key Distribution
       STA Roam to AP B
                      MK        Roam Server
                     PMKA’
                     PMKB
                     PMKC
                     PMKD                            RADIUS (AAA)
                     PMKE’




                      PMKB
A PMKA’         B                   C PMKC       D PMKD E         PMKE’
                      PTK
           MK
          PMKB                                                 12/15/02
           PTK                                                       38
           For LTS Review Purposes Only - Do Not Redistribute


     Proactive Key Distribution
              Protocol
1.   STA associates to AP1.
2.   STA performs 802.1X EAP-TLS authentication with (AP1, AS).
3.   AS and STA derive the PMK = TLS-PRF(MasterKey, "client EAP
     Encryption" | clientHello.random | serverHello.random).
4.   AS sends PMK to AP1.
5.   AP1 and STA derive PTK via any method, e.g. 4-way handshake
6.   AP1 and STA derive GTK in usual way
7.   AS constructs PMK2 = TLS-PRF(MasterKey, PMK1, AP2-MAC-Addr,
     STA-MAC-Addr)
8.   AS sends PMK2 to AP2
9.   Steps 7 and 8 performed for each AP in Neighbor(AP1)




                                                                12/15/02
                                                                      39
           For LTS Review Purposes Only - Do Not Redistribute



                   Protocol cont.
1.   STA roams to AP2
2.   STA derives PMK2 = TLS-PRF(MasterKey, PMK1, AP2-MAC-Addr, STA-
     MAC-Addr)
3.   AP2 and STA derive PTK via key agreement, e.g. 4-way handshake
4.   AP2 and STA derive GTK in usual way
5.   STA can resume data traffic
6.   AP1 and AP2 inform AS of the roam
7.   AS constructs PMK3 = TLS-PRF(MasterKey, PMK2, AP3-MAC-Addr,
     STA-MAC-Addr)
8.   AS sends PMK3 to AP3
9.   Steps 7 and 8 done for each AP in Neighbor(AP2)




                                                                12/15/02
                                                                      40
      For LTS Review Purposes Only - Do Not Redistribute



    Why a Roaming Server?
 Not actually required (could use current
  AAA server) but:
   May load RADIUS/DIAMETER host too
    much
   Requires retention of state which RADIUS
    tries to avoid



                                                           12/15/02
                                                                 41
      For LTS Review Purposes Only - Do Not Redistribute


   Inter-LAN and Intra-WAN
           Roaming
 IP address change too costly (Layer 3
  delay)
 Current solutions (Mobile IP and IPv6)
  suffer from deployment problems.
 Mobile IP suffers from additional delays
  due to home agent


                                                           12/15/02
                                                                 42
      For LTS Review Purposes Only - Do Not Redistribute



              Our Approach
 Use double reverse network address
  translation (DRNAT) to eliminate IP
  address change.
 If a second device is used, use “smart”
  look ahead



                                                           12/15/02
                                                                 43
         For LTS Review Purposes Only - Do Not Redistribute



                          DRNAT
          Host A
                       Can be placed
       IP A
                            In
  DRNAT                 edge router

IP 1                          Net 2
                                                   IP 3          Host B
                        Net 1            IP 2                 IP B
                                                   DRNAT


                                                                12/15/02
                                                                      44
      For LTS Review Purposes Only - Do Not Redistribute



     Advantages of DRNAT
 Can be realized in software or hardware
 Requires no infrastructure changes
 Can be placed in the infrastructure to
  support non-mobile hosts




                                                           12/15/02
                                                                 45
      For LTS Review Purposes Only - Do Not Redistribute



        Inter-LAN Roaming
 Proactive key distribution handles
  security well.
 Proactive caching handles other AP
  context well.




                                                           12/15/02
                                                                 46
      For LTS Review Purposes Only - Do Not Redistribute


       Intra-LAN and WAN
             Roaming
 The approach will be to define a
  Roaming station to Roaming station
  message protocol for AAA.
 DRNAT remains useable as a client only
  approach which requires no standards
  activity.


                                                           12/15/02
                                                                 47
       For LTS Review Purposes Only - Do Not Redistribute



    Ad Hoc Network Security

We’re focusing on:
 Availability
   The major function of
    routing
   A non-trivial aspect of
    ad hoc network
    security



                                                            12/15/02
                                                                  48
         For LTS Review Purposes Only - Do Not Redistribute



                             SUCV
 SUCV Address


      Routing prefix (64 bits)        SUCV ID (64 bit)

    SUCV ID = Hash1 [ Hash2(imprint), Hash2(Public Key)]
    Due to the cryptography difficulty, it’s hard to impersonate a
     given SUCV address node, by using another private-public
     key pair.
    Dilemma: the malicious node is able create arbitrary virtual
     nodes, with new SUCV addresses.




                                                              12/15/02
                                                                    49
            For LTS Review Purposes Only - Do Not Redistribute



             Problems with SUCV



       S                                                           T

                                                                  Virtual network




                                       Assign
Malicious node                     corresponding            Virtual node
                                   SUCV address
           Create public-private                                  12/15/02
                 key pair                                               50
       For LTS Review Purposes Only - Do Not Redistribute


   Probabilistic Routing Protocol (PRP)
                 Motivation
 Traditional Ad Hoc Routing Protocols
   Deterministically based on the value of some well
    known metrics (e.g hops, cost)
   Metrics can be easily affected by attackers
 Enhancement of availability
   Introduce a new metric (risk) over which attackers
    have less control
   Select routing randomly (to some degree) to
    guarantee minimum amount of throughput
 Based on DSR
                                                            12/15/02
                                                                  51
             For LTS Review Purposes Only - Do Not Redistribute


            Overall Flow Graph of
              Route Discovery
            R1
                                 R’1
Source                                                            Destination
                 R2                R’2
           R3

      Decision node                                    PRP Route Request

      Data packet                                      PRP Route Reply
                                                                of routes
Red nodes will make route selection according to the risk value12/15/02
                                                                        52
                For LTS Review Purposes Only - Do Not Redistribute


       Simulations from Initial
     Experiment (without SUCV)



     Average Delay               Routing Overhead                Delivery Ratio

 Average delay is increased, since the routes are no
  longer always the shortest
 PRP does not suffer a large performance penalty
  with respect to both packet overhead and packet
  delivery ratio                              12/15/02
                                                                                  53
          For LTS Review Purposes Only - Do Not Redistribute



                    Assumptions
 SUCV property holds (G.Montenegro et al., G.O’Shea
  et al., Bobba et al.)
    Secure binding between an IP address and a public key for
     each node (still subject to attacks in which nodes create
     multiple virtual Ids –- to be addressed in future work)
 Some nodes share a trust relation, but not all
    A non-trusted node may be or may not be a malicious node
     but has some possibility to be a malicious node
 Trust is bidirectional and transitive
    Not the case in theory, but usually the case in practice!



                                                               12/15/02
                                                                     54
            For LTS Review Purposes Only - Do Not Redistribute



           Quantification of Risk

            c, if r is not compromise ;
                                     d
Let A(r )  
            , if r is compromised.
wherec is the cost of the route r. Let p be the
                    ch                           d.
probabilit y with whi theroute r is not compromise
                 1                 1               c
Risk (r )                                      
            E (1 A (r )) p 1 c  (1  p ) 1 /  p
p could be viewed as the confidenceof the route.
                                                                 12/15/02
                                                                       55
        For LTS Review Purposes Only - Do Not Redistribute



     Estimation of confidence
Confidence could be computed as:
                      # of trusted nodes
    confidence 
                 # of total nodes on the route
For routes replied from the route cache of an
intermediate node A*, equivalent cost and confidence
from A* to T is given by:
          ce 
                 p       i
                                  ,
                                   2

                                      pe 
                                             p
                                              i   ci
                 p c i       i              p
                                              i   ci

 in which the sum is done for all the routes from A* to
 T. This formula is given in accordance with the
 probabilistic algorithm described later.         12/15/02
                                                             56
       For LTS Review Purposes Only - Do Not Redistribute



              Trust Assertion
An assertion T(A,B) is defined as:
T(A,B)=(A, “A trusts B”, public key of A,
  nonce) , which is signed by A using the
  private key;
T(A,B) contains a statement asserting a node B
  as trusted;
T(A,B) could not be forged (by properties of
  SUCV).


                                                            12/15/02
                                                                  57
          For LTS Review Purposes Only - Do Not Redistribute



      Deciding Trusted Nodes
                     Preestablished
                  trust relationships




S                 A                 B                 C                    T

[ ]          [ T(A,S)]           [ T(A,S),         [ T(A,S),       [ T(A,S),
                                  T(B,A)]           T(B,A)]         T(B,A),
                                                                    T(T,B),
                                                                    T(T,C)]


[              [ T(A,S),         [ T(A,S),          [ T(A,S),      [ T(A,S),
T(A,S),         T(B,A),           T(B,A),            T(B,A),        T(B,A),
T(B,A),         T(T,B),           T(T,B),            T(T,B),        T(T,B),
T(T,B),         T(T,C),           T(T,C),            T(T,C),        T(T,C)]
T(T,C),         T(C,T),           T(C,T),            T(C,T)]
                T(B,T),           T(B,T)]
T(C,T),         T(A,B)]
T(B,T),
T(A,B),                                                         12/15/02
T(S,A)]                                                               58
            For LTS Review Purposes Only - Do Not Redistribute



         Route Selection Algorithm
                                   Destination       Route        Risk
                                        …              …           …
      Route cache in
                                        T        ST1:{S,A,B,T}
        source S:
                                        T        ST2:{S,M,N*,T}
                                        T        ST3:{S,L,C,T}
                                        …              …           …
 Source randomly selects a route
    With the probability of the selected route as 1/risk
 For routes replied from the destination: ST1 & ST3
    Route selection is made only by source
 For routes replied from the intermediate node: ST2
    Intermediate node will make another random route selection with
     the same strategy as the source
                                                                  12/15/02
                                                                        59
         For LTS Review Purposes Only - Do Not Redistribute



                   Future Work
 Simulations under new assumptions (e.g. SUCV
  property etc.)
 Modeling the behavior of malicious nodes to
  complement the simulation
 Exploring further the random route selection algorithm
  to make optimal tradeoff between security and
  performance
 Studying countermeasures against “multiple ID attacks”
  imposed on SUCV



                                                              12/15/02
                                                                    60
       For LTS Review Purposes Only - Do Not Redistribute



     IEEE Standards Activity
 Proactive caching proposed to TGf.
   Received well, but standard is in early
    stages of approval.
   Full written proposal will be submitted
    during re-circulation ballot (ends ~Dec 16).
 Proactive key distribution will be
  proposed to TGi in January ‘03.
   Intel, Cisco, and Microsoft currently
    support the proposal.
                                                            12/15/02
                                                                  61
     For LTS Review Purposes Only - Do Not Redistribute



                  Questions
?




                                                          12/15/02
                                                                62
       For LTS Review Purposes Only - Do Not Redistribute



     IETF Standards Activity
 A new keying draft will be submitted to AAA
  (March ‘03).
 A new key wrap will be proposed to replace
  RFC 2548 (March ‘03).
 A roaming server to roaming server protocol
  will be proposed (March ‘03).
 Member of the SEND design team.
 EAP WG security advisor.
 Students formalizing EAP state machine.
                                                            12/15/02
                                                                  63

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:2
posted:10/3/2012
language:English
pages:63