Securing Arbitrary XMPP Data…(cont)

arbitrary XMPP Data has a XML media type named “application/xmpp+xml”. Just like securing CPIM objects, this kind of XMPP data can be signed and/or encrypted, then it would be encapsulated within an XML CDATA section contained in an <e2e/> child of a <presence/> stanza.

Rules for S/MIME Generation and Handling

RFC 3923 does not state how to get a certificate from the certificate authority, instead it recquires every sending agent to have a certificate. User agents should send a request asking for the recipient’s signed certificate. The memo includes what are the information that should be included in an end-entity certificates; it should have a valid instant messaging and presence address.

When the data should be signed and encrypted, it should be signed first before encrypted.

When the sender and the recipient communicates over a period of time, the sender should send a certificate with at least one encrypted message every five minutes. But the sender should not send more than one certificate every five minutes.

The memo also includes rules when dealing with Timestamps which is used to prevent “replay attacks”.

This also has several error handling whenever the recipient receives a signed and/or encrypted data.

c/o hannah

overnight in jrdc…

we decided to have another overnight stay at jrdc to prepare our thesis presentation for thursday. we also finished designing our initial user interface design, and that is included in our presentation. we were having a hard time looking for some articles for our literature summary… but the other parts of our presentation are okey nah…

c/o hannah

Re-do

Have to re-do the slides for the presentation. I’ve been noted of the errors and the missing information that we need to include to the slides. Overnight session will pursue later for preparation on the presentation, do some designing for the application prototype.

I ‘ve read JEP-0147, which is related to rfc 4622. this jep extends the XMPP URI Scheme Query components that the rfc failed to enumerate. It provides a list of common actions for queries such as “join chat room” or “send message” in IM.

JEP-0132 discusses Presence obtained via kinesthetic excitation (POKE), which means some form of physical contact with an object is an evidence of presence. It makes use of a new presence type “probe-irl”

JEP-0027 discusses Jabber OpenPGP usage which is necessary to provide security and privacy features in a system.

c/o ariel

presentation slides

the group has been preparing the slides for the project presentation.

i read jep 0182.  as xmpp is extensible, any extension may define any application-specific error.  all error definitions must be registered to the jabber registrar to avoid confusion.  there is a namespace for errors not specified.

jep 0113.  aside from instant messaging, jabber can be used in whiteboarding.  multiple users can share a single whiteboard and edit images.  however, text not supported.

Burnnnnnnnn!

I am currently studying the code of Spark, the Instant Messaging Client used by the Jabber-implemented server, Wildfire. This will be helpful in implementing the instant messaging/chat module of our project. I am also trying to find resources on how to perform the logging-in to the Google Jabber server, since we’ve decided that we’re going to use it in the project. I am also trying to work things out with NetBeans (since I’m not really into IDE’s that much) so I could try working on the prototype that we’ve done during the overnight session last weekend. We’ll have a conference later for topics to be done and preparation for the presentation next week.
More updates to follow.

c/o ariel

progress report for 8/15-8/21

for this week, we tested Spark, an XMPP-based chat application. At first, we had a difficult time in configuring how can we connect to other servers. But we were able to use the application using ariel’s server last thursday. we are planning to study the application, since it is an open-source app, for the instant messaging feature of our project.

last friday and saturday, the group had their first overnight stay at jrdc. we started to make the uml for the project. the use-case, class and activity diagrams are designs we have just  finished working on. reah posted these at our wiki. she also finished posting the background of the study, objectives, statement of the problem, etc. at the wiki.

during the overnight stay, we also started designing the initial prototype of the Pisara editor. although we haven’t finished it yet, we are planning to finish it within this week.

the group is still studying the RFC’s of the XMPP. hannah have read the RFC that is about signing and object encryption on XMPP, she posted the summary at securing XMPP messages and presence information post.

ariel have just read the RFC 4622 (Internationalized Resource Identifiers [IRI] and Uniform Resource Identifiers [URI] for Extensible Messaging Presence Protocol).  the summary is posted at URI’s and IRI’s for XMPP.

so far, the group is still right on schedule. the details about the progress we’ve made are stated in our previous posts, this is just the summary of all the things we’ve done last week.

URI’s and IRI’s for XMPP

I’ve scanned through the RFC 4622 (Internationalized Resource Identifiers [IRI] and Uniform Resource Identifiers [URI] for Extensible Messaging Presence Protocol). It discusses IRI’s and URI’s used in entities communicating using XMPP.

1. In order to be converted into an IRI or URI, an XMPP address must be prepended with a scheme, and can also include other URI syntax for a more advance identification in XMPP entities.
2. An application that generates the XMPP address must ensure that it follows the rules indicated in the XMPP: CORE. To transform an XMPP URI into and IRI, proper mapping shoul be done. Moreover, there are characters used in creating the node, domain and resource identifiers that are not allowed in the IRI.
3. If the processing application is presented with an XMPP URI, it is required to convert it first to an XMPP IRI before it can be used for interaction, and as mentioned above, it should follow the rules indicated in the XMPP: CORE.

The document also discusses issues that are related to the generation and processing of URI’s and IRI’s such as security, reliability and consistency. This takes into consideration the malicious construction of URI’s and IRI’s and sending information that may be sensitive to attacks.

c/o ariel

wiki updated

the use case, activity, and class diagrams have been uploaded in the wiki, in addition to the previous wiki requirements (e.g. statement of the problem, literature summary).

 c/o reah

Securing XMPP instant messages and presence information

the protocol we’re gonna use provides methods for securing instant messages. These methods are end-to-end signing and object encryption. The RFC 3923: end-to-end signing and object encryption for the Extensible Messaging and Presence Protocol contains the procedures for signing and object encryption.

for securing messages, first, you must produce a CPIM (instant message) object. You may sign the object and/or encrypt the object. then you must provide this object within an XML CDATA section, under <e2e> element of XMPP stanza. after signing an object its content-type would be “multipart/signed”.

 when signing an CPIM object the result will be an object which has two parts, first part has a content-type “Message/CPIM” , and the other part has a content-type of “application/pkcs7-signature”.

for encrypting the message, the sender only has to generate the CPIM object and then he may encrypt it.

 in xmpp, you can also secure the presence information. this time you have to make an “application/pidf+xml” object. then after that you may sign and/or encrypt the presence info. then you must provide the signed and/or encrypted object within an XML CDATA section, under the <e2e> element of the XMPP stanza.

After signing the generated ”application/pidf+xml” object, the object whose content-type is “multipart/signed” would also contain two parts just like in CPIM message. however, the first part has a content-type of “application/pidf+xml”, while the other would be “application/pkcs7-signature”.

you may also  encrypt your presence information, all you have to do is generate the “application/pidf+xml” object.

the memo also contains the procedures for securing arbitrary XMPP data, the kind of data that can be translated directly into MSGFMT or PIDF formats. i will not discuss the procedures since i think we wont use it in our project.

source: http://www.xmpp.org/specs/rfc3923.html#MSGFMT

c/o hannah

prototype…

last friday night, during our overnight stay at jrdc we tried to make the Pisara’s user interface design. We used netbeans 5.0 to make the prototype of our application. We haven’t finished it yet, we still on familiarizing-the-IDE stage. But at least we already have an idea on our design. we even have a mascot, its a tarsier named Tarsi… hehe.

c/o hannah