Avaya WLAN 9100 Access Points    Non‐Proprietary Security Policy  Document Version 1.1    Avaya Inc.      April 15, 2015          Non‐Proprietary Security Policy. May be reproduced only in its original entirety [without revision].   Page 1 of 18  Table of Contents References and Definitions ..................................................................................................... 3  1  Introduction .................................................................................................................... 4  1.1  Hardware and Physical Cryptographic Boundary .........................................................................4  1.2  Modes of Operation .....................................................................................................................5  2  Cryptographic Functionality ............................................................................................. 7  2.1  Critical Security Parameters .........................................................................................................9  2.2  Public Keys ....................................................................................................................................9  3  Roles, Authentication and Services ................................................................................ 10  3.1  Assumption of Roles .................................................................................................................. 10  3.2  Authentication Methods ........................................................................................................... 10  3.3  Services ...................................................................................................................................... 11  4  Self‐tests  ....................................................................................................................... 13  . 5  Physical Security Policy .................................................................................................. 14  6  Operational Environment .............................................................................................. 14  7  Mitigation of Other Attacks Policy ................................................................................. 14  8  Security Rules and Guidance .......................................................................................... 14  9  Approved Mode Configuration Instructions ................................................................... 15  9.1  Configuring the Module to operate in the FIPS 140‐2 Approved mode using the WMI  .......... 15  . 9.2  Configuring the Module to operate in the FIPS 140‐2 Approved mode using the CLI .............. 15  9.3  Determining if the Module is in the FIPS 140‐2 Approved mode of operation ........................ 15  10  Tamper Seal Installation ................................................................................................ 16  10.1 Tamper seals on the WAO912200‐E6GS ................................................................................... 16  10.2 Applying tamper seals to the WAB910003‐E6 Enclosure ......................................................... 17  List of Tables Table 1 – References ..................................................................................................................................... 3  Table 2 – Acronyms and Definitions ............................................................................................................. 3  Table 3 ‐ Part Numbers ................................................................................................................................. 4  Table 4 – Security Level of Security Requirements ....................................................................................... 4  Table 5 – Ports and Interfaces ...................................................................................................................... 5  Table 6 – Approved and CAVP Validated Cryptographic Functions .............................................................. 7  Table 7 – Non‐Approved but Allowed Cryptographic Functions .................................................................. 7  Table 8 – Protocols Allowed in FIPS Mode  ................................................................................................... 8  . Table 9 – Critical Security Parameters (CSPs) ............................................................................................... 9  Table 10 – Public Keys ................................................................................................................................... 9  Table 11 – Roles Description ....................................................................................................................... 10  Table 12 ‐ Authentication Methods ............................................................................................................ 10  Table 13 – Unauthenticated Services ......................................................................................................... 11  Table 14 – Authenticated Services .............................................................................................................. 11  Table 15 – CSP Access Rights within Services ............................................................................................. 12  Table 16 – Power Up Self‐tests ................................................................................................................... 13  Table 17 – Conditional Self‐tests ................................................................................................................ 13    List of Figures Figure 1 – Module Packaging ........................................................................................................................ 5  Non‐Proprietary Security Policy. May be reproduced only in its original entirety [without revision].   Page 2 of 18  References and Definitions  The following standards are referred to in this Security Policy.  Table 1 – References  Abbreviation  Full Specification Name  [FIPS140‐2]  Security Requirements for Cryptographic Modules, May 25, 2001  [SP800‐131A]  Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms  and Key Lengths, January 2011    Table 2 – Acronyms and Definitions  Acronym  Definition  CLI  Command line interface.  IETF  Internet Engineering Task Force  IP  Internet Protocol  RFC  Request for Comment; IETF RFCs are the public internet standards followed for TLS,  SSH and numerous other protocols.  WMI  Web management interface.          Non‐Proprietary Security Policy. May be reproduced only in its original entirety [without revision].   Page 3 of 18  1 Introduction   The  Avaya  WLAN  9100  Access  Points  (hereafter  denoted  the  Module)  are  multi‐chip  standalone  cryptographic modules used for secure wireless IP networking.  Table  3  lists  all  configurations  of  the  Module.  All  configurations  use  the  same  general  design  and  firmware,  but  are  packaged  in  two  form  factors  as  shown  in  Figure  1  below.  All  of  the  Avaya  Wi‐Fi  models, with the exception of the WAO912200‐E6GS, must be secured in the WAB910003‐E6 enclosure.  All  of  the  modules  run  the  same  version  of  firmware  and  enter  FIPS  approved  mode  identically.  Functionally the units have different numbers and types of radio modules.     NOTE:  Each  configuration  includes  all  necessary  tamper‐evident  seals.  Replacement  seals  can  be  ordered using SKU WLB910001‐E6.    Table 3 ‐ Part Numbers  Enclosure  (Form  Distinguishing Features  Model/SKU  Firmware  Factor)  WAO912200‐E6GS  WAO912200‐E6GS  AOS‐7.1  ‐2 main PCB, 2 radio, 2x2 stream  WAP913200‐E6GS  WAB910003‐E6  AOS‐7.1  ‐2 main PCB, 2 radio, 2x2 stream  WAP913300‐E6GS  WAB910003‐E6  AOS‐7.1  ‐2 main PCB, 2 radio, 3x3 stream  WAP917300‐E6GS  WAB910003‐E6  AOS‐7.1  ‐4 main PCB, 4 radio, 3x3 stream  SKU WLB910001‐ WAO912200‐E6GS  N/A  Replacement Tamper‐evident seals  E6  or WAB910003‐E6    The FIPS 140‐2 security levels for the Module are as follows:    Table 4 – Security Level of Security Requirements  Security Requirement  Security Level  Cryptographic Module Specification  2  Cryptographic Module Ports and Interfaces  2  Roles, Services, and Authentication  2  Finite State Model  2  Physical Security  2  Operational Environment  N/A  Cryptographic Key Management  2  EMI/EMC  2  Self‐Tests  2  Design Assurance  3  Mitigation of Other Attacks  N/A    1.1 Hardware and Physical Cryptographic Boundary  The physical form of the Module is depicted in Figure 1. The cryptographic boundary of the Module is  defined as the entire physical enclosure. The Module does not rely on external input/output devices.  Non‐Proprietary Security Policy. May be reproduced only in its original entirety [without revision].   Page 4 of 18  Figure 1 – Module Packaging  WAB910003‐E6 Enclosure (bottom)  WAB910003‐E6 Enclosure (top, connector port)          WAO912200‐E6GS (top)  WAO912200‐E6GS (bottom, connectors)    Table 5 – Ports and Interfaces  Port  Model (Qty)  Logical Interface Type  WAO912200‐E6GS (1); WAP913200‐E6GS (1);  Gigabit Ethernet POE  Power, Control in, Data in,  WAP913300‐E6GS (1); WAP917300‐E6GS (1)   Data out, Status out  RS‐232 Serial  Control in, Data in, Data  WAP917300‐E6GS (1)  out, Status out  WAO912200‐E6GS (2); WAP913200‐E6GS (2);  Radio RF  Control in, Data in, Data  WAP913300‐E6GS (2); WAP917300‐E6GS (4)  out, Status out    1.2 Modes of Operation  The Module may be configured in a FIPS 140‐2 Approved mode of operation or a non‐Approved mode of  operation.  The  procedure  in  Sections  9  and  10  lists  simple  steps  that  must  be  followed  exactly  to  configure  the  module  for  compliance  to  FIPS  140‐2,  Level  2.  The  procedure  includes  physical  actions,  Non‐Proprietary Security Policy. May be reproduced only in its original entirety [without revision].   Page 5 of 18  and parameters that must be set in Web Management Interface (WMI) windows in the Security section  and in other sections.  The non‐Approved mode is a superset of the Approved mode; the following functionality is disabled in  the Approved mode:   SNMP v1, v2, and v3   SSHv1, Telnet, FTP, TFTP, HTTP   SSL 2.0 and 3.0   RADIUS (internal or external)   WEP, WPA (TKIP or EAP)   Entry of PSK as passphrase (the firmware requires entry of the complete 64‐character hex value  for the pre‐shared key in the Approved mode).   All  non‐Approved  ciphers  or  ciphersuites:  blowfish,  Camellia,  CAST,  IDEA,  RC4,  SEED,  MD5  (except in TLS KDF and for storage of passwords).  MD5 is used in the Approved mode only for TLS and obfuscation of stored parameters, with no security    claim for these usages.   Non‐Proprietary Security Policy. May be reproduced only in its original entirety [without revision].   Page 6 of 18  2 Cryptographic Functionality   The  Module  implements  the  FIPS  Approved  and  Non‐Approved  but  Allowed  cryptographic  functions  listed in the tables below. Table 8 lists the high level protocols implemented by the Module.  Table 6 – Approved and CAVP Validated Cryptographic Functions   Algorithm  Description  Cert #  AES 1  [FIPS 197, SP 800‐38A, SP 800‐38C] 128‐bit ECB mode encryption, 128‐bit  2450  CCM encryption and decryption.  AES 2  [FIPS 197, SP 800‐38A] 128‐bit and 256‐bit CBC encryption and decryption.  2833  DRBG   [SP 800‐90A] Hash_DRBG (SHA‐256).  490  HMAC   [FIPS 198‐1] HMAC‐SHA‐1, HMAC‐SHA‐256 generation and verification.  1774  KDF TLS  [SP 800‐135] TLS v1.0/1.1 and v1.2 KDF  257 (CVL)  KDF SSHv2  [SP 800‐135] SSHv2 KDF  258 (CVL)  KDF 802.11i  [IG 7.2, IG 7.10, SP 800‐108] 802.11i HMAC‐SHA‐1 shared key derivation.  24 (KDF)  RSA   [FIPS 186‐4] key pair generation, PKCS1.5 signature generation, and  1475    signature verification using only RSA‐2048.  SHA   [FIPS 180‐4] Signature generation and verification (SHA‐256); non‐Digital  2374    Signature Applications (SHA‐1, SHA‐256).  Triple‐DES  [SP 800‐20] 3‐key TCBC mode encryption and decryption.   1693    Note: The TLS and SSHv2 protocols have not been reviewed or tested by the CAVP and CMVP.    Table 7 – Non‐Approved but Allowed Cryptographic Functions  Algorithm  Description  Non‐SP 800‐56A  [IG D.8] Diffie‐Hellman (key agreement; key establishment methodology provides 112  Compliant DH  bits  of  encryption  strength);  EC  Diffie‐Hellman  (key  agreement;  key  establishment  methodology provides 128 bits of encryption strength)  Non‐SP 800‐56B  [IG  D.9]  RSA  (key  wrapping;  key  establishment  methodology  provides  112  bits  of  Compliant RSA  encryption strength).  Key Transport   MD5 within TLS  [IG D.2] MD5 usage in TLS KDF, and for obfuscation of stored passwords.  NDRNG  [Annex C] Hardware Non‐Deterministic RNG; 64 bits per access, used to seed the FIPS  Approved DRBG.        Non‐Proprietary Security Policy. May be reproduced only in its original entirety [without revision].   Page 7 of 18  Table 8 – Protocols Allowed in FIPS Mode  Protocol/KDF  RFC String  TLSv1.0/1.1  TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA  TLSv1.0/1.1  TLS_DH_RSA_WITH_AES_128_CBC_SHA  TLSv1.0/1.1  TLS_DH_RSA_WITH_AES_256_CBC_SHA  TLSv1.0/1.1  TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA  TLSv1.0/1.1  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA  TLSv1.0/1.1  TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA  TLSv1.0/1.1  TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA  TLSv1.0/1.1  TLS_ECDH_RSA_WITH_AES_128_CBC_SHA  TLSv1.0/1.1  TLS_ECDH_RSA_WITH_AES_256_CBC_SHA  TLSv1.0/1.1  TLS_PSK_WITH_3DES_EDE_CBC_SHA  TLSv1.0/1.1  TLS_PSK_WITH_AES_128_CBC_SHA  TLSv1.0/1.1  TLS_PSK_WITH_AES_256_CBC_SHA  TLSv1.0/1.1  TLS_RSA_WITH_3DES_EDE_CBC_SHA  TLSv1.0/1.1  TLS_RSA_WITH_AES_128_CBC_SHA  TLSv1.0/1.1  TLS_RSA_WITH_AES_256_CBC_SHA  TLSv1.2  TLS_DH_RSA_WITH_AES_128_CBC_SHA256  TLSv1.2  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256  TLSv1.2  TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256  TLSv1.2  TLS_RSA_WITH_AES_128_CBC_SHA256  TLSv1.2  TLS_DH_RSA_WITH_AES_256_CBC_SHA256  TLSv1.2  TLS_RSA_WITH_AES_256_CBC_SHA256  SSHv2  diffie‐hellman‐group14‐sha1  SSHv2  ssh‐rsa  SSHv2  3des‐cbc; aes128‐cbc; aes256‐cbc  SSHv2  hmac‐sha1    SSHv2 and TLS v1.0/v1.1/v1.2 usage are in accordance with IG D.8 and SP 800‐135.   In the RFC strings in the table above, the following shorthand is used by the IETF TLS and SSH RFCs:  DH: Diffie‐Hellman.  diffie‐hellman‐group‐14‐sha1: Diffie‐Hellman using p = 2048 (this implementation uses q = 1024).  ECDH: Elliptic curve Diffie‐Hellman.  ECDHE: Elliptic curve Diffie‐Hellman, ephemeral.  3DES: 3‐Key Triple‐DES;   3des‐cbc: 3‐Key Triple‐DES in CBC mode.  PSK: Pre‐shared Key.  SHA: in TLS RFC strings, HMAC‐SHA‐1 integrity.  SHA256: in TLS RFC strings, corresponds to HMAC‐SHA‐256 integrity.  ssh‐rsa: in SSH strings, RSA public key authentication (this implementation uses 2048‐bit RSA only).  hmac‐sha1: in SSH strings, HMAC‐SHA1 integrity.  aes128‐cbc: in SSH strings, AES‐128 in CBC mode  aes256‐cbc: in SSH strings, AES‐256 in CBC mode    Non‐Proprietary Security Policy. May be reproduced only in its original entirety [without revision].   Page 8 of 18  2.1 Critical Security Parameters  All  CSPs  used  by  the  Module  are  described  in  this  section.  Refer  also  to  Table  15  (CSP  Access  Rights  within Services).   Table 9 – Critical Security Parameters (CSPs)  CSP  Description / Usage  Crypto  Officer  Password:  5  (min)  to  50  (max)  ASCII  printable  characters,  for  CO  CO‐PW  authentication.   DRBG‐S  DRBG State: SP 800‐90A Hash_DRBG state (V, C).  FW‐IK  Firmware Integrity Key: HMAC key for HMAC‐SHA‐1 power‐on firmware integrity test.  SSH‐SK  SSH2 Session Keys: AES‐128, AES‐256 or 3‐Key Triple‐DES key and HMAC key for SSH2.  SSH‐SS  SSH2 Shared Secret: Secret value used to derive SSH2 Session keys.   SSH2  Key  Exchange  Private  Key:  Ephemeral  Diffie‐Hellman  2048  private  key  for  SSH2  key  SSH‐KEX‐PRI  exchange.  SSH‐AUTH‐PRI  SSH2 Authentication Private Key: RSA 2048 private key for SSH authentication.  TLS‐SK  TLS Session Keys: AES‐128, AES‐256, or 3‐Key Triple‐DES keys and HMAC keys for https.  TLS‐SS  TLS shared Secret: Secret value used to derive TLS Session keys.  TLS  Key  Exchange  Private  Key:  Ephemeral  Diffie‐Hellman  2048,  RSA  2048  or  EC  P‐256  TLS‐KEX‐PRI  private key for TLS key exchange.  TLS  Authentication  Private  Key:  RSA  2048  private  key  used  to  decrypt  TLS  Pre‐Master  TLS‐AUTH‐PRI  Secret.  WL‐DSK  Wireless Derived AES Session Key: AES‐128 802.11i session encryption/decryption key.  WL‐PSK  Wireless Pre‐Shared Key: 256 bit secret value used for KDF 802.11i derivation of DSK.    2.2 Public Keys  Table 10 – Public Keys  Key  Description / Usage  SSH2  Key  Exchange  Public  Key:  Ephemeral  Diffie‐Hellman  2048  public  key  for  SSH  key  SSH2‐KEX‐PUB  exchange.  SSH2 Authentication Public Key: Diffie‐Hellman 2048 public key provided to clients for  SSH2‐AUTH‐PUB  SSH authentication.  TLS  Key  Exchange  Public  Key:  Ephemeral  Diffie‐Hellman  2048,  RSA  2048  or  EC  P‐256  TLS‐KEX‐PUB  public keys for TLS key exchange.  TLS  Authentication  Public  Key:  RSA  2048  public  key  provided  to  clients  for  TLS  host  TLS‐AUTH‐PUB  authentication.        Non‐Proprietary Security Policy. May be reproduced only in its original entirety [without revision].   Page 9 of 18  3 Roles, Authentication and Services   3.1 Assumption of Roles   The  cryptographic  module  supports  two  distinct  operator  roles  (User  and  Crypto  Officer).    Operators  authenticated to the Crypto Officer role manage the module via the serial command line interface (CLI)  or  web  management  interface  (WMI).  The  User  role  corresponds  to  operators  using  the  Module  for  wireless  client  traffic.  Authentication  of  operators  to  roles  is  cleared  when  power  is  removed  or  the  module is rebooted. The module supports multiple concurrent Users and Crypto Officers.   Table 11 – Roles Description  ID  Role  Authentication Method  CO  Crypto Officer  Identity‐based operator authentication using username and password.  User  User  Role‐based operator authentication using an 802‐11i pre‐shared key.    3.2 Authentication Methods  Table 12 ‐ Authentication Methods  Authentication  Probability of false authentication  Probability of false authentication in a one‐ Method  minute period  (1.0E‐06 required)  (1.0E‐05 required)  Passphrase  Minimum length: 5 characters  The communications rate imposes an upper limit  verification  of authentication attempts to 60,000  Character set: ASCII printable (94)   attempts/minute (1000 per second).  1/(94^5) = 1.4E‐10  60,000/(94^5)=8.2E‐6  802.11i Auth  Authentication  of  128  bit  secret  The communications rate imposes an upper limit  during 802.11i handshake.  of authentication attempts to 60,000  attempts/minute (1000 per second).  1/(2^128) = 2.9E‐39  60,000/(2^128) = 1.8E‐34        Non‐Proprietary Security Policy. May be reproduced only in its original entirety [without revision].   Page 10 of 18  3.3 Services  All  services  implemented  by  the  Module  are  listed  in  the  tables  below.  Each  service  description  also  describes all usage of CSPs by the service.  Note: All services are available in both the Approved and non‐Approved modes of operation.    Table 13 – Unauthenticated Services  Service  Description  Local reset  Power cycle the Module. Invokes power‐up self‐tests.      Table 14 – Authenticated Services   Service  Description  CO  U  Configure device parameters, non‐security relevant: routing, radio  Configure  X    function, etc.  X    Configure security  Configure TLS, SSH, 802.11 and operator accounts.    X  Connect (802.11i)  Establish and use a 802.11i connection used for wireless traffic.  Establish and use a TLS connection used for the WMI, inclusive of  Connect (TLS)  X    authentication (login) process completion.  Connect (SSH)  Establish SSH secure channel for the CLI, inclusive of authentication  X    (login) process completion.  Factory Reset destroys all Module’s CSPs, except the FW‐IK. This  X    Factory Reset  service is equivalent to the FIPS 140‐2 required Zeroize service  X    Remote reset  Trigger a reset remotely. Invokes power‐up self‐tests.  X    Show status  Show status and configuration information.  X    Update firmware  Load and manage a new firmware image. Overwrites FW‐IK.  Wireless traffic  802.11 network communications by end User.    X        Non‐Proprietary Security Policy. May be reproduced only in its original entirety [without revision].   Page 11 of 18  Note: CSPs are not output from the module.       Table 15 defines the relationship between access to CSPs and the different module services. The modes  of access shown in the table are defined as:   G = Generate: The service generates the CSP.   E = Execute: The service uses the CSP.   W = Write: The CSP is entered or established into the Module by the service.   Z = Zeroize: The CSP is destroyed by the service.   ‐‐ = The service does not access the CSP.  Note: CSPs are not output from the module.       Table 15 – CSP Access Rights within Services  CSPs  SSH‐AUTH‐PRI  TLS‐AUTH‐PRI  SSH‐KEX‐PRI  TLS‐KEX‐PRI  WL‐DSK  WL‐PSK  DRBG‐S  CO‐PW  SSH‐SK  SSH‐SS  TLS‐SK  TLS‐SS  FW‐IK  Service  Configure  ‐‐  ‐‐  ‐‐  ‐‐  ‐‐  ‐‐  ‐‐  ‐‐  ‐‐  ‐‐  ‐‐  ‐‐  ‐‐  Configure  W  ‐‐  ‐‐  E  ‐‐  ‐‐  GZ  ‐‐  ‐‐  ‐‐  GZ  ‐‐  W  security  Connect  ‐‐  W  ‐‐  ‐‐  ‐‐  ‐‐  ‐‐  ‐‐  ‐‐  ‐‐  ‐‐  GE  E  (802.11i)  Connect (TLS)  E  W  ‐‐  E  ‐‐  ‐‐  ‐‐  GE  GE  GE  E  ‐‐  ‐‐  Connect (SSH)  E  W  ‐‐  GE  GE  GE  E  E  ‐‐  ‐‐  ‐‐  ‐‐  ‐‐  Factory Reset  Z  Z  ‐‐  Z  Z  Z  Z  Z  Z  Z  Z  Z  Z  Show status  ‐‐  ‐‐  ‐‐  ‐‐  ‐‐  ‐‐  ‐‐  ‐‐  ‐‐  ‐‐  ‐‐  ‐‐  ‐‐  Reset (Local or  ‐‐  Z  ‐‐  Z  Z  Z  ‐‐  Z  Z  ‐‐  ‐‐  Z  ‐‐  Remote)   Update  ‐‐  ‐‐  EWZ  ‐‐  ‐‐  ‐‐  ‐‐  ‐‐  ‐‐  ‐‐  ‐‐  ‐‐  ‐‐  firmware  Wireless traffic  ‐‐  ‐‐  ‐‐  ‐‐  ‐‐  ‐‐  ‐‐  ‐‐  ‐‐  ‐‐  ‐‐  E  ‐‐          Non‐Proprietary Security Policy. May be reproduced only in its original entirety [without revision].   Page 12 of 18  4 Self‐tests  Each time the Module is powered up it tests that the cryptographic algorithms still operate correctly and  that  sensitive  data  have  not  been  damaged.  Power‐up  self–tests  are  available  on  demand  by  power  cycling the module.  On power up or reset, the Module performs the self‐tests described in Table 16 below. All KATs must be  completed successfully prior to any other use of cryptography by the Module.   If one of the KATs fails, the Module enters the Auto_Recovery error state.   The operator is notified of a power‐up or conditional self‐test failure by an error message on active SSH  sessions, an active console session, and an error log.    Table 16 – Power Up Self‐tests  Test Target  Description  Firmware Integrity  HMAC‐SHA‐1 (tests embedded SHA‐1).  AES 1  Separate authenticated encrypted and authenticated decrypt AES CCM KATs using  AES‐128, inclusive of underlying AES encrypt  AES 2  Separate encrypt and decrypt KATs using a 128‐bit key in ECB mode.   DRBG   Hash_DRBG KAT using SHA‐256.  RSA  Separate generate and verify KATs using 2048‐bit key pair and SHA‐256.  HMAC‐SHA‐256  HMAC‐SHA‐256 KAT (tests embedded SHA‐256).  Triple‐DES  Separate encrypt and decrypt KATs using TECB 3‐Key.     Table 17 – Conditional Self‐tests  Test Target  Description  NDRNG  The  AS.09.42  Continuous  Random  Number  Test  is  performed  each  time  a  random  value is requested from the NDRNG.  DRBG  The  AS.09.42  Continuous  Random  Number  Test  is  performed  each  time  a  random  value is requested from the DRBG.  RSA PCT  RSA Pairwise Consistency Test performed on every RSA key pair generation.  Firmware Load  HMAC‐SHA‐1 signature verification performed on firmware load.         Non‐Proprietary Security Policy. May be reproduced only in its original entirety [without revision].   Page 13 of 18  5 Physical Security Policy   The multi‐chip standalone cryptographic module includes the following physical security mechanisms:   Production‐grade components and production‐grade opaque enclosure    Tamper evident seals. The tamper evident seals and shall be installed for the module to operate  in a FIPS Approved mode of operation. (Refer to Section 10 for installation instructions.)  The Crypto Officer role is responsible for the following:    Controlling any unused tamper evident seals.   Controlling and observing changes to the module (e.g., reconfigurations) where the seals are  removed or installed.   Periodically inspecting the tamper evident seals.    The Crypto Officer is responsible for proper deployment and inspection of all Security Labels within the  FIPS network. Additional Security Labels may be ordered from Avaya using SKU WLB910001‐E6. Security  Labels should be inspected for signs of tampering which may include tears, cuts, speckling, curling, rips,  and/or wrinkles. Peeled labels will clearly display a stipple pattern over the face of the label. The Crypto  Officer should consider any unit displaying signs of tampering to be compromised and should  immediately take it out of service. The compromised unit should not be redeployed into the network  under any circumstances. If a replacement unit is needed only brand new Avaya product should be used.       6 Operational Environment  The  Module  is  designated  as  a  limited  operational  environment  under  the  FIPS  140‐2  definitions.  The  Module includes a firmware load service to support necessary updates. New  firmware versions within  the scope of this validation must be validated through the FIPS 140‐2 CMVP. Any other firmware loaded  into this module is out of the scope of this validation and require a separate FIPS 140‐2 validation.    7 Mitigation of Other Attacks Policy  The module has not been designed to mitigate attacks that are outside of the scope of FIPS 140‐2.    8 Security Rules and Guidance  The Module design corresponds to the Module security rules. This section documents the security rules  enforced by the cryptographic module to implement the security requirements of this FIPS 140‐2 Level 2  module.  1. When  the  Module  has  not  been  placed  in  a  valid  role,  the  operator  does  not  have  access  to  any  cryptographic services.  2. Data output is inhibited during key generation, self‐tests, zeroization, and error states.  3. Status  information  does  not  contain  CSPs  or  sensitive  data  that  if  misused  could  lead  to  a  compromise of the module.  4. The module does not support a maintenance interface or role.  5. The module does not support manual key entry.  6. The module does not have any external input/output devices used for entry/output of data.  7. The module does not output intermediate key values.    Non‐Proprietary Security Policy. May be reproduced only in its original entirety [without revision].   Page 14 of 18  9 Approved Mode Configuration Instructions  9.1 Configuring the Module to operate in the FIPS 140‐2 Approved mode using the WMI  To implement FIPS 140‐2, Level 2 using WMI:  1. Enable HTTPS using the CLI if it is not already enabled, using the following command:  Avaya-AP(config)# https on This allows the Web Management Interface to be used for the rest of this procedure. HTTPS is enabled  on the Module by default.   2. Select the Management Control from the Security window.    Figure 10 – Security Management Control Window    3. Set FIPS 140‐2, Level 2 Security to On (Figure 10). Click to accept any warnings about the FIPS  settings.   4. The Module will automatically save the new configuration and reboot. Once rebooted, FIPS mode  will be ON.  9.2 Configuring the Module to operate in the FIPS 140‐2 Approved mode using the CLI  1. The following CLI command will perform all of the settings required to put the Module in FIPS mode:  Avaya-AP (config-mgmt}# fips on This command saves the current FIPS‐related attribute values. They will be restored if you use  the fips off command.   2. A prompt will appear indicating that FIPS mode is about to be enabled. Type ‘yes’ to confirm. The  FIPS‐related attributes will be automatically configured and saved.   3. The Module will automatically reboot and will be configured for FIPS operation upon completion.  4. Use the fips off command if you would like to revert the FIPS settings back to the values they had  before you entered the fips on command.   Avaya-AP (config-mgmt}# fips off 9.3 Determining if the Module is in the FIPS 140‐2 Approved mode of operation  You  may  determine  whether  or  not  the  Module  is  running  in  FIPS  mode  by  verifying  that  the  settings  described in the previous procedures are in effect.      Non‐Proprietary Security Policy. May be reproduced only in its original entirety [without revision].   Page 15 of 18  10 Tamper Seal Installation  The  tamper‐evident  seals  shall  be  installed  for  the  module  to  operate  in  a  FIPS  Approved  mode  of  operation.   The Crypto‐Officer role is responsible for controlling any unused seals and for controlling/observing the  installation, removal, and replacement of the seals (as applicable).   NOTE: If necessary, replacement tamper seals may be ordered using SKU WLB910001‐E6.   10.1 Tamper seals on the WAO912200‐E6GS   The tamper seals are pre‐installed on the WAO912200‐E6GS modules at the factory, in the locations  shown below. To apply replacement seals, follow the steps below.  1. Using alcohol‐based cleaning pads, clean the surface area of any grease, dirt, oil, or adhesive.  2. Apply the two seals, one on either side of the module about 180° apart from each other,  wrapping over the side as indicated in the figures below.       Tamper seals on WAO912200‐E6GS (2x)    Tamper seal wrapping over the side of the module           Non‐Proprietary Security Policy. May be reproduced only in its original entirety [without revision].   Page 16 of 18  10.2 Applying tamper seals to the WAB910003‐E6 Enclosure  1. The WAB910003‐E6 enclosure is used for the WAP913200‐E6GS; WAP913300‐E6GS, and  WAP917300‐E6GS.  2. Mount the Array or AP in the WAB910003‐E6 square enclosure according to mounting  instructions.  3. Close and lock the enclosure.  4. Using alcohol‐based cleaning pads, clean the surface area of any grease, dirt, or oil.  5. Apply four seals, each near the middle of the straight edge of each side of the enclosure and  straddling the slight gap between the metal backing and the plastic cover as illustrated below.       Module mounted in WAB910003‐E6 enclosure    Non‐Proprietary Security Policy. May be reproduced only in its original entirety [without revision].   Page 17 of 18  #1 #2 #4  #3   Tamper seals on WAB910003‐E6 enclosure (4x)      Tamper seal applied over small gap between   metal backing and plastic cover   Non‐Proprietary Security Policy. May be reproduced only in its original entirety [without revision].   Page 18 of 18