rerun "make asciidoc"

diff --git a/doc/antora/modules/raddb/pages/dictionary.adoc b/doc/antora/modules/raddb/pages/dictionary.adoc
index 84628e016d2faea650b48c44740152fd22bc1fc2..0dd426a06c8d6deabe72f994b58de593e1b01c3d 100644 (file)
--- a/doc/antora/modules/raddb/pages/dictionary.adoc
+++ b/doc/antora/modules/raddb/pages/dictionary.adoc
@@ -47,10 +47,73 @@ required, or add your own.
 
 
 
+
+## v3 Compatible names.
+
+All of the attributes have been renamed from v3.  This change was
+necessary in order to support new funtionality in v4.  The
+unfortunate side effect of this change is that all of the names in
+SQL, LDAP, and the "files" module are incompatible with v4.
+
+We recognize that is is difficult to change every entry in a
+database, especially when there's no clear mapping between the
+"old" and "new" names.  This renaming is made more complex because
+the "new" names need to be grouped and arranged in ways that the
+old ones were not.
+
+The "old" names were all in flat lists, so that User-Name appeared
+next to Cisco-AVPAir.  This organization was simple enough to work
+for 20 years, but its time has come.  The new names are
+hierarchical, so that the organization is nested by definition.
+
+For v4, the Cisco-AVPair attribute is called "AVPair", and it lives
+inside of the "Cisco" namespace, which in turn lives inside of the
+"Vendor-Specific" namespace.  So the new name for Cisco-AVPair is
+Vendor-Specific.Cisco.AVPair.
+
+This process continues for many thousands of vendor-specific
+attributes.
+
+Happily, it is possible to (mostly) use the old names with v4.
+There are limitations, but it will mostly work.  The main reason
+for enabling the old names is to try out v4 with a database that is
+also used by v3.  This lets you test that v4 works, without going
+through a complex "upgrade everything" process.
+
+The old v3 names are in "alias" dictionaries, in the ${dictdir}
+directory.  To find out where this directory is on your local
+system, run "radiusd -h" or "radclient -h".  Then look for the "-D"
+command-line option, and it will tell you where the dictionary
+files are located.
+
+The v3 names are in ${dictdir}/radius/alias/alias.VENDOR where
+VENDOR is the name of the vendor, which is taken from the VENDOR
+definition in the v3 dictionaries.
+
+You will need to add a $INCLUDE line for each vendor-specific
+dictionary which is used by your local system.  The default v4
+dictionaries do not enable all of v3 compatibilty names.
+
+Yes, we recognize that this process is a bit of work.  However, we
+wish to encourage everyone using v4 to upgrade to using the new v4
+features.  Our experience shows that if we automatically enable
+"compatibility functions", then those compatiblity functions will
+be used for a decade.  So we need to find a balance between
+upgrades and ongoing support.  Easy upgrades will mean complex
+ongoing support.  Complex upgrades make ongoing support easier, but
+also make it less likely that people will upgrade.
+
+
+All of the v3 compatibility names are in the RADIUS namespace.
+
+
 == Default Configuration
 
 ```
 #ATTRIBUTE     My-Local-String         3000    string
 #ATTRIBUTE     My-Local-IPAddr         3001    ipaddr
 #ATTRIBUTE     My-Local-Integer        3002    integer
+BEGIN-PROTOCOL RADIUS
+#$INCLUDE ${dictdir}/radius/alias/alias.cisco
+END-PROTOCOL RADIUS
 ```

diff --git a/doc/antora/modules/raddb/pages/mods-available/eap.adoc b/doc/antora/modules/raddb/pages/mods-available/eap.adoc
index 0508447be2a3530cc54412317e235112818900ba..751beb930d6618dbc6b888655f0d9932c1667be2 100644 (file)
--- a/doc/antora/modules/raddb/pages/mods-available/eap.adoc
+++ b/doc/antora/modules/raddb/pages/mods-available/eap.adoc
@@ -20,6 +20,28 @@ then cannot use ANY other authentication method.
 ## Configuration Settings
 
 
+require_identity_realm:: Require the the EAP Identity provided contains
+a realm.
+
+If `require_identity_realm` is `nai`, the EAP identity provided must
+end with `@<label0>.<label1>[.<labelN>]`, i.e. an '@' followed by at least
+two DNS labels.
+
+If `require_identity_realm` is `yes`, the EAP identity provided must
+either match the NAI format described above, or a `Stripped-User-Domain`
+attribute must be present in the request list.
+This validation mode is intended to be user where Windows machine
+authentication is intermixed with user authentication.
+
+If `require_identity_realm` is `no`, no identity format checks are performed.
+It is NOT recommended to use this value.  Future security standards will
+key off the NAI realm to validate the certificate we (the EAP server) present.
+If you do not require an NAI realm be present in the EAP identity string,
+your users will not be able to take advantage of this added security when
+it is enabled by OS and device vendors.
+
+
+
 default_eap_type:: The default EAP submodule to invoke when an `EAP-Identity`
 response is received.
 
@@ -1581,6 +1603,7 @@ TODO
 
 ```
 eap {
+#      require_identity_realm = nai
 #      default_eap_type = md5
        ignore_unknown_eap_types = no
        type = md5