Kindly clarify on the following queries about the OPC UA specification Part 4 Services,
From my understanding after the GetEndpoints Service messages, the client sends a OpenSecureChannel request to the server which means the request is signed or signed & encrypted according the security policy in the desired endpoint. I saw the following lines in the specification Part 4 Services, pg.no 33,
The OpenSecureChannel request and response Messages shall be signed
with the sender’s Certificate. These Messages shall always be
encrypted. If the transport layer does not provide encryption, then
these Messages shall be encrypted with the receiver’s Certificate.
In this it is mentioned that the messages shall always be encrypted. How does it rely on transport layer ?
And I also see another description in the OPC Unified Architecture Book by Wolfgang Mahnke, Stefan-Helmut Leitner, Matthias Damm as follows,
If the certificate is considered as trustworthy, then as the second
step an OpenSecureChannel request secured in accordance to the
Security Policy and the Security Mode is sent to the selected Session
Endpoint of the server. (Chapter 7, pg.no:213)
Here, it highlights that the message is secured in accordance to the Security Policy and Security Mode, so I request a clarification on the scenario if the security mode is sign?
Will the message be encrypted also?
In general, when the MessageSecurityMode is None then the SecurityPolicy ‘must’ be None? What is the exact usage of 'Invalid' MessageSecurityMode?
X509IdentityToken specification Part 4 Services section 7.35.4
This token shall always be accompanied by a signature in the
userTokenSignature parameter of ActivateSession if required by the
SecurityPolicy. The Server should specify a SecurityPolicy for the
UserTokenPolicy if the SecureChannel has a SecurityPolicy of None.
In the first line it is mentioned that ‘if required by the SecurityPolicy’, what is context of ‘if required’ when the userTokenSignature is a required field for X509IdentityToken ? In the second line it is mentioned that a explicit Security Policy is required if the SecureChannel has a SecurityPolicy of None, where ‘None’ means no certificates are exchanged and so X509IdentityToken cannot be used, referring to the following lines in the same specification (Section 5.6.3 ActivateSession, pg.no: 40)?
If the token is an X509IdentityToken then the proof is a signature
generated with private key associated with the Certificate. The data
to sign is created by appending the last serverNonce to the
serverCertificate specified in the CreateSession response.
For your kind information I use the specification released on November 2015 to study. Please clarify.
For the first question, the specification continues with "These requirements for OpenSecureChannel only apply if the securityPolicyUri is not None". So the answer is that a SecureChannel will both sign and encrypt the OpenSecureChannelRequest/Response for any MessageSecurityMode, except MessageSecurityMode.None.
For the second question, if MessageSecurityMode is None, then the Security policy is none. There is no usage of MessageSecurityMode.Invalid as far as I can find.
For the third question, if the securityPolicyUri is None, then no application certificates are exchanged. The client can provide a UserIdentity by a X509IdentityToken. The token consists of a X509Certificate and a signature. The signature is generated by appending the server nonce to the server certificate and signing with the user certificate's private key.
Related
I'm using DTLS v1.0 to communicate with a server. I'm having some trouble figuring out exactly what to do to generate the certificate verify message. I've been reading the RFCs (DTLSv1.0 and TLS1.1, which DTLS v1.0 is based on) but they're somewhat non-specific when it comes to this particular message.
I see the structure of the message is as below, and I know the signature type is RSA.
struct {
Signature signature;
} CertificateVerify;
The Signature type is defined in 7.4.3.
CertificateVerify.signature.md5_hash
MD5(handshake_messages);
CertificateVerify.signature.sha_hash
SHA(handshake_messages);
Based on what I've read it seems to be a concatenation of the sha1 hash and the md5 hash of all the previous messages sent and received (up to and excluding this one) and then RSA signed.
The piece that's got me a bit confused though is how to assemble the messages to hash them.
Does it use each fragment piece or does it use the re-assembled messages? Also, what parts of the messages does it use?
The RFC for TLS 1.1 says
starting at client hello up to but not including this message,
including the type and length fields of the handshake messages
but what about the DTLS specific parts like message_seq, fragment_offset, and fragment_length, do I include them?
UPDATE:
I have tried doing as the RFC for DTLS 1.2 shows (meaning keeping the messages fragmented, using all the handshake fields including DTLS specific fields, and not including the initial Client Hello or Hello Verify Request messages) but I am still receiving "Bad Signature". I do believe I'm signing properly, so it's my belief that I'm concatenating the data improperly to be signed.
For DTLS 1.2 it is defined. And reading RFC 4347, my impression is, RFC 6347 doesn't differ, it clarifies the calculations.
RFC 6347, 4.2.6. CertificateVerify and Finished Messages
RFC 4347, 4.2.6. Finished Messages
I'm developing a product that need to integrate with RADIUS server as an authentication method.
When configuring the RADIUS server (IP Address, Port, Shared Secret) I would like to do a "test" in order to check that the configuration is valid - The server is available and it is indeed a RADIUS server, Shared secret is OK.
I did some research on how to do it,
My options are:
Send Access-Request message with fictional user name and password to the RADIUS server
Send Status-Server message to the RADIUS server
RFC 5997 introduces the use of Status-Server Packets in the RADIUS protocol.
This packet extension enabling clients to query the status of a RADIUS server.
The Status-Server is marked as experimental and as Informational RFC rather than as a Standards-Track RFC
My questions are:
Which are the most common \ in use RADIUS server vendors ? MS NPS, FreeRADIUS, Other?
Are these vendors supporting Status-Server request - Do they implementing this packet type ?
If i will use Access-Request, I will receive "Access-Reject" with a failure message in "Reply-Message" attribute. Can i understand the reason for the refusal from that text message? Is there any list of error codes\messages that are part of the Standard ?
Thanks a lot,
Yossi Zrahia
Ad 1) Exact (or even estimate) numbers are hard to come by, but you should expect to encounter FreeRADIUS, Microsoft NPS, Radiator and maybe Cisco ACS/ISE.
Ad 2) FreeRADIUS, Radiator support it. Microsoft NPS and Cisco ACS/ISE do not. If your "test" is used once (upon configuring) I would use option 1 with the Access-Request. If you wish to periodically check the availability and configuration of a RADIUS server, I would suggest implementing both options and allow for configuration of the check as part of the RADIUS configuration:
IP: 1.2.3.4
Port: 1812
Shared Secret: U7tr453cur3
Servercheck: [x] Status-Server
[ ] Access-Request
Ad 3) From RFC2865, section 5.18 (Reply-Message):
"[...] This Attribute indicates text which MAY be displayed to the user. [...] When used in an Access-Reject, it is the failure message. It MAY indicate a dialog message to prompt the user before another Access-Request attempt. [...] The Text field is one or more octets, and its contents are implementation dependent. It is intended to be human readable, and MUST NOT affect operation of the protocol. It is recommended that the message contain UTF-8 encoded 10646 [7] characters."
There apparently are no standard messages specified; however if IP, Port or Shared Secret are configured incorrectly you should not get a response at all, because RFC 2865 specifies:
"A request from a client for which the RADIUS server does not have a shared secret MUST be silently discarded."
I have problems verifying a SAML-response I get form an ADFS Server. I get the response as an url like CALLBACK_URL?SAMLResponse=ENCODED_XML&Signature=SIGNATURE_VALUE&SigAlg=SIGNATURE_ALGORITHMwhile SIGNATURE_ALGORITHM is http://www.w3.org/2001/04/xmldsig-more#rsa-sha256. I managed to decode the response but I am not able to find a way to verify the response using the given signature.
My main problem is that the signature has a very unexpected format. Because of the given signature algorithm I expect the signature to have a length of 32 bytes but what I get when I base64-decode the signature is a string with length 256.
I expect that decoding the signature using base64 is not sufficient. Unfortunately I have not been able to find out what to do next so far. So my question is: What do I have to do to correctly decode the signature to be able to verify it?
I believe you're conflating a hash with a signature.
The signature takes the hash of the message as input and encrypts it with a key. In your case the SigAlg parameter indicates that the 32 byte hash of the SAML message is encrypted with (apparently) a 2048 bits RSA private key, possibly using PKCS#1 v1.5 padding as described in https://www.rfc-editor.org/rfc/rfc6931#section-2.3.2 resulting in a 256 byte signature that can be verified with the associated 2048 bits RSA public key of the sender.
Apart from that: I assume your referring to a SAML request rather than a SAML response since the latter must not be sent by using the HTTP redirect binding as written down in the Web Browser SSO Profile specification, page 16: https://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf (top of the page):
Identity Provider issues to Service Provider In step 5, the identity provider issues a message to be delivered by
the user agent to the service provider. Either the HTTP POST, or HTTP
Artifact binding can be used to transfer the message to the service
provider through the user agent. The message may indicate an error, or
will include (at least) an authentication assertion. The HTTP Redirect
binding MUST NOT be used, as the response will typically exceed the
URL length permitted by most user agents.
I don't understand why JWS unprotected headers exist.
For some context: a JWS unprotected header contains parameters that are not integrity protected and can only be used per-signature with JSON Serialization.
If they could be used as a top-level header, I could see why someone could want to include a mutable parameter (that wouldn't change the signature). However, this is not the case.
Can anyone think of a use-case or know why they are included in the spec?
Thanks!
JWS Spec
The answer by Florent leaves me unsatisfied.
Regarding the example of using a JWT to sign a hash of a document... the assertion is that the algorithm and keyID would be "sensitive data" that needs to be "protected". By which I suppose he means "signed". But there's no need to sign the algorithm and keyID.
Example
Suppose Bob creates a signed JWT, that contains an unprotected header asserting alg=HS256 and keyid=XXXX1 . This JWT is intended for transmission to Alice.
Case 1
Suppose Mallory intercepts the signed JWT sent by Bob. Mallory then creates a new unprotected header, asserting alg=None.
The receiver (Alice) is now responsible for verifying the signature on the payload. Alice must not be satisfied with "no signature"; in fact Alice must not rely on a client (sender) assertion to determine which signing algorithm is acceptable for her. Therefore Alice rejects the JWT with the contrived "no signature" header.
Case 2
Suppose Mallory contrives a header with alg=RS256 and keyId=XXX1. Now Alice tries to validate the signature and finds either:
the algorithm is not compliant
the key specified for that algorithm does not exist
Therefore Alice rejects the JWT.
Case 3
Suppose Mallory contrives a header with alg=HS256 and keyId=ZZ3. Now Alice tries to validate the signature and finds the key is unknown, and rejects the JWT.
In no case does the algorithm need to be part of the signed material. There is no scenario under which an unprotected header leads to a vulnerability or violation of integrity.
Getting Back to the Original Question
The original question was: What is the purpose of an unprotected JWT header?
Succinctly, the purpose of an unprotected JWS header is to allow transport of some metadata that can be used as hints to the receiver. Like alg (Algorithm) and kid (Key ID). Florent suggests that stuffing data into an unprotected header could lead to efficiency. This isn't a good reason. Here is the key point: The claims in the unprotected header are hints, not to be relied upon or trusted.
A more interesting question is: What is the purpose of a protected JWS header? Why have a provision that signs both the "header" and the "payload"? In the case of a JWS Protected Header, the header and payload are concatenated and the result is signed. Assuming the header is JSON and the payload is JSON, at this point there is no semantic distinction between the header and payload. So why have the provision to sign the header at all?
One could just rely on JWS with unprotected headers. If there is a need for integrity-protected claims, put them in the payload. If there is a need for hints, put them in the unprotected header. Sign the payload and not the header. Simple.
This works, and is valid. But it presumes that the payload is JSON. This is true with JWT, but not true with all JWS. RFC 7515, which defines JWS, does not require the signed payload to be JSON. Imagine the payload is a digital image of a medical scan. It's not JSON. One cannot simply "attach claims" to that. Therefore JWS allows a protected header, such that the (non JSON) payload AND arbitrary claims can be signed and integrity checked.
In the case where the payload is non-JSON and the header is protected, there is no facility to include "extra non signed headers" into the JWS. If there is a need for sending some data that needs to be integrity checked and some that are simply "hints", there really is only one container: the protected header. And the hints get signed along with the real claims.
One could avoid the need for this protected-header trick, by just wrapping a JSON hash around the data-to-be-signed. For example:
{
"image" : "qw93u9839839...base64-encoded image data..."
}
And after doing so, one could add claims to this JSON wrapper.
{
"image" : "qw93u9839839...base64-encoded image data..."
"author" : "Whatever"
}
And those claims would then be signed and integrity-proected.
But in the case of binary data, encoding it to a string to allow encapsulation into a JSON may inflate the data significantly. A JWS with a non-JSON payload avoids this.
HTH
The RFC gives us examples of unprotected headers as follows:
A.6.2. JWS Per-Signature Unprotected Headers
Key ID values are supplied for both keys using per-signature Header Parameters. The two JWS Unprotected Header values used to represent these key IDs are:
{"kid":"2010-12-29"}
and
{"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"}
https://datatracker.ietf.org/doc/html/rfc7515#appendix-A.6.2
The use of kid in the example is likely not coincidence. Because JWS allows multiple signatures per payload, a cleartext hint system could be useful. For example, if a key is not available to the verifier (server), then you can skip decoding the protected header. The term "hint" is actually used in the kid definition:
4.1.4. "kid" (Key ID) Header Parameter
The "kid" (key ID) Header Parameter is a hint indicating which key was used to secure the JWS. This parameter allows originators to explicitly signal a change of key to recipients. The structure of the "kid" value is unspecified. Its value MUST be a case-sensitive string. Use of this Header Parameter is OPTIONAL.
https://datatracker.ietf.org/doc/html/rfc7515#section-4.1.4
If we look at Key Identification it mentions where you a kid does not have to be integrity protected (ie: part of unprotected headers): (emphasis mine)
6. Key Identification
It is necessary for the recipient of a JWS to be able to determine the key that was employed for the digital signature or MAC operation. The key employed can be identified using the Header Parameter methods described in Section 4.1 or can be identified using methods that are outside the scope of this specification. Specifically, the Header Parameters "jku", "jwk", "kid", "x5u", "x5c", "x5t", and "x5t#S256" can be used to identify the key used. These Header Parameters MUST be integrity protected if the information that they convey is to be utilized in a trust decision; however, if the only information used in the trust decision is a key, these parameters need not be integrity protected, since changing them in a way that causes a different key to be used will cause the validation to fail.
The producer SHOULD include sufficient information in the Header Parameters to identify the key used, unless the application uses another means or convention to determine the key used. Validation of the signature or MAC fails when the algorithm used requires a key (which is true of all algorithms except for "none") and the key used cannot be determined.
The means of exchanging any shared symmetric keys used is outside the scope of this specification.
https://datatracker.ietf.org/doc/html/rfc7515#section-6
Simplified, if you have a message that by somebody modifying the kid will refer to another key, then the signature itself will not match. Therefore you don't have to include the kid in the protected header. A good example of the first part, where the information they convey is to be utilized in a trust decision, is the ACME (aka the Let's Encrypt protocol). When creating an account, and storing the key data, you want to trust the kid. We want to store kid, so we need to make sure it's valid. After the server has stored the kid and can use it to get a key, we can push messages and reference the kid in unprotected header (not done by ACME but possible). Since we're only going to verify the signature, then the kid is used a hint or reference to which kid was used for the account. If that field is tampered with, then it'll point to a nonexistent of completely different key and fail the signature the check. That means the kid itself is "the only information used in the trust decision".
There's also more theoretical scenarios that, knowing how it works you can come up with.
For example: the idea of having multiple signatures that you can pass on (exchange). A signing authority can include one signature that can be for an intermediary (server) and another for the another recipient (end-user client). This is differentiated by the kid and the server doesn't need to verify or even decode the protected header or signature. Or perhaps, the intermediary doesn't have the client's secret in order to verify a signature.
For example, a multi-recipient message (eg: chat room) could be processed by a relay/proxy and using kid in the unprotected header, pass along a reconstructed compact JWS (${protected}.${payload}.${signature}) for each recipient based on kid (or any other custom unprotected header field, like userId or endpoint).
Another example, would be a server with access to many different keys and a cleartext kid would be faster than iterating and decoded each protected field to find which one.
From one perspective, all you're doing is skipping base64url decoding the protected header for performance, but if you're going to proxy/relay the data, then you're not polluting the protected header which is meant for another recipient.
I am using spring-security saml extension to implement the IDP initiated SSO for my application. I am using https protocol and signature/encryption is ON. I dont need SLO/SP-Initiated SSO.
On the transport layer's encryption/decryption (because using HTTPS protocol), I am fine as My web container (SP one) is going to take care of the decryption part. And this certificate could be different then SP's certifiate.
At the SP end, I need the IDP's public key to verify the signature on SAMLAuthResponse Msg, which I have as part of the IDP's metadata file...so no issues here.
Couple of qns:
For decryption of the SAMLAuthResponse Msg, Do I need SP's
certificate's private key?
And If I need the private key, how to
create the bean definition for keyManager when I have the jks file,
jks-pwd, alias, but no pwd for privatekey? Can I pass the empty string (as "") in the password field in the alias-password value pair.
You can skip usage of private key in this case. You can find detail on how to use Spring SAML without keystore in the manual chapter 8.1:
In case your application doesn't need to create digital signatures
and/or decrypt incoming messages, it is possible to use an empty
implementation of the keystore which doesn't require any JKS file -
org.springframework.security.saml.key.EmptyKeyManager. This can be the
case for example when using only IDP-Initialized single sign-on.
Please note that when using the EmptyKeyManager some of Spring SAML
features will be unavailable. This includes at least SP-initialized
Single Sign-on, Single Logout, usage of additional keys in
ExtendedMetadata and verification of metadata signatures. Use the
following bean in order to initialize the EmptyKeyManager:
<bean id="keyManager" class="org.springframework.security.saml.key.EmptyKeyManager"/>