I'm reading the RFC 4422 document which detail described the SASL framework, but English is not my native language. I really can't understand what's the 'challenge' mean in SASL? The following content is extracted from the document:
Where the mechanism specifies that the first data sent in the
exchange is from the client to the server and this field is
unavailable or unused, the client request is followed by an empty
challenge.
C: Request authentication exchange
S: Empty Challenge
C: Initial Response
<additional challenge/response messages>
S: Outcome of authentication exchange
'an empty challenge' is an empty request? or something else? Thanks for your help.
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
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.
I want to implement a simple authentication in C++. For now I can initiate a stream, get supported mechanisms and chose one. It works fine, but now I can't read out (from http://xmpp.org/extensions/xep-0034.html#sect-id259287 ) what I have to write into the plaintext handshake. Decoding the string I get "robsecret". So how do I do it with username "user" and passsword "pass"?
PS: Response using "userpass" is "".
Thanks!
You do of course realize that this is a retracted XEP you are trying to find information in?
The relevant documents are RFC 6120 (XMPP Core) and RFC 4616 (SASL PLAIN).
Short version:
PLAIN requires you to send base64("authzid\0authcid\0password"), where authzid is usually empty and authcid is your username.
Making a REST web server mainly based on large files uploads / downloads, I want to be able to check the file integrity. I believed that the proper way to do it was using Content-MD5 HTTP header [0] as proved useful by aws experience [1].
However, much to my dismay, I recently learned that it was (to be ?) deprecated [2].
The deprecation discussion did not give any workaround hint, so I am asking you :
Should I still decide to use a Content-MD5 HTTP header ?
Should I use an ETag with the same meaning (base64 encoding of the md5sum) ?
Should I use an ?md5sum=XXX parameter ?
Is there a better solution altogether ?
Thanks for your insights.
Best Regards,
B.
[0] https://webmasters.stackexchange.com/questions/2924/
[1] http://developer.amazonwebservices.com/connect/thread.jspa?threadID=22709
[2] http://trac.tools.ietf.org/wg/httpbis/trac/ticket/178
Add a custom header, called say X-YourService-Integrity. That makes it explicit that it's a system specific to your service, and allows you to use integrity check mechanisms other than MD5 in the future (for example, SHA1). It also avoids you having to "overload" existing mechanisms that are similar but not quite what you want.
https://www.ietf.org/rfc/rfc3230.txt
4.3.2 Digest
The Digest message header field provides a message digest of the
instance described by the message.
Digest = "Digest" ":" #(instance-digest)
The instance described by a message might be fully contained in the
message-body, partially-contained in the message-body, or not at all
contained in the message-body. The instance is specified by the
Request-URI and any cache-validator contained in the message.
A Digest header field MAY contain multiple instance-digest values.
This could be useful for responses expected to reside in caches
shared by users with different browsers, for example.
A recipient MAY ignore any or all of the instance-digests in a Digest
header field.
A sender MAY send an instance-digest using a digest-algorithm without
knowing whether the recipient supports the digest-algorithm, or even
knowing that the recipient will ignore it.
Examples:
Digest: md5=HUXZLQLMuI/KZ5KDcJPcOA==
Digest: SHA=thvDyvhfIqlvFe+A9MYgxAfm1q5=,unixsum=30637
Do not use Content-MD5: it has been deprecated because it leads to inconsistencies.
Use Digest with sha-256 or sha-512. We are updating RFC3230 to the latest HTTP specification (RFC7231) and added a lot of useful examples https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-digest-headers-02
Digest: sha-256=4REjxQ4yrqUVicfSKYNO/cF9zNj5ANbzgDZt3/h3Qxo=
There Want-Digest allows requesting a specific Digest header.
Eg. The client requests a digest, supporting sha-256 and sha-512. The server replies with sha-256
Request:
GET /items/123 HTTP/1.1
Want-Digest: sha-256, sha-512
Response:
HTTP/1.1 200 OK
Content-Type: application/json
Digest: sha-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=
{"hello": "world"}
I'm trying to learn the XMPP spec (RFC 3920) by coding it in low-level Python. But I've been hung up for over an hour at step 4 of section 6.5, selecting an authentication mechanism. I'm sending: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='PLAIN'/>, and getting: <failure xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><incorrect-encoding/></failure> instead of a base64-encoded challenge.
The "incorrect-encoding" error is supposedly to be used for when I incorrectly base64-encode something, but there was no text to encode. I'm probably missing something really obvious. Anybody got a cluestick?
I'm using talk.google.com port 5222 as the server, if that matters. I doubt that it does; this is almost definitely due to my lack of understanding this section of the RFC. And the problem isn't likely my code, other than the way I'm sending this particular stanza, or it would be failing at the previous steps. But for what it's worth, here is the code I've got so far, and the complete log (transcript of the session). Thanks.
First off, RFC 6120 is often more clear than 3920. [updated to point to the RFC as released]
Since you're using SASL PLAIN (see RFC 4616), many servers expect you to send a SASL "initial response" in the auth element, consisting of:
base64(\x00 + utf8(saslprep(username)) + \x00 + utf8(saslprep(password)))
All together, then, your auth element needs to look like this:
<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
mechanism='PLAIN'>AGp1bGlldAByMG0zMG15cjBtMzA=</auth>
For the username "juliet" and the password "r0m30myr0m30".