(C) Copyright 2011 Matteo Panella <[email protected]>.
This work is licensed under the Creative Commons Attribution 3.0 Unported License.
This specification aims to develop a new and improved version of the WebIRC protocol [WEBIRC], allowing strong cryptographic authentication of WEBIRC gateways and autodiscovery of WEBIRC-enabled servers through DNS SRV records.
Current WEBIRC protocol is well-suited for simple scenarios (single gateway for a single ircd), but more complex scenarios (multiple gateways and/or multiple ircds or IRC networks) require quite a lot of administrative overhead.
Each network has to maintain a list of all allowed gateways, specifying their IP addresses and passwords, likewise gateway operators need to have a list of all networks supporting WEBIRC, what servers do support it and what passwords have been allocated.
Gateways would be able to autodiscover if a given network supports WEBIRC without the need to arrange trust relationships beforehand or informing IRC networks of gateway IP address changes. All that's need is publishing public key information (more on that later) for the gateway and checking if the gateway is trusted by a network.
IRC networks would just need to publish required DNS SRV records to advertise WEBIRC support and retrieve public keys for each gateway they wish to establish a trust relationship with.
This is mostly a braindump of the author's ideas on the matter, it should be evaluated by a third party, polished and reformatted.
Eventually, this document should be submitted to IETF as an Internet Draft for further evaluation.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [BCP 14].
WEBIRC Version 2 is comprised of two elements:
- extension of the IRC handshake to relay the client's original host name and host address;
- automatic discovery of WEBIRC-enabled networks through the use of DNS SRV records.
Compliant IRC servers and gateways MUST implement the extended client handshake as specified by this document. Implementation of the IRC server autodiscovery by gateways is RECOMMENDED.
A gateway initiates a WEBIRCv2 handshake by sending a "WEBIRC LOGIN" message, to which the server MUST respond with a "WEBIRC CHALLENGE" message. The gateway then concatenates the challenge, its identifier and all user data, signs the resulting data with its ECDSA private key and sends it to the server using a "WEBIRC RESPONSE" command. The gateway MUST proceed with the standard IRC client handshake without waiting for an answer by the server.
The server uses the supplied information to verify if a trust relationship exists and the validity of user data. If a trust relationship exists and the signature is valid, the server MUST use provided user data in place of the gateway host name and host address. If there is no trust relationship, the server SHOULD discard provided user data and treat the gateway as an ordinary IRC client. If required by the server administrator, however, the server MAY reply with an error message and close the connection. If signature verification fails, the server MUST reply with an error message and close the connection.
The following rules are specified for message elements:
- <identifier>: a unique identifier for the WEBIRC gateway following the same grammar for <user host name>
- <user host name>: as specified in "Requirements for Internet Hosts - Application and Support" [RFC 1123]
- <user host address>:
- IPv4 host address: quad-dotted notation (IPv6-mapped notation is forbidden)
- IPv6 host address: standard hexadecimal notation surrounded by [ and ]
- <ecdsa string>: a string of US-ASCII [RFC 20] characters in the range 33..126 excluding \ and all quotation marks
- <challenge>: <ecdsa string>
- <signature>: <ecdsa string>
Gateway identifier SHOULD be the public host name of the gateway to avoid potential name clashes.
Additionally, the following rules are specified for configuration data:
- <public key>: <ecdsa string>
The WEBIRC RESPONSE payload plus the initial challenge are cryptographically signed using Elliptic Curve DSA (ECDSA from now on). This allows to use short keys and signatures while maintaining a security level comparable to RSA signatures with key lenghts exceeding 2048 bits.
A challenge is generated by the server to prevent handshake replay by an adversary and is passed to the gateway.
The gateway then performs the following steps to produce the signature:
def generate_signature(challenge, identifier, userhost, useraddr, privkey):
blob = challenge + identifier + userhost + useraddr
raw_signature = ECDSA_sign(privkey, blob, curve='secp192r1')
return serialize_signature(raw_signature)
where serialize_signature() transforms the raw signature bytes into a string of
US-ASCII characters using the algorithm defined in Section **FIXME**.
The server receives from the gateway its identifier, user data and signature and verifies if this gateway is registered and trusted. If the gateway is not trusted, the server SHOULD ignore all supplied data and treat it as a standard IRC client or it MAY reply with an error and close the connection if configured to do so.
If a trust relationship exists, the server MUST fetch from local storage the public ECDSA key of the gateway and verify the data signature according to the following algorithm:
def verify_signature(client, identifier, userhost, useraddr, signature, pubkey):
# Rebuild original blob
blob = client.challenge + identifier + userhost + useraddr
raw_signature = deserialize_signature(signature)
return ECDSA_verify(pubkey, blob, raw_signature, curve='secp192r1')
If verification succeeds, the server MUST replace the gateway host name and host address with those supplied with the WEBIRC RESPONSE command. If verification fails, the server MUST reply with an error message and close the connection unconditionally.
TBD, see serialize.c in [SECCURE].
Compliant servers MAY implement backward compatibility with original WEBIRC protocol. If they do, they MUST forbid the use of the following strings as WEBIRC passwords:
LOGIN(any case variation)RESPONSE(any case variation)
CHALLENGE MAY be forbidden, but its usage does not break forward compatibility.
Compliant gateways MAY implement the original protocol, but they SHOULD NOT use it as default handshake mechanism.
- Command:
WEBIRC LOGIN - Parameters: none
- Server Reply:
WEBIRC CHALLENGE
The WEBIRC LOGIN command is used by a compliant gateway to initiate a WEBIRCv2 handshake. The command MUST be sent before any other WEBIRC command or standard user registration. The server MUST accept the command only once.
Example:
WEBIRC LOGIN
- Command:
WEBIRC RESPONSE - Parameters: <identifier> <user host name> <user host address> :<signature>
- Server Reply: Varies, see relevant section.
The WEBIRC RESPONSE command is used by a compliant gateway to complete a WEBIRCv2 handshake and relay user data to the IRC server. The command MUST be sent after a WEBIRC CHALLENGE has been received from the server and before standard IRC client handshake. See relevant section for signature generation algorithm and syntax of client identifier and signature.
Example:
WEBIRC RESPONSE webirc.example.com client.example.com [2001:0db8::1] :%2nf2ZjG3{9x3wt/L;B8nmUGEUt>1NGkUH5JvX=v9w+QlM$au:
- Reply:
WEBIRC CHALLENGE - Parameters: <challenge>
The WEBIRC CHALLENGE reply is sent by the server in response to a WEBIRC LOGIN command to initiate a WEBIRCv2 handshake. The server MUST generate a cryptographically secure challenge, and send it to the client encoded using printable US-ASCII characters.
The server MUST save the challenge for a given client until the initial handshake is completed.
Example:
:server.example.com WEBIRC CHALLENGE :ChAlLeNgE
- Client:
- Host address:
2001:0db8::1 - Host name:
client.example.com - Nickname:
morpheus
- Server:
- IRC Name:
server.example.com
- Gateway:
- Host name:
backend01.example.com - Identifier:
webirc.example.com - ECDSA curve:
secp192r1 - Private Key:
antani - Public Key:
7..mVgp&o<_U$PeT,*1tk={3/Ugww}
Notation:
>: data sent by the gateway<: data sent by the server- CR+LF packet terminators are omitted for clarity
Valid handshake:
> WEBIRC LOGIN
< :server.example.com WEBIRC CHALLENGE :ChAlLeNgE
> WEBIRC RESPONSE webirc.example.com client.example.com [2001:0db8::1] :#xs_Q,|mhM/89uQRHH7X>7cSID38CVN~V]z#jJJ619*pI/zeOjj(Zl7=1[wn
> NICK morpheus
> USER webchat 0 0 :Example.com WebChat
< :server.example.com 001 morpheus :Welcome to the Internet Relay Network [email protected]
Invalid handshake (missing trust relationship - server does not close the connection):
> WEBIRC LOGIN
< :server.example.com WEBIRC CHALLENGE :ChAlLeNgE
> WEBIRC RESPONSE webirc.example.com client.example.com [2001:0db8::1] :#xs_Q,|mhM/89uQRHH7X>7cSID38CVN~V]z#jJJ619*pI/zeOjj(Zl7=1[wn
> NICK morpheus
> USER webchat 0 0 :Example.com WebChat
< :server.example.com 001 morpheus :Welcome to the Internet Relay Network [email protected]
Invalid handshake (invalid signature):
> WEBIRC LOGIN
< :server.example.com WEBIRC CHALLENGE :ChAlLeNgE
> WEBIRC RESPONSE webirc.example.com spoofed.example.com [2001:0db8:f001::1] :#xs_Q,|mhM/89uQRHH7X>7cSID38CVN~V]z#jJJ619*pI/zeOjj(Zl7=1[wn
> NICK morpheus
> USER webchat 0 0 :Example.com WebChat
< ERROR :WEBIRC signature verification failed
<Server closes the connection>
TBD
As with all digital signature algorithms based on the Discrete Logarithm Problem, special care MUST be taken not to generate two distinct signatures with the same random parameter, as it would allow an attacker to retrieve the private key.
Challenge strings MUST be generated using cryptographically secure pseudo-random number generators to prevent signature replay. Failure to comply with this requirement would result in the ability for an attacker to reuse a previous valid handshake and spoof their host name and address.
The standard curve for this specification is secp192r1 [SEC 2], which
provides a good balance between security and computational cost.
Security of DNS SRV records is out of the scope of this document, however DNSSEC MAY be employed to prevent forging of replies to autodiscovery requests.
TBD
| [BCP 14] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC 20] | Cerf, V., "ASCII format for network interchange", RFC 20, October 1969. |
| [RFC 1123] | Braden, R., "Requirements for Internet Hosts - Application and Support", RFC 1123, October 1989. |
| [SEC 2] | Standards for Efficient Cryptography Group, "SEC 2: Recommended Elliptic Curve Domain Parameters", Version 2.0, January 2010. <http://www.secg.org> |
| [WEBIRC] | WebIRC Protocol <http://wiki.mibbit.com/index.php/WebIRC> |
| [SECCURE] | SECCURE Elliptic Curve Crypto Utility for Reliable Encryption <http://point-at-infinity.org/seccure/> |
Brilliant.