Configuring Gatekeeper Security
The options that are available for securing the gatekeeper-controlled H.323 network were discussed in Chapter 16. Proper planning and design up front of the desired security function simplifies the configuration.
To configure the gatekeeper to authenticate requests, it is first necessary to set up the authentication, authorization, and accounting feature (AAA) within Cisco IOS. AAA can use credentials that are configured in either a local database on the gatekeeper or an external RADIUS security server such as the Cisco Secure Access Control Server (ACS). AAA can also send accounting records to the RADIUS server to track events such as call duration, invalid login attempts, and so on.
The exact AAA configuration depends on several factors that are beyond the scope of this book. For guidance configuring AAA, please refer to Cisco.com.
When you are using authentication, it is important that you synchronize the time between the gatekeeper and all the gateways on the network. The Network Time Protocol (NTP) is the best way to accomplish this. To enable NTP, use the ntp server command in global configuration mode. The should be that of a known good NTP time source that is reachable on the network. More information on configuring NTP is available on Cisco.com.
The security token required-for all | registration command is used on the gatekeeper to authenticate gateways during registration or to do per-call authentication. If the registration option is selected, the gateway credentials are validated before the gateway can successfully register. If the all option is used, credentials are checked during registration and for each call that is presented to the gatekeeper.
On the gateway, the security password wordall | endpoint | per-call command is used in gateway configuration mode. If the endpoint option is selected, authentication occurs only during registration. The per-call option causes credentials to be sent on every call request. The all option enables both registration and per-call authentication. The word parameter sets the password to be used for the gateway.
You can use the tokenless call authentication feature for endpoints that do not support tokens, such as CallManager. To configure tokenless call authentication, you must create an access control list (ACL) on the gatekeeper. The ACL must include permit statements for the IP address of every device that is authorized to place call routing requests to the gatekeeper.
After you create the ACL, you enter the command security acl answerarq <1-99> in gatekeeper configuration mode. The <1-99> parameter refers to the ACL you just created. When this is complete, all ARQs that are received from gateways that have IP addresses permitted by the ACL are answered, whether or not they contain a security token.
It is important to note that tokenless call authentication applies to ARQs only and has no effect on gateway registration with the gatekeeper. Also, you can use token-based and tokenless call authentication at the same time. They are not mutually exclusive.
Example 17-23 shows the configuration that is necessary to enable gateway registration authentication. In this example, per-call authentication is not being done. The AAA feature is using locally configured user IDs and passwords rather than a RADIUS server.
|
BOISE GATEWAY boise#show running-config Building configuration... ! ! Unnecessary output deleted ! interface FastEthernet0/0 ip address 10.1.5.200 255.255.255.0 h323-gateway voip interface h323-gateway voip id boise multicast h323-gateway voip h323-id boise@cisco.com h323-gateway voip tech-prefix 1# h323-gateway voip bind srcaddr 10.1.5.200 ! gateway security password goodguy level endpoint ! end GATEKEEPER A GKA#show running-config Building configuration... ! ! Unnecessary output deleted ! username leeds@cisco.com password 0 goodguy username boise@cisco.com password 0 goodguy username miami@cisco.com password 0 goodguy ! aaa new-model ! ! aaa authentication login default local aaa authentication login h323 local aaa authorization exec default local aaa authorization exec h323 local ! gatekeeper zone local boise cisco.com 10.1.5.1 zone local miami cisco.com zone local leeds cisco.com zone prefix miami 21........ security token required-for registration gw-type-prefix 1#* default-technology rrq dynamic-prefixes-accept arq reject-unknown-prefix bandwidth interzone default 64 no shutdown ! ! ntp server 10.1.5.200 ! end |
If a RADIUS server such as Cisco Secure ACS had been used, the credentials would not have appeared in the Cisco IOS configuration. Also note that NTP has been configured and is being used to synchronize the gatekeeper clock.
CallManager does not support tokens for either registration or per-call security. If CallManager trunks are in use, you cannot enable registration security; otherwise, the CallManager trunk is unable to register. You can use per-call security with CallManager by using the tokenless call authentication feature.
Troubleshooting Gatekeeper Security
If registration or call routing problems occur due to security, you can use one of several tools to determine the problem. Some common causes of security issues include the following:
- Clocks not synchronized If is the difference is too great between the time stamps on the request and the time in the gatekeeper, the request is rejected. Be sure that NTP is set up and working properly. You can use the show ntp status command to quickly verify NTP operation.
- User ID mismatch The user ID that is used is the full H.323-ID. The user ID credentials must match.
- No token being presented Some devices cannot use token authentication, as discussed previously.
Some of the tools that can assist in finding the cause of a problem include the debug h225 asn1, debug gatekeeper main 5, debug aaa authentication, and debug aaa attr trace commands. Example 17-24 shows how the debug h225 asn1 trace can assist with a gateway registration problem.
|
May 17 14:23:23.717: RAS OUTGOING PDU ::= value RasMessage ::= registrationRequest : { requestSeqNum 1150 protocolIdentifier { 0 0 8 2250 0 4 } discoveryComplete TRUE callSignalAddress { ipAddress : { ip '0A0105C8'H port 1720 } } rasAddress { ipAddress : { ip '0A0105C8'H port 56775 } } terminalType { vendor { vendor { t35CountryCode 181 t35Extension 0 manufacturerCode 18 } productId '436973636F47617465776179'H versionId '32'H } gateway { protocol { voice : { supportedPrefixes { { prefix dialedDigits : "1#" } } }, h323 : { supportedPrefixes { } } } } mc FALSE undefinedNode FALSE } terminalAlias { h323-ID : {"boise@cisco.com"} } gatekeeperIdentifier {"boise"} endpointVendor { vendor { t35CountryCode 181 t35Extension 0 manufacturerCode 18 } productId '436973636F47617465776179'H versionId '32'H } timeToLive 60 keepAlive FALSE willSupplyUUIEs FALSE maintainConnection TRUE usageReportingCapability { nonStandardUsageTypes { { nonStandardIdentifier h221NonStandard : { t35CountryCode 181 t35Extension 0 manufacturerCode 18 } data '40'H } } startTime NULL endTime NULL terminationCause NULL } } May 17 14:23:23.865: May 17 14:23:23.865: RAS INCOMING PDU ::= value RasMessage ::= registrationReject : { requestSeqNum 1150 protocolIdentifier { 0 0 8 2250 0 4 } rejectReason securityDenial : NULL gatekeeperIdentifier {"boise"} } |
You can see that the registration request from the Boise gateway was rejected because of securityDenial. In this case, no security information was included in the RRQ. This most likely indicates a configuration error in the gateway. Example 17-25 shows the successful registration process after the configuration was corrected.
|
value RasMessage ::= registrationRequest : { requestSeqNum 1170 protocolIdentifier { 0 0 8 2250 0 4 } discoveryComplete TRUE callSignalAddress { ipAddress : { ip '0A0105C8'H port 1720 } } rasAddress { ipAddress : { ip '0A0105C8'H port 52091 } } terminalType { vendor { vendor { t35CountryCode 181 t35Extension 0 manufacturerCode 18 } productId '436973636F47617465776179'H versionId '32'H } gateway { protocol { voice : { supportedPrefixes { { prefix dialedDigits : "1#" } } }, h323 : { supportedPrefixes { } } } } mc FALSE undefinedNode FALSE } terminalAlias { h323-ID : {"boise@cisco.com"} } gatekeeperIdentifier {"boise"} endpointVendor { vendor { t35CountryCode 181 t35Extension 0 manufacturerCode 18 } productId '436973636F47617465776179'H versionId '32'H } timeToLive 60 tokens { { tokenOID { 1 2 840 113548 10 1 2 1 } timeStamp 1147876446 challenge 'F64FAD4A17AFE3C1D0D51ADF38071BA8'H random 164 generalID {"boise@cisco.com"} } } cryptoTokens { cryptoEPPwdHash : { alias h323-ID : {"boise@cisco.com"} timeStamp 1147876446 token { algorithmOID { 1 2 840 113549 2 5 } paramS { } hash "6D01394D6E13493CB7338E16EADDB9F" } } } keepAlive FALSE willSupplyUUIEs FALSE maintainConnection TRUE usageReportingCapability { nonStandardUsageTypes { { nonStandardIdentifier h221NonStandard : { t35CountryCode 181 t35Extension 0 manufacturerCode 18 } data '40'H } } startTime NULL endTime NULL terminationCause NULL } } May 17 14:34:07.073: RAS INCOMING PDU ::= value RasMessage ::= registrationConfirm : { requestSeqNum 1170 protocolIdentifier { 0 0 8 2250 0 4 } callSignalAddress { } terminalAlias { h323-ID : {"boise@cisco.com"} } gatekeeperIdentifier {"boise"} endpointIdentifier {"840F50B400000003"} alternateGatekeeper { } timeToLive 60 willRespondToIRR FALSE maintainConnection TRUE supportsAdditiveRegistration NULL usageSpec { { when { end NULL inIrr NULL } callStartingPoint { connect NULL } required { nonStandardUsageTypes { } startTime NULL endTime NULL terminationCause NULL } } } } |
In this example, you can see that both the Cisco Access Token (CAT) and H.235 cryptoToken are included in the RRQ. The Cisco gatekeeper only processes the CAT; it ignores the cryptoToken. The cryptoToken is included for compatibility with third-party gatekeepers. You can also see the H.323 ID and timestamp in the trace output.