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.
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 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.
I have added International Domain Name support to an XMPP client as specified in RFC 6122. In the RFC it states:
Although XMPP applications do not communicate the output of the
ToASCII operation (called an "ACE label") over the wire, it MUST be
possible to apply that operation without failing to each
internationalized label.
However, with the domain I have available for testing (running Prosody 0.9.4; working on getting feedback from someone else about how Ejabberd handles this), sending a Unicode name in the "to" field of an XMPP stanza causes them to immediately return an XMPP error stanza and terminate the stream. If I apply the toASCII operation before sending the stanza, the connection succeedes, and I can begin authentication with the server.
So sending:
<somestanza to="éxample.net"/>
Would cause an error, while:
<somestanza to="xn--xample-9ua.net"/>
works fine.
Is it correct to send the ASCII representation (ACE label) of the domain like this? If so, what does the spec mean when it says that "XMPP applications do not communicate the output of the ToASCII operation ... over the wire"? If not, how can I ensure compatibility with misbehaving servers?
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".