WS-Security
ONVIF Core Specification v2.2
5.12 Security
The services defined in ONVIF shall be protected using either digest authentication according to [RFC 2617] or the WS-Security framework,
depending on the security policy. The framework allows several
different security models using tokens. The following tokens are
currently defined:
User name token profile [WS-UsernameToken]
X.509 security token profile [WS-X.509Token]
SAML token profile [WS-SAMLToken]
Kerberos token profile [WS-KerberosToken]
Rights Expression Language (REL) Token Profile [WS-RELToken]
User name token profile [WS-UsernameToken] X.509 security token profile [WS-X.509Token] SAML token profile [WS-SAMLToken] Kerberos token profile [WS-KerberosToken] Rights Expression Language (REL) Token Profile [WS-RELToken]
A client should not simultaneously supply authentication credentials on both the HTTP level and the WS level.
If a server receives a web service request
that contains authentication credentials on both the HTTP level and the
WS level, it shall first validate the credentials provided on the HTTP
layer. If this validation was successful, the server shall finally
validate the authentication credentials provided on the WS layer.
Both digest authentication and the user
name token profile give only a rudimentary level of security. In a
system where security is important, it
is recommended to always configure the device for TLS-based access (see
10.1). Digest authentication or the user name token message level
security combined with TLS, with client and server
authentication, protected transport level security give an acceptable
level of security in many systems.
일차적으로 우리는 WS-Username Token만을 지원하기로 한다.
By default, the device should enforce the following default access policy, which gives an acceptable level of security in many systems.
| Administrator | Operator | User | Anonymous | |
| PRE_AUTH | X | X | X | X |
| READ_SYSTEM | X | X | X | |
| READ_SYSTEM_SECRET | X | |||
| WRITE_SYSTEM | X | |||
| UNRECOVERABLE | X | |||
| READ_MEDIA | X | X | X | |
| ACTUATE | X | X |
5.12.2 Username token profile
A client shall use both nonce and timestamps as defined in [WS-UsernameToken]. The server shall reject any Username Token not using both nonce and creation timestamps.
5.12.2.1 Password derivation
Denote by UA an arbitrary user. Denote by P_UA the password value used by user UA to access the devices in the system. Furthermore, denote, by NEP, the end device service point reference value for a particular device in the system. Finally, denote by PE_UA the password equivalent used by the client to access a particular device in the system. The client should calculate the PE_UA as follows:
PE_UA = base64(HMAC_SHA-1(UA+P_UA,NEP+”ONVIF password”)),
HMAC_SHA-1 is the algorithm specified in [RFC 2104] using SHA-1 [FIPS 180-2] as the underlying algorithm. The key value to use for the HMAC function is the user password, P_UA, directly mapped to its binary equivalent. Similar, the value PE_UA should be mapped to its ASCII equivalent before transmitting it to the device.
base64 is described in [RFC 3548], note that the result of the base64 operation is the actual password equivalent and shall be used as it is.
5.12.2.1.1 Example
Assume the following username and password is used by the client (ASCII): “user” and “VRxuNzpqrX”, i.e.,
UA = 75 73 65 72
P_UA = 56 52 78 75 4E 7A 70 71 72 58
Next, assume the device has the following device service end point reference value:
Urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6.
Then the password equivalent to be used will be then calculated as:
PE_UA = base64(HMAC_SHA-1(UA+ P_UA,NEP+”ONVIF password”)) =
base64(HMAC_SHA-1(75736572565278754E7A70717258,
F81D4fAE7DEC11D0A76500A0C91E6BF64F4E5649462070617373776F7264)) =
base64(16 E5 C5 A9 4D DE 8A 97 6D D7 2F 55 78 5F C2 D0 6B DA 53 4A)=
FuXFqU3eipdt1y9VeF/C0GvaU0o=
The resulting password equivalence “FuXFqU3eipdt1y9VeF/C0GvaU0o=” is the password that
shall be used by a client both for configuring the user credential on the particular device and
then also for accessing the device.
OASIS 200401 WSS Uername Token profile 1.0
2.2 Namespaces
| Prefix | NameSpace |
| S11 | http://schemas.xmlsoap.org/soap/envelope/ |
| S12 | http://www.w3.org/2003/05/soap-envelope |
| wsse | http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd |
| wsu | http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd |
3.1 Usernames and Passwords
Having a type of wsse:PasswordText, wsse:PasswordDigest merely implies that the information held in the password is “in the clear”, as opposed to holding a “digest” of the information.
Password_Digest = Base64 ( SHA-1 ( nonce + created + password ) )
The following illustrates the XML syntax of this element:
<wsse:UsernameToken wsu:Id="Example-1">
<wsse:Username> ... </wsse:Username>
<wsse:Password Type="..."> ... </wsse:Password>
<wsse:Nonce EncodingType="..."> ... </wsse:Nonce>
<wsu:Created> ... </wsu:Created>
</wsse:UsernameToken>
The following describes the attributes and elements listed in the example above:
/wsse:UsernameToken/wsse:Password
This optional element provides password information (or equivalent such as a hash). It is RECOMMENDED that this element only be passed when a secure transport (e.g.
HTTP/S) is being used or if the token itself is being encrypted.
/wsse:UsernameToken/wsse:Password/@Type
This optional URI attribute specifies the type of password being provided. The table below identifies the pre-defined types (note that the URI fragments are relative to the URI
for this specification).
#PasswordText (default) The actual password for the username, the password hash, or derived password or S/KEY.
This type should be used when hashed password equivalents that do not rely on a nonce or creation time are used, or when a digest algorithm other than SHA1 is used.
#PasswordDigest The digest of the password (and optionally nonce and/or creation timestame) for the username using the algorithm described above.
/wsse:UsernameToken/wsse:Password/@{any}
This is an extensibility mechanism to allow additional attributes, based on schemas, to be added to the element.
/wsse:UsernameToken/wsse:Nonce
This optional element specifies a cryptographically random nonce. Each message including a <wsse:Nonce> element MUST use a new nonce value in order for web
service producers to detect replay attacks.
/wsse:UsernameToken/wsse:Nonce/@EncodingType
This optional attribute URI specifies the encoding type of the nonce (see the definition of <wsse:BinarySecurityToken> for valid values). If this attribute isn't specified then
the default of Base64 encoding is used.
/wsse:UsernameToken/wsu:Created
The optional <wsu:Created> element specifies a timestamp used to indic
The following example illustrates the use of this element. In this example the password is sent as clear text and therefore this message should be sent over a confidential channel:
<S11:Envelope xmlns:S11="..." xmlns:wsse="...">
<S11:Header>
...
<wsse:Security>
<wsse:UsernameToken>
<wsse:Username>Zoe</wsse:Username>
<wsse:Password>IloveDogs</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
...
</S11:Header>
...
</S11:Envelope>
The following example illustrates using a digest of the password along with a nonce and a creation timestamp:
<S11:Envelope xmlns:S11="..." xmlns:wsse="..." xmlns:wsu= "...">
<S11:Header>
...
<wsse:Security>
<wsse:UsernameToken>
<wsse:Username>NNK</wsse:Username>
<wsse:Password Type="...#PasswordDigest">
weYI3nXd8LjMNVksCKFV8t3rgHh3Rw==
</wsse:Password>
<wsse:Nonce>WScqanjCEAC4mQoBE07sAQ==</wsse:Nonce>
<wsu:Created>2003-07-16T01:24:32Z</wsu:Created>
</wsse:UsernameToken>
</wsse:Security>
...
</S11:Header>
...
</S11:Envelope>
댓글 없음:
댓글 쓰기