| |
Approved
|
Log event records will be formatted as recommended in RFC 3164, Section 4.1. The PRI part will use a Facility Numerical Code of 21 (local use 5). The syslog TIMESTAMP field will be set to the time indicated by the internal clock (see 96x1COPS.5.1.100 in [7.1-4]). The telephone’s extension number, if known, will be included as the first part of the syslog TAG field. The entire length of each syslog message will be 80 characters or less.
Information that may be considered sensitive or private by a user, such as called party telephone numbers or IP addresses, will not to be logged.
|
Note:
|
The Priority value in the PRI part is determined by multiplying the Facility Numerical Code by 8 and adding the Severity Numerical Code (0-7). Since the Facility Numerical Code has a fixed value of 21 (which, multiplied by 8, is 168), the Priority values will range from 168 (for a Severity of 0) to 175 (for a Severity of 7).
|
Rationale:
|
Linux-based versions of ACP use syslog internally, but the syslog service is not currently made available to other devices on the LAN. Facility numerical code 21 (local use 5) was chosen because it is not currently used internally by ACP. In the event that the ACP syslog server is activated for external access, syslog messages from IP telephones should be distinguishable.
|
Approved
|
The HOSTNAME field will contain the telephone’s IP address.
|
Note:
|
The IP address used in the HOSTNAME field should be the same one that is used as the source IP address in the packet that carries the syslog message, so if IPv4/IPv6 dual-stack operation is enabled (see 96x1H-IPI.5.1.300), the address to be used would be determined by whether the value of LOGSRVR is an IPv4 or IPv6 address. If only local logging to the SNMP MIB is being done (see MIB Group 3 in 96x1H-IPI.5.1.1100), the IP address doesn’t really matter, and a null value (0.0.0.0) could even be used to keep it as short as possible and to indicate that the message was not transmitted.
|
Approved
|
A client for transmitting log event records to a syslog server will be supported as specified in IETF RFC 3164 [7.3-30a], and as clarified below.
Syslog will use UDP (see 96x1H-IPI.5.1.400) as a transport-layer protocol.
|
Note:
|
The UDP port numbers used for syslog are specified in 96x1H-IPI.5.1.400.
|
Approved
|
If the value of NVLOGSTAT (see 96x1H-IPI.2.1.500) is greater than “0” and the value of LOGSRVR is either a valid IP address or a resolvable DNS name, a syslog message will be sent to that IP address whenever a log event record is generated with a severity whose numerical code is less than the value of NVLOGSTAT.
|
Note:
|
The conditions constituting an error event, the severity level, and the exact format of the syslog message will be determined by development unless explicitly specified.
|
Note:
|
Syslog messages cannot be sent until or unless the telephone successfully obtains a configuration file, because LOGSRVR is not saved in non-volatile memory and LOGSRVR can only be set in a configuration file (see 96x1H-IPI.2.1.1200).
|
Note:
|
Log event records may also be captured in the SNMP MIB (see endptRecentLog and endptResetLog in Group 3 of the MIB in 96x1H-IPI.5.1.1100), even if NVLOGSTAT is “0” or if LOGSRVR does not contain a valid address. However, while RFC 3164 allows syslog messages to contain up to 1024 characters, RFC 2579 only allows SNMP MIB DisplayString objects to contain up to 255 characters, so if a log event record is longer than 255 characters, the entire record cannot be saved in a DisplayString object.
|
Note:
|
Since syslog messages are sent over UDP (no connection is established) and do not receive acknowledgements, the telephone cannot tell whether the messages are being received.
|
96x1H-IPI.5.1.1350: Logging to an internal file |
Approved
for R6.2.3+
|
If and only if the value of the parameter LOGTOFILE is “1”, optional debug printf strings will be saved in an internal file.
|
Note:
|
Some special (critical) debug printf strings may be saved in an internal file even if the value of LOGTOFILE is “0”.
|
Note:
|
These printf strings are not the same as, and need not have the same format as, the log event messages specified in 96x1H-IPI.5.1.1300.
|
96x1H-IPI.5.1.1400: Hypertext Transfer Protocol (HTTP) client |
Approved
|
An HTTP 1.1 client will be supported as specified in IETF RFC 2616 (Hypertext Transfer Protocol – HTTP/1.1) [7.3-23b] and below.
URI syntax will be supported as specified in IETF STD 66: RFC 3986 (Uniform Resource Identifier (URI): Generic Syntax) [7.3-25c].
|
Rationale:
|
Although RFC 2616 references (in Section 3.2.1) IETF RFC 2396 [7.3-25b] for URI syntax and semantics, RFC 2396 was obsoleted by RFC 3986, and support of RFC 3986 is required by Requirement 32 in Section 5.3.5.4.10 of UCR 2008 [7.8-1d]. RFC 3986 supports IPv4 and IPv6 addresses in URIs, but RFC 2396 only supports IPv4 addresses.
|
Approved
|
The HTTP client will use TCP (see 96x1H-IPI.5.1.500) as a transport-layer protocol when the URI for a transmitted message begins with “http://”. The TCP connection will be established to port 80 unless a different port number is explicitly specified in the URI.
The HTTP client will be able to use TLS and/or SSL (see 96x1H-IPI.5.1.1500) over TCP as a transport-layer protocol when the URI for a transmitted message begins with “https://”, if usage of TLS and/or SSL is explicitly specified by the application using the HTTP client. The TCP connection will be established to port 443 unless a different port number is explicitly specified in the URI. The HTTP 1.1 Upgrade header (see RFC 2817 [7.3-23e]) will not be supported.
|
|
A User-Agent header (see Section 14.43 of RFC 2616 [4.2-23b]) will be included in all HTTP request messages, formatted as follows:
User-Agent: AVAYA/96x1H/vMajorSoftwareVersion+(model4)/Std/MinorSoftwareVersion
where:
MajorSoftwareVersion is the software version number as conveyed to customers,
model4 is the value of the MODEL4 parameter, and
MinorSoftwareVersion is any finer-grained internal software version identifier.
|
Example:
|
The User-Agent header for a 9621GD01A running H.323 software release 6.2.2, build 09 would be: User-Agent: AVAYA/96x1H/v6.2.2+(9621)/Std/09
|
Note:
|
The requirement for the User-Agent header was moved here from 96x1WML.1 in [7.1-8] because all HTTP requests, not just those from the browser, should include the same User-Agent header.
|
Approved
|
If and only if explicitly specified by application-specific requirements, proxy server usage will be supported as follows: if the value of WMLPROXY can be resolved into a valid IP address, it will be used as the destination IP address, and the value of WMLPORT will be used as the destination TCP port number, for all connections established for URLs for that application, except for those URLs for which the rightmost part of the host portion of the authority part of the URL (see Section 3 of [7.3-25b]) matches a value of WMLEXCEPT. If the value of WMLPROXY is null, or if WMLPROXY cannot be resolved into a valid IP address, WMLPROXY, WMLPORT and WMLEXCEPT will not be used.
|
Note:
|
Support of proxy server usage is not specified in 96x1H-IPI.3.1.100 for file download during startup, or in 96x1H-IPI.4.1.100 for backup or restore of user-specific data. Besides the WML browser, it is intended to be used only by applications that must be able to use HTTP through a firewall, such as
|
|
SCEP (see 96x1H-IPI.5.1.1600) and the Weather and World Clock applications (see Section 5.2 in [7.1-5]). The proxy parameters begin with “WML” because the WML browser was the only application that needed them when they were first implemented.
|
Approved
|
The CONNECT method (see RFC 2817 [7.3-23e]) will not be supported.
|
Note:
|
Since the CONNECT method is not supported, HTTPS connections will not work through a proxy server.
|
Approved
|
If a URI begins with either “http://string1:string2@...” or “https://string1:string2@...”, the “string1:string2@” portion will be removed from the URI before it is used in an HTTP request, and “string1:string2” will be encoded in base64 and included in an Authorization: header in the HTTP request as specified for HTTP Basic Authentication in Section 2 of RFC 2617 [7.3-23d]. The strings will not be treated as user-specific data.
|
Note:
|
Since passwords can contain special characters, including “:” and “@”, and since usernames do not typically contain colons and the rest of a valid URI cannot contain a “@”, the first colon found after the scheme (“http://” or “https://”) should be assumed to be the separator between string1 and string2, and the last “@” in the URI should be assumed to be the separator between string2 and the rest of the URI. If either one is not found, it should be assumed that the URI does not contain credentials.
|
Note:
|
Inclusion of credentials in a URL seems to have first been specified in Section 3.1 of RFC 1738 [7.3-25a], which is updated, but not obsoleted, by RFC 3986, which deprecates the usage in its Section 3.2.1. Section 3.3 of RFC 1738 also claims to specify the HTTP URL scheme, but so does Section 3.2.2 of RFC 1945 (HTTP 1.0) and Section 3.2.2 of RFC 2616 (HTTP 1.1), and neither of the latter two mention the inclusion of credentials.
|
Note:
|
HTTP Basic Authentication is not secure, because decoding base64 is only slightly harder than decoding Pig Latin, and the inclusion of authentication credentials in a URI that is the value of a parameter in a configuration file is also not secure, because even though they will be removed from the URI before the HTTP request is sent, the downloading of configuration files is not secure, even if HTTPS is used, because the files are sent to any client that requests them. Therefore, this mechanism should only be used as a work-around for compatibility with file servers that require authentication, by customers that would not otherwise use authentication.
|
Rationale:
|
Microsoft IIS version 7 and later file servers require authentication for PUT requests.
|
Approved
for R6.2.3+
|
If the authority portion of a URI (see Section 3 of RFC 3986) contains a DNS name, that DNS name will be used in the Request-URI or in the Host: header, as appropriate, it will not be replaced by an IP address resolved via DNS.
|
Note:
|
Section 5.1.2 of RFC 2616 states that the Request-URI must be an absolute URI (which contains the host portion) if the request is being made to a proxy, however, if the request is being made to the origin server for the resource, the Request-URI must contain the absolute path of the resource, and the authority portion of the URI must be in the Host: header.
|
Note:
|
If the authority portion of the URI was created by concatenating the value of DOMAIN with a value of HTTPSRVR or TLSSRVR, the complete authority portion must be used in the appropriate HTTP field.
|
Note:
|
There seems to be a contradiction in RFC 2616 as to whether a dotted-decimal IP address may be included in a Host: header if it is also in the authority portion of the URI. Section 5.1.2 states that “the network location of the URI (authority) MUST be transmitted in a Host header field”, which implies that an IP address in a URI should be included in a Host: header, but Section 14.23 states that “If the requested URI does not include an Internet host name for the service being requested, then the Host header field MUST be given with an empty value.” At least one PC browser (Firefox) does seem to include an IP address in a Host: header if it is in the URI.
|
Rationale:
|
Some customers use distributed content delivery systems that only recognize the intended resource if the fully-qualified DNS name is included.
|
Approved
for R6.2.3+
|
If the HTTP client receives a response code of 301 (Moved Permanently), 302 (Found), 303 (See Other), or 307 (Moved Temporarily), the HTTP request will be resent using the URI provided in the received Location: header. A URI received in a Location: header in a 301 response will be stored in volatile memory for automatic reuse if the same Request-URI is requested. A maximum of 5 redirections will be attempted per request before the request is abandoned.
|
Note:
|
The 304 (Not Modified) response code should only be received in response to a GET request that includes an If-Modified-Since header, to indicate that the file is not being returned because it has not changed (see flowcharts 3b-5 and 3b-6 in 96x1H-IPI.3.1.100). The 300 (Multiple Choices) and 305 (Use Proxy) response codes are not supported.
|
Approved
|
If the HTTP client receives a response code of 500 (Internal Server Error), or a response code of 503 (Service Unavailable) with a Retry-After header with a non-integer (i.e., a date) value, the HTTP request that resulted in the response code will be abandoned. If the HTTP client receives a response code of 503 with a Retry-After header with an integer value, the HTTP request will be resent in that number of seconds. If the HTTP client receives a response code of 503 without a Retry-After header, an additional request will be sent after a randomly selected interval in the range of 4-6 seconds.
The HTTP client will be able to include optional and non-standard headers in transmitted messages if specified by application-specific requirements.
The HTTP client will not save or cache cookies (see [7.3-23e,f]) or files (see Sections 13 and 14.9 of [7.3-23b]) unless specified by application-specific requirements.
Manual entry of HTTP authentication credentials and procedures as specified in IETF RFC 2617 [7.3-23d] will be supported if explicitly specified by the application, otherwise, the HTTP request that resulted in the 401 (Unauthorized) or 407 (Proxy Authentication Required) response code is to be abandoned.
Manually-entered HTTP authentication credentials and the associated realm from successful authentications will be treated as user-specific data that will be saved for automatic reuse in responses to subsequent challenges from the same realm within the same application, and will be set to null whenever other user-specific data is removed from the telephone. Credentials will not be saved in non-volatile memory unless explicitly specified by application-specific requirements. Application-specific requirements must also specify how many sets of credentials are to be saved for reuse if more than one set of credentials is to be saved. Credentials from the most recent successful authentication will replace the least-recently used credentials once the limit for an application has been reached.
When HTTP authentication is required and authentication credentials for that realm are not available, an HTTP Authentication interrupt screen will be displayed as specified by 96x1COPS.7.2.100 in [7.1-4] and below, with the priority specified for the HTTP Authentication screen by 96x1COPS.7.2.200 in [7.1-4]:
|
Approved
for R6.0
|
“HTTP Authentication” will be displayed on the Title Line unless alternate text is specified by the application.
“Enter authentication credentials” will be displayed on the Prompt Line unless alternate text is specified by the application.
|
Approved
for R6.1+
|
“Enter authentication credentials” will be displayed on the Status Line unless alternate text is specified by the application.
|
Approved
|
“Realm: ” followed by the realm-value received in the 401 or 407 response code will be displayed, left-justified on the first application line.
|
Approved
for R6.1+
|
The following will be displayed by touchscreen telephones:
“User ID...” will be displayed, left-justified on the second application line. If there is a non-null userid for the indicated realm, it will be displayed, right-justified on the same line. This line will be selectable.
“Password...” will be displayed, left-justified on the third application line. If there is a non-null password for the indicated realm, eight asterisks will be displayed, right-justified on the same line. This line will be selectable.
If the “User ID...” line is selected, the on-screen keyboard will be displayed as specified in Section 1.7.3 of [7.2-3d] and normal text entry procedures will be used as specified by 96x1COPS.4.1.250 and 96x1COPS.4.1.450 in [7.1-4]. “User ID:” will be displayed to the left of the input field, and if there is a non-null userid for that realm, it will be displayed in the input field.
If the “Password...” line is selected, the on-screen keyboard will be displayed as specified in Section 1.7.3 of [7.2-3d] and Password text entry procedures will be used as specified by 96x1COPS.4.1.250, 96x1COPS.4.1.450 and 96x1COPS.4.1.550 in [7.1-4]. “Password:” will be displayed to the left of the input field, which will initially be empty.
A Cancel softkey will always be provided, and an Enter softkey will be provided when both values are not null.
The following will be displayed by button-oriented telephones:
|
Approved
|
“User ID: ” followed by a user-input field (see 96x1COPS.4.1.400 and 96x1COPS.4.1.450 in [7.1-4]) will be displayed, left-justified on the second application line and will be active for text entry.
“Password: ” followed by a user-input field will be displayed, left-justified on the third application line.
Softkeys will be labeled as specified by 96x1COPS.4.1.200 in [7.1-4], except that Save will be changed to Enter, and it will only be present when both values are not null.
All telephones will operate as follows.
If Enter is pressed, the authentication screen will be removed from the display and the HTTP request that resulted in the 401 or 407 response code will be tried again using the text that was entered.
If the Cancel softkey is pressed, any text entered into the user-input fields will be discarded, the authentication screen will be removed and the HTTP request that resulted in the 401 or 407 response code will be abandoned.
If an authentication attempt fails, an HTTP Authentication Failure interrupt screen will be displayed that is identical to the HTTP Authentication interrupt screen specified above except that “Authentication failed. Try again.” will be displayed on the
|
R6.0
|
Prompt Line
|
R6.1+
|
Status Line
|
Approved
|
unless alternate text is specified by the application.
|
Note:
|
The HTTP authentication screens specified above assume that the user interface framework specified in [7.1-3a,b,c,d] is available for use, which is not true until after the HTTP file download procedures specified in 96x1H-IPI.3.1.100 (which do not currently support HTTP authentication) are complete.
|
Note:
|
In the context of this requirement, “application-specific” refers to applications such as configuration file downloading, backup and restore of user data, HTTP push, and the web browser. It does not mean that individual web-page-based “applications” rendered in the web browser may specify these “application-specific” customizations.
|
Note:
|
Applications that currently use the HTTP client are configuration and software file downloading (see 96x1H-IPI.3.1.100), backup and restore of user data (see 96x1H-IPI.4.1.100), the WML browser (see [7.1-7]), and push (see [7.1-6]).
|
Note:
|
Application-specific requirements must specify operation with respect to specific response codes received by the HTTP client, e.g., 3xx (Redirection), 401 (Unauthorized), 407 (Proxy Authentication Required), 503 (Service Unavailable), etc. Application-specific requirements may wish to specify optional headers sent, such as User-Agent, Accept-Charset and Accept-Language.
|
Rationale:
|
Since none of the HTTP 1.1 enhancements (including persistent connections) are required, support of HTTP 1.0 is allowed to provide flexibility for software sourcing.
|
96x1H-IPI.5.1.1450: Hypertext Transfer Protocol (HTTP) server |
Approved
|
An HTTP server will be supported for IPv4 only as specified either for HTTP 1.0 in IETF RFC 1945 [7.3-23a] or for HTTP 1.1 in IETF RFC 2616 [7.3-23b], and as clarified below and by application-specific requirements.
The HTTP server will use TCP as a transport-layer protocol, and it will only support one connection at a time. The port will be closed by default and will only be opened for listening based on explicit application-specific requirements. The HTTP server will not support persistent connections, TLS/SSL connections or Basic or Digest access authentication, and it will not send cookies to the client. Only received POST methods will be supported, and the content will be processed in an application-specific manner based on the Request-URI in the Request-Line (see Section 5.1 of either RFC 1945 or RFC 2616), which identifies the application. A 403 (Forbidden) response will be sent in reply to any other methods received, and in reply to a POST method with an invalid Request-URI. The TCP connection will be closed after an HTTP response is transmitted (i.e., a FIN will be sent). The HTTP server will not process more than one HTTP message per connection or more than two connection requests per second.
|
Note:
|
The only application that currently uses the HTTP server is push (see [7.1-6]).
|
96x1H-IPI.5.1.1500: Transport Layer Security (TLS) / Secure Sockets Layer (SSL) |
Approved
|
TLS 1.0 will be supported as specified in IETF RFC 2246 [7.3-26b], and as further clarified below.
TLS will use TCP (see 96x1H-IPI.5.1.500) as a transport-layer protocol.
SSL 3.0 [7.3-26a] will also be supported, and application software will be able to specify whether negotiation to SSL 3.0 is to be allowed. SSLv1 and SSLv2 will not be supported.
A TLS or SSL connection will only be established if the digital certificate received from the other entity is successfully authenticated as specified in 96x1H-IPI.5.1.1550.
|
|
At least the following cipher suites will be supported:
TLS_RSA_WITH_NULL_SHA
TLS_RSA_WITH_NULL_MD5
TLS_RSA_EXPORT_WITH_RC4_40_MD5
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
The equivalent SSL 3.0 cipher suites will also be supported.
Application-specific requirements must specify which cipher suite(s) are to be allowed for each application.
|
Approved
for R6.2.1+
|
If an identity certificate is stored in the telephone, it will be used during the TLS handshake as required when the telephone is acting as a server, and will be transmitted on request when the telephone is acting as a client.
|
Note:
|
An identity certificate can be stored in the telephone using SCEP as specified in 96x1H-IPI.5.1.1600.
|
Note:
|
Since the CONNECT method is not supported (see 96x1H-IPI.5.1.1400), HTTPS connections will not work through a proxy server.
|
Note:
|
TLS 1.0 is actually an enhancement of SSL 3.0, published by Netscape Communications, and it uses the same TCP port and supports negotiation for backwards compatibility with SSL. The acronyms TLS and SSL are often used interchangeably, which can also lead to confusion. In fact, even though the IETF document is titled “The TLS Protocol Version 1.0”, TLS identifies itself as version 3.1 during negotiation of the version to be used. SSL 3.0 is very similar to TLS, and is probably still supported by more web servers than TLS. SSLv1 and SSLv2 are earlier and less secure versions of SSL. While some web servers may still support them for backward compatibility, there is no reason for endpoints to support them going forward.
|
Note:
|
The TLS_RSA_WITH_NULL_SHA cipher suite uses the Rivest-Shamir-Adelman public key algorithm for authentication and key exchange, provides no encryption, and uses the Federal Information Processing Standard Secure Hash Algorithm to generate a message digest for authenticating the content of exchanged messages.
|
Note:
|
TLS cipher suite names use the format: TLS_xxx_WITH_yyy_zzz, where xxx indicates the authentication and key exchange algorithms, yyy indicates the encryption algorithm, and zzz indicates the message digest algorithm (see RFC 2246, pp.61-62).
|
Rationale:
|
The initial application of TLS for configuration file authentication (see 96x1H-IPI.3.1.100, flowchart 3a-1) assumes use of TLS 1.0 on an Avaya server with an Avaya-signed certificate and the TLS_RSA_WITH_NULL_SHA cipher suite, so support for SSL, additional Certificate Authority certificates and additional cipher suites is not necessary.
Even though RFC 2246 requires support for the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite for compliance (Section 9, p.48), it is not required above because it is not exportable, the algorithms would consume significant additional memory, and interworking with arbitrary servers is not required.
|
96x1H-IPI.5.1.1550: Digital signature and certificate authentication |
Approved
|
X.509v3 certificates will be supported as specified in ITU-T Recommendation X.509-2005 [7.4-12c], with an RSA key length of 1024 or 2048 bits, signed as specified in RFC 3447 [7.3-32a], using the SHA-1 message digest algorithm specified by FIPS PUB 180-2 [7.5-3], and algorithm identifiers as specified in RFC 3279 [7.3-32e].
|
|
Other devices’ identity certificates will be authenticated as specified below.
|
|
Note:
|
Dates and times specified in certificates are in Greenwich Mean or Universal Time (GMT/UT) but the telephone does not know the offset of its local clock relative to GMT/UT, so validity intervals are checked assuming that there is no offset, which may result in an error of up to 12 hours.
|
Note:
|
For a certificate to be recognized as being signed by an Avaya CA certificate, a copy of the CA certificate must be built into the software, as specified by 96x1PKG.2.3.300 in COMPAS ID 143545 [7.1-10] for the Avaya Product Root CA certificate. Trusted certificates downloaded from a file server using the TRUSTCERTS parameter (see flowcharts 3a-3 and 3b-3 in 96x1H-IPI.3.1.100) will supersede built-in certificates, so copies of the built-in CA certificates are included in software distribution packages as specified by 96x1PKG.2.1.300 in COMPAS ID 143545 [7.1-10] so that they can be downloaded via TRUSTCERTS along with customer-provided third-party certificates if desired.
|
96x1H-IPI.5.1.1600: Simple Certificate Enrollment Protocol (SCEP) |
Approved
|
SCEP will be supported as specified in [7.3-34a], which also references PKCS #7 [7.3-34b], PKCS #9 [7.3-34c] and PKCS #10 [7.3-34d], and as further clarified below.
When SCEP is initiated (see flowchart 4c in 96x1H-IPI.3.1.100), the telephone will attempt to contact an SCEP server via HTTP, using the value of the configuration parameter MYCERTURL as the URI.
SCEP will support the use of an HTTP proxy server as specified in 96x1H-IPI.5.1.1400.
|
Note:
|
SCEP uses HTTP as a transport protocol (see Section 3 of [7.3-34a]).
|
Note:
|
If the SCEP server is outside of the corporate firewall, telephones connecting to the corporate network over a VPN connection could be configured to establish the SCEP connection outside of the VPN tunnel (via NVIPSECSUBNET, see 96x1H-IPI.5.1.310) rather than establishing them inside the tunnel and using an HTTP proxy server to get back outside of the corporate firewall.
|
Approved
|
An RSA private/public key pair will be created by the telephone, where each key has a length equal to the value of MYCERTKEYLEN. The public key and the following values will be used in the certificate signing request:
the value of MYCERTCAID is used as the Certificate Authority Identifier;
the value of MYCERTCN is used to specify the Common Name of the Subject of the certificate, which must be unique for each telephone; if the value of MYCERTCN contains the string “$SERIALNO”, “$SERIALNO” will be replaced by the value of SERIALNO (see 96x1H-IPI.2.1.1400), and if the value of MYCERTCN contains the string “$MACADDR”, “$MACADDR” will be replaced by the value of MACADDR (see 96x1H-IPI.2.1.100) without the colon separators (values of MYCERTCN that do not contain “$SERIALNO” or “$MACADDR” will be ignored);
the value of MYCERTDN is used as additional information to specify the Subject of the certificate (which can be common to multiple telephones, such as the Organization, Organizational Unit, Location, State and Country); if the value of MYCERTDN contains the string “$SERIALNO”, “$SERIALNO” will be replaced by the value of SERIALNO, and if the value of MYCERTDN contains the string “$MACADDR”, “$MACADDR” will be replaced by the value of MACADDR without the colon separators;
|
|
the value of SCEPPASSWORD, if non-null, will be included in a challengePassword attribute, subject to the following: if the value of SCEPPASSWORD contains the string “$SERIALNO”, “$SERIALNO” will be replaced by the value of SERIALNO, and if the value of SCEPPASSWORD contains the string “$MACADDR”, “$MACADDR” will be replaced by the value of MACADDR without the colon separators;
|
|
When SCEP is initiated, the SCEP screen will be displayed on the reserved text lines as follows:
|
|
|
SCEP: s secs
|
|
|
where s is the number of seconds that have elapsed since SCEP was initiated. This text will remain on the display until it is replaced by a subsequent display.
|
|
If the attempt to contact the SCEP server is not successful,
|
|
or if the HTTP request fails or is abandoned,
|
|
the telephone will continue with start-up, and it will not try to contact the SCEP server again unless it is reset or power-cycled.
|
|
Otherwise,
|
|
if the value of MYCERTWAIT is “1”,
SCEP will remain in progress until the certificate signing request is granted or rejected.
If the certificate is signed and returned, “SCEP: Successful” will be displayed on the top line for at least one second, it will remain on the display until it is replaced by a subsequent display, the TCP connection to the SCEP server will be terminated, and the telephone will continue with start-up.
If the certificate signing request is rejected, “SCEP: Failed” will be displayed on the top line for at least one second, it will remain on the display until it is replaced by a subsequent display, the TCP connection to the SCEP server will be terminated, and the telephone will continue with start-up.
|
|
if the value of MYCERTWAIT is “0”,
SCEP will remain in progress until the certificate signing request is granted or rejected or until a response is received indicating that the request is pending for manual approval.
If the certificate signing request is granted or rejected, the same text will be displayed as specified above.
|
|
If a response is received indicating that the request is pending, “SCEP: In progress” will be displayed on the top line for at least one second, it will remain on the display until it is replaced by a subsequent display, the TCP connection to the SCEP server will be terminated, and the telephone will continue with start-up. The telephone will attempt to contact MYCERTURL every 2 minutes as specified above (but in the background without displaying anything) until the request is granted or rejected.
|
|
If the identity certificate is successfully signed and returned, it will be saved in non-volatile memory along with the value of MYCERTURL that was used to obtain it.
When the date and time of the telephone's clock reaches (or exceeds, if the telephone starts up after) the date and time that corresponds to the expiration of a percentage of the certificate's valid lifetime (as specified in the certificate's Validity object) that is equal to the value of MYCERTRENEW, the telephone will attempt to contact MYCERTURL every 5 minutes (but in the background without displaying anything) to renew the certificate, until the request for a renewal is granted or rejected.
|
Note:
|
Dates and times specified in certificates are in Greenwich Mean or Universal Time (GMT/UT) but the telephone does not know the offset of its local clock relative to GMT/UT, so renewal is initiated assuming that there is no offset, which may result in renewal starting up to 12 hours earlier or later than the specified time. Since certificate lifetimes are typically on the order of a year or more, ignoring the offset relative to GMT/UT is expected to be well within the precision of the value of MYCERTRENEW. However, if a certificate with a very short lifetime is used for testing purposes, it should be understood that the telephone will initiate the renewal as if the local time is GMT/UT.
Even though the value of MYCERTRENEW is allowed to be set to values that correspond to from 1% to 99% of the certificate's lifetime, SCEP servers typically do not expect, and may reject, renewal requests that are received before at least 50% of the certificate's lifetime has expired. Setting MYCERTRENEW to values less than 50 is supported for testing purposes, but corresponding server administration may be required.
|
Rationale:
|
This implementation of SCEP is only intended to support manual or automated certificate enrollment (see Sections 2.1.1.2.1 and 2.1.1.2.2 of [7.3-34a]) in a “staging” environment (a special-purpose isolated network that may only consist of the telephone being directly connected to a PC that supports multiple services, i.e., DHCP, HTTP and SCEP), and it is assumed that all trusted CA certificates are downloaded via the TRUSTCERTS parameter (see flowcharts 3a-3 and 3b-3 in 96x1H-IPI.3.1.100). Therefore, a “fingerprint” generated on the certificate request is not displayed on the telephone in manual enrollment mode (even though it is a MUST requirement in Section 2.1.1.2.1 of [7.3-34a]), and the telephone does not do a “GetCACert” operation as described in Section 5.5 of [7.3-34a]. Also, since all trusted certificates must be self-signed (see flowcharts 3a-3 and 3b-3 in 96x1H-IPI.3.1.100), SCEP “RA mode” is not supported.
|
96x1H-IPI.5.1.1700: Secure Shell (SSH) Protocol |
Approved
for R6.2+
|
An SSHv2 server will be supported as specified in IETF RFCs 4250, 4252, 4253, 4254, 4256 and 4716 [7.3-36a,c,d,e,g,o], and as further clarified below.
SSHv1 will not be supported.
|
Note:
|
The version of SSH specified by the above RFCs is sometimes referred to as SSH-2 or SSHv2, but in those documents it is usually referred to only as SSH, except in Section 4.2 of RFC 4253 and in Sections 3.2 and 3.6 of RFC 4716.
|
Rationale:
|
Support of SSHv2 is required by 147576-070-M (SSH Version) in the internal Avaya Remote Access standard [7.1-16g].
Disabling SSHv1 is required by 147513-060-M (Key Management) in the internal Avaya Encryption standard [7.1-16o].
|
Approved
for R6.2+
|
TCP/IP port forwarding will not be supported (see Section 7 of IETF RFC 4254 [7.3-36e]).
|
Rationale:
|
Not supporting port forwarding is required by 147576-100-R (Host-Hopping Protection) in the internal Avaya Remote Access standard [7.1-16g].
|
Note:
|
SSH client is supported to allow proper operation of SCP client on the phone. Still SSH client can not be used by a non-privileged user from initiating an interactive TCP connection since SSH server requires craft login using ASG mechanism and console port activation requires PROCPSWD knowledge.
|
Approved
for R6.2+
|
Only the aes128-cbc and 3des-cbc cipher suites will be supported, with aes128-cbc listed as the most preferred.
Only the hmac-sha1 and hmac-sha1-96 Message Authentication Codes (MACs) will be supported, with hmac-sha1 listed as the most preferred.
|
Rationale:
|
Section 6.3 of RFC 4253 [7.3-36d] requires that 3des-cbc be supported and recommends that aes128-cbc be supported, and Section 6.4 requires that hmac-sha1 be supported and recommends that hmac-sha1-96 be supported.
|
Approved
for R6.2+
|
A common (non-unique) 1024-bit RSA host key (and the corresponding private key) will be included in the software. The private key will be encrypted in the software distribution package and the decryption key will be obscured as much as possible.
|
Rationale:
|
Use of common host and private keys is intended to make it easier for the user of the SSH client to verify the host key, because the same fingerprint will be displayed for all telephones, and because it will not be necessary to display the host key or its fingerprint to the telephone user or to query the telephone user for that value, even though it is less secure to include the private key in the software distribution package.
|
Approved
for R6.2+
|
If the value of SSH_ALLOWED is “0”, the TCP port specified for SSH (see 96x1H-IPI.5.1.500) will be closed.
If the value of SSH_ALLOWED is “1”, the TCP port specified for SSH will be open.
|
Approved
for R6.4+
|
If the value of SSH_ALLOWED is "0", the value of SSH_STATUS will be set to "0".
If the value of SSH_ALLOWED is "1", the value of SSH_STATUS will be set to "1" when an SSH connection is not established, and the value of SSH_STATUS will be set to "2" when an SSH connection is established.
If the value of SSH_ALLOWED is "2",
- SSH_STATUS will be set to “0” after reboot/powerup and will be set to “1” when SSH server is enabled from local CRAFT procedure.
- the TCP port specified for SSH will be closed when the value of SSH_STATUS is "0", and open when the value of SSH_STATUS is not "0";
- the value of SSH_STATUS will be set to "2" when an SSH TCP connection is established, and the value of SSH_STATUS will be set to "0" when an SSH TCP connection is terminated;
- if the value of SSH_IDLE_TIMEOUT is not "0", a countdown timer will be started after being initialized to the number of minutes specified by SSH_IDLE_TIMEOUT, and the TCP port will be closed if a connection has not been established by the time the timer expires.
|
|
Only one SSH connection and one session will be supported at a time.
Challenge/response authentication will be supported using the generic interactive authentication messages specified in RFC 4256 [7.3-36g]. The challenge message will be as specified below:
|
|
|
byte
string
string
string
int
string
boolean
|
SSH_MSG_USERAUTH_INFO_REQUEST
“”
“”
“”
1
“Response: ”
TRUE
|
|
where consists of 10 ASCII numeric characters generated by the telephone using ASG software. Authentication will succeed only if the user name in the authentication request is “craft”,
|
Approved
for R6.2+
|
and if the response returned by the SSH client matches the response string generated using ASG software with a fixed 256-bit AES key that is built into the telephone software. The AES key will be encrypted in the software distribution package and the decryption key will be obscured as much as possible.
|
Note:
|
Responses will also consist of 10 ASCII numeric characters.
|
Rationale:
|
Challenge/response authentication is being supported initially because server support is required for secure configuration of passwords for password authentication. ASG (Avaya Security Gateway) is used by Avaya Services to access other Avaya products, and a tool already exists to generate responses.
|
Approved
for R6.2+
|
If authentication succeeds, and if the value of SSH_IDLE_TIMEOUT is not “0”, a countdown timer will be started after being initialized to the number of minutes specified by SSH_IDLE_TIMEOUT. Any time an SSH packet is transmitted or received by the SSH server, the timer will be reinitialized to the number of minutes specified by the value of SSH_IDLE_TIMEOUT. If the timer expires, the SSH connection will be terminated.
SSH users will not be given root access, and it will not be possible to escalate privileges once they have access. Access will be read-only and will not support access to any private data (see 96x1H-IPI.5.2.400).
|
Approved
for R6.4+
|
SSH users will be able to perform the following operation
create a debug report
View all log files (including the ability to unzip them if needed)
Ping
tcpdump
Ps
topnetstat
scp to upload files from the phone
dmesg
ftpput
traceroute
meminfo
eth mib show/clear
eth arl table show
On the other hand, the following operations could not be performed
ft
start telnet server (telnetd)
change passwords or ownerships
add users or groups
move/remove location of existing directories
format partition, mount
change permission of files (chmod)
su
interrupt the ssh functionality (creating key, adding keys, spawning daemon, etc.)
wget
|
Rationale:
|
Requirement 147873-055-M in [7.1-16m] specifies that there shall be no direct logins to accounts with the highest privilege level (e.g., root account).
|
Approved
for R6.2+
|
An SCP (Secure Copy) client and server will be enabled for use via SSH.
|
Rationale:
|
SCP is required for remote access by requirement 147576-070-M in [7.1-16g].
|
Approved
for R6.2+
|
A security warning banner message will be sent to the client before authentication is attempted, per Section 5.4 of IETF RFC 4252 [7.3-36c]. The language tag will be null. If a file has been downloaded and stored in the telephone based on the value of SSH_BANNER_FILE, the content of that file will be sent as the banner message. If such a file has not been downloaded, the following default banner message will be sent:
|
|
“This system is restricted solely to authorized users for legitimate business purposes only. The actual or attempted unauthorized access, use, or modification of this system is strictly prohibited.
Unauthorized users are subject to company disciplinary procedures and or criminal and civil penalties under state, federal, or other applicable domestic and foreign laws.
The use of this system may be monitored and recorded for administrative and security reasons. Anyone accessing this system expressly consents to such monitoring and recording, and is advised that if it reveals possible evidence of criminal activity, the evidence of such activity may be provided to law enforcement officials. All users must comply with all corporate instructions regarding the protection of information assets.”
|
Rationale:
|
Support of a customer configurable security warning banner on remote access logins is required by 147873-025-M in the internal Avaya Authentication, Authorization & SSO standard [7.1-16m].
|
Directory: public -> downloadFile.jsp?file= -> resources -> sites -> AVAYA -> content -> live -> SOLUTIONSpublic -> The german unification, 1815-1870public -> Preparation of Papers for ieee transactions on medical imagingpublic -> Harmonised compatibility and sharing conditions for video pmse in the 7 9 ghz frequency band, taking into account radar usepublic -> Adjih, C., Georgiadis, L., Jacquet, P., & Szpankowski, W. (2006). Multicast tree structure and the power lawpublic -> Duarte, G. Pujolle: fits: a flexible Virtual Network Testbed Architecturepublic -> Swiss Federal Institute of Technology (eth) Zurich Computer Engineering and Networks Laboratorypublic -> Tr-41. 4-03-05-024 Telecommunicationspublic -> Chris Young sets 2016 “I’m Comin’ Over” Tour headlining datesSOLUTIONS -> CM: How to enable 'auto answer' feature
Share with your friends: |
