summaryrefslogtreecommitdiffstats
path: root/raddb/mods-available/wimax
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--raddb/mods-available/wimax165
1 files changed, 165 insertions, 0 deletions
diff --git a/raddb/mods-available/wimax b/raddb/mods-available/wimax
new file mode 100644
index 0000000..3add59e
--- /dev/null
+++ b/raddb/mods-available/wimax
@@ -0,0 +1,165 @@
+#
+# The WiMAX module currently takes no configuration.
+#
+# ## Instructions for v1 and v2.0 WiMAX
+#
+# It should be listed in the "authorize" and "preacct" sections.
+# This enables the module to fix the horrible binary version
+# of Calling-Station-Id to the normal format, as specified in
+# RFC 3580, Section 3.21.
+#
+# In order to calculate the various WiMAX keys, the module should
+# be listed in the "post-auth" section. If EAP authentication
+# has been used, AND the EAP method derives MSK and EMSK, then
+# the various WiMAX keys can be calculated.
+#
+# Some useful things to remember:
+#
+# WiMAX-MSK = EAP MSK, but is 64 octets.
+#
+# MIP-RK-1 = HMAC-SHA256(ESMK, "miprk@wimaxforum.org" | 0x00020001)
+# MIP-RK-2 = HMAC-SHA256(ESMK, MIP-RK-1 | "miprk@wimaxforum.org" | 0x00020002)
+# MIP-RK = MIP-RK-1 | MIP-RK-2
+#
+# MIP-SPI = first 4 octets of HMAC-SHA256(MIP-RK, "SPI CMIP PMIP")
+# plus some magic... you've got to track *all* MIP-SPI's
+# on your system!
+#
+# SPI-CMIP4 = MIP-SPI
+# SPI-PMIP4 = MIP-SPI + 1
+# SPI-CMIP6 = MIP-SPI + 2
+#
+# MN-NAI is the Mobile node NAI. You have to create it, and put
+# it into the request or reply as something like:
+#
+# WiMAX-MN-NAI = "%{User-Name}"
+#
+# You will also have to have the appropriate IP address (v4 or v6)
+# in order to calculate the keys below.
+#
+# Lifetimes are derived from Session-Timeout. It needs to be set
+# to some useful number.
+#
+# The hash function below H() is HMAC-SHA1.
+#
+#
+# MN-HA-CMIP4 = H(MIP-RK, "CMIP4 MN HA" | HA-IPv4 | MN-NAI)
+#
+# Where HA-IPv4 is WiMAX-hHA-IP-MIP4
+# or maybe WiMAX-vHA-IP-MIP4
+#
+# Which goes into WiMAX-MN-hHA-MIP4-Key
+# or maybe WiMAX-RRQ-MN-HA-Key
+# or maybe even WiMAX-vHA-MIP4-Key
+#
+# The corresponding SPI is SPI-CMIP4, which is MIP-SPI,
+#
+# which goes into WiMAX-MN-hHA-MIP4-SPI
+# or maybe WiMAX-RRQ-MN-HA-SPI
+# or even WiMAX-MN-vHA-MIP4-SPI
+#
+# MN-HA-PMIP4 = H(MIP-RK, "PMIP4 MN HA" | HA-IPv4 | MN-NAI)
+# MN-HA-CMIP6 = H(MIP-RK, "CMIP6 MN HA" | HA-IPv6 | MN-NAI)
+#
+# both with similar comments to above for MN-HA-CMIP4.
+#
+# In order to tell which one to use (CMIP4, PMIP4, or CMIP6),
+# you have to set WiMAX-IP-Technology in the reply to one of
+# the appropriate values.
+#
+#
+# FA-RK = H(MIP-RK, "FA-RK")
+#
+# MN-FA = H(FA-RK, "MN FA" | FA-IP | MN-NAI)
+#
+# Where does the FA-IP come from? No idea...
+#
+#
+# The next two keys (HA-RK and FA-HA) are not generated
+# for every authentication request, but only on demand.
+#
+# HA-RK = 160-bit random number assigned by the AAA server
+# to a specific HA.
+#
+# FA-HA = H(HA-RK, "FA-HA" | HA-IPv4 | FA-CoAv4 | SPI)
+#
+# where HA-IPv4 is as above.
+# and FA-CoAv4 address of the FA as seen by the HA
+# and SPI is the relevant SPI for the HA-RK.
+#
+# DHCP-RK = 160-bit random number assigned by the AAA server
+# to a specific DHCP server. vDHCP-RK is the same
+# thing.
+#
+#
+#
+# ## Instructions for v2.1 (LTE) WiMAX:
+#
+# When called from the "authorize" this module will detect the
+# presence of the following attributes:
+#
+# request:WiMAX-Re-synchronization-Info
+# control:WiMAX-SIM-Ki
+# control:WiMAX-SIM-OPc
+#
+# If all attributes are present, (i.e. a known SIM is requesting a
+# resync) then the module will attempt to extract the new SQN and
+# save it in control:WiMAX-SIM-SQN. It will also save a copy of
+# RAND from the request in control:WiMAX-SIM-RAND.
+#
+# The resulting value of SQN can then be saved in a database
+# e.g. via a call to the sql module using some unlang
+#
+# When called in the "post_auth" section it looks for:
+#
+# control:WiMAX-SIM-Ki
+# control:WiMAX-SIM-OPc
+# control:WiMAX-SIM-AMF
+# control:WiMAX-SIM-SQN
+# request:WiMAX-Visited-PLMN-ID
+#
+# If all these are present then it will attempt to generate the
+# keys for EPS AKA.
+#
+# First it checks for the presence of control:WiMAX-SIM-RAND and
+# if it is not present it generates a new RAND value which is
+# stored in reply:WiMAX-E-UTRAN-Vector-RAND. If it is present then
+# the value is simply copied to the reply attribute.
+#
+# Then it calls the Milenage algorithm to generate:
+#
+# reply:WiMAX-E-UTRAN-Vector-XRES
+# reply:WiMAX-E-UTRAN-Vector-AUTN
+#
+# And finally generates KASME which is stored in:
+# reply:WiMAX-E-UTRAN-Vector-KASME
+#
+#
+# NOTE: It is up to the system administrator to make sure that all
+# the necessary "control" attributes are populated with the
+# required values. The IMSI is likely to be found in User-Name in
+# the request and this can be used as the key to grab the values
+# from a database.
+#
+#
+wimax {
+ #
+ # Some WiMAX equipment requires that the MS-MPPE-*-Key
+ # attributes are sent in the Access-Accept, in addition to
+ # the WiMAX-MSK attribute.
+ #
+ # Other WiMAX equipment request that the MS-MPPE-*-Key
+ # attributes are NOT sent in the Access-Accept.
+ #
+ # By default, the EAP modules sends MS-MPPE-*-Key attributes.
+ # The default virtual server (raddb/sites-available/default)
+ # contains examples of adding the WiMAX-MSK.
+ #
+ # This configuration option makes the WiMAX module delete
+ # the MS-MPPE-*-Key attributes. The default is to leave
+ # them in place.
+ #
+ # If the keys are deleted (by setting this to "yes"), then
+ # the WiMAX-MSK attribute is automatically added to the reply.
+ delete_mppe_keys = no
+}