From cbbea523c615b178d548b8e3da76b3d1e32566ad Mon Sep 17 00:00:00 2001 From: Pekka Riikonen Date: Mon, 2 Feb 2004 08:02:33 +0000 Subject: [PATCH] Added. --- doc/draft-riikonen-presence-attrs-03.nroff | 669 +++++++++++ doc/draft-riikonen-silc-ke-auth-08.nroff | 1180 ++++++++++++++++++++ 2 files changed, 1849 insertions(+) create mode 100644 doc/draft-riikonen-presence-attrs-03.nroff create mode 100644 doc/draft-riikonen-silc-ke-auth-08.nroff diff --git a/doc/draft-riikonen-presence-attrs-03.nroff b/doc/draft-riikonen-presence-attrs-03.nroff new file mode 100644 index 00000000..1f83ded5 --- /dev/null +++ b/doc/draft-riikonen-presence-attrs-03.nroff @@ -0,0 +1,669 @@ +.pl 10.0i +.po 0 +.ll 7.2i +.lt 7.2i +.nr LL 7.2i +.nr LT 7.2i +.ds LF Riikonen +.ds RF FORMFEED[Page %] +.ds CF +.ds LH Internet Draft +.ds RH 2 February 2004 +.ds CH +.na +.hy 0 +.in 0 +.nf +Network Working Group P. Riikonen +Internet-Draft +draft-riikonen-presence-attrs-03.txt 2 February 2004 +Expires: 2 August 2004 + +.in 3 + +.ce 2 +User Online Presence and Information Attributes + + +.ti 0 +Status of this Memo + +This document is an Internet-Draft and is in full conformance with +all provisions of Section 10 of RFC 2026. Internet-Drafts are +working documents of the Internet Engineering Task Force (IETF), its +areas, and its working groups. Note that other groups may also +distribute working documents as Internet-Drafts. + +Internet-Drafts are draft documents valid for a maximum of six months +and may be updated, replaced, or obsoleted by other documents at any +time. It is inappropriate to use Internet-Drafts as reference +material or to cite them other than as "work in progress." + +The list of current Internet-Drafts can be accessed at +http://www.ietf.org/ietf/1id-abstracts.txt + +The list of Internet-Draft Shadow Directories can be accessed at +http://www.ietf.org/shadow.html + +The distribution of this memo is unlimited. + + +.ti 0 +Abstract + +This document defines set of attributes that can represent the online +user's presence in a network, and to provide general information about +the user. The purpose is to provide a generic mechanism to share +online presence and status, and general information about the user +to be used in several kind of network protocols and applications. +These attributes could be used by for example chat and conferencing +protocols (such as Instant Message protocols), network games, and +other similar network protocols and applications that has online +users in a network. + + + + + + + +.ti 0 +Table of Contents + +.nf +1 Introduction .................................................. 2 + 1.1 Requirements Terminology .................................. 2 +2 Attributes Concept ............................................ 3 + 2.1 Requesting Attributes ..................................... 3 + 2.2 Replying Attributes ....................................... 3 + 2.3 Attribute Data Types ...................................... 4 + 2.4 Attribute Payload ......................................... 4 + 2.5 Attributes ................................................ 5 +3 Security Considerations ....................................... 11 +4 References .................................................... 12 +5 Author's Address .............................................. 13 +6 Full Copyright Statement ...................................... 13 + + +.ti 0 +1. Introduction + +This document defines set of attributes that can represent the online +user's presence in a network, and to provide general information about +the user. The purpose is to provide a generic mechanism to share +online presence and status, and general information about the user +to be used in several kind of network protocols and applications. +These attributes could be used by for example chat and conferencing +protocols (such as Instant Message protocols), network games, and +other similar network protocols and applications that has online +users in a network. + +This document does not define these attributes to be used in any +specific protocol, but assumes that they can be used generally in +any kind of online network protocol. Furthermore, the document +pays attention to special needs of various protocols, such as +mobile network protocols, which requires the attributes to be +both robust and compact. The attributes are also considered to be +easily implementable and for this reason a clear and robust structure +was chosen for the attributes. + +This document is strongly influenced by Wireless Village Initiative +where similar attributes are defined, and credits for the ideas are +due there. However, they are defined only in the context of the +Wireless Village, and the format of the attributes used is not +suitable for general purpose usage. + + +.ti 0 +1.1 Requirements Terminology + +The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, +MAY, and OPTIONAL, when they appear in this document, are to be +interpreted as described in [RFC2119]. + + +.ti 0 +2 Attributes Concept + +Many network protocols needs a way to transfer and retrieve status +information about users in a network. For example, many chat and +conferencing protocols such as IRC, and all Instant Message (IM) +protocols, such as ICQ has a way to retrieve presence and status +information about the users in the network. This could be added to +several other kind of network protocols as well, and for this reason +a defined mechanism to provide these informations is needed. + +The attributes are usually requested by an entity in the network +from other entity, usually a user or end user's device in the network. +The recipient then replies to each of the requested attributes and +sends the reply to the requester. + +This document does not define the actual transport for requesting and +providing the replies to the requests, since this is irrelevant. +This document defines a payload for requesting, and providing the +information, but how the payload is transported is not defined in +this document. In a client-server network model the user requesting +attributes usually destine the request to a remote user and the +server relays the attributes to the remote user. It is also possible +that the concept is not user-to-user, but the server replies to the +requested attributes on behalf of the user. + + +.ti 0 +2.1 Requesting Attributes + +When an entity requests attributes from a user in the network, +it assembles a list of Attribute Payloads, and sets the requested +attribute value into the payload. Each requested attribute is a separate +Attribute Payload and they MUST be appended one after the other. The +requester need to understand that the recipient may not understand all +the requested attributes, and may not reply to all of the requested +attributes. The requester also need to understand that the recipient +may reply with additional attributes that were not requested. + + +.ti 0 +2.2 Replying Attributes + +When en entity receives the Attribute Payloads it parses them one after +the other. The entity can parse each of the Attribute Payload separately +since it knows the length of the current attribute; next attribute +begins after the current attribute ends. The entity then checks the +requested attribute and SHOULD reply either with valid value or with +an indication that the attribute is unsupported or unknown. It is +also possible to reply with additional attributes that were not +requested. + +When replying to the requested attributes the entity assembles a list +of Attribute Payloads, each including the attribute type and the +actual attribute data. + + +.ti 0 +2.3 Attribute Data Types + +This section defines basic data types that can appear in the attributes +in this document. + +All integer values are stored in the MSB first order. The size of the +integer is provided separately with the attribute. Integer is +represented as "integer" in this documentation. + +Strings MUST be UTF-8 [RFC2279] encoded, and include 2 bytes length +field indicating the length of the string. Hence, when "string" value +appears in this documentation it is encoded as: + +.in 6 +Length Type Value +2 bytes integer Length of String field +variable UTF-8 String +.in 3 + +If string is not present then the length field includes zero (0) +value. + +Boolean value is represented as "boolean" and its size is 1 byte. +Value 0x00 indicates false value and value 0x01 indicates true value. + + +.ti 0 +2.4 Attribute Payload + +The Attribute Payload is used to request an attribute, and to reply +to the requested attribute. One payload includes one attribute. + + +.in 5 +.nf + 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Attribute | Attr Flags | Attribute Length | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| | +~ Attribute Data ~ +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +.in 3 + +.ce +Figure 1: Attribute Payload + + +.in 6 +o Attribute (1 byte) - Indicates the attribute included in this + Attribute Payload. + +o Attribute Flags (1 byte) - Indicates the flags associated + with this attribute. The following flags are defined: + + 0x01 ATTRIBUTE_FLAG_INVALID + + The attribute value in Attribute Data is invalid, or + unknown. This may be set to indicate that a requested + attribute is not available, its value is unknown, or + sender does not understand it. + + 0x02 ATTRIBUTE_FLAG_VALID + + The attribute value is included in the Attribute Data. + + When sending this payload to request attributes this value + MUST be set to zero (0) value. When sending a reply to the + request this field MUST NOT include a zero (0) value. + +o Attribute Length (2 bytes) - Indicates the length of the + Attribute Data field, not including any other field. + +o Attribute Data (variable length) - The Attribute Data. + The contents of this field is attribute specific, defined + subsequently. +.in 3 + + +.ti 0 +2.5 Attributes + +The following values can appear in the Attribute field in the +Attribute Payload to indicate the content of the attribute. The +format of the attribute data is represented as length, type and +value. Example: + +.in 6 +Length Type Value +2 bytes integer Some integer value +variable string Some string +1 byte boolean Boolean value +.in 3 + +When sending multiple Attribute Payloads it is possible to include +multiple same attributes in the packet. + + +.in 6 +0 ATTRIBUTE_NONE + + This attribute is reserved and it is never sent. + + +1 ATTRIBUTE_USER_INFO + + This attribute includes general information about the user, their + name and contact information. The content of this attribute is + a VCard version 3.0 as defined in RFC 2426 [RFC2426] and RFC 2425 + [RFC2425]. Note that some of the information that VCard provides + can be also provided in the means of providing other attributes. + The rationale for this is that the VCard does not provide all the + information, or with the required precision that may be desired in + some applications. It is therefore RECOMMENDED that this attribute + would be used to provide only basic and constant user information, + such as name and contact information, but not online status + information. + + Length Type Value + variable VCard Basic user information + + +2 ATTRIBUTE_SERVICE + + This attribute indicates a service in the Internet that the user + is currently using or has logged in. It also shows when the user + started using the service, and how long user has been idle in the + service. The value of this attribute is as follows: + + Length Type Value + 4 bytes integer Service Port (IANA specified) + variable string Service Address + 1 byte boolean Online status. If this is set to + 0x01 (true) it means the user is online + in the service. Set to 0x00 (false) when + out of reach. + variable string Signon date and time, UTC date, format as + in ISO 8601 + 4 bytes integer Idle time + + +3 ATTRIBUTE_STATUS_MOOD + + This attribute indicates the mood of the user. It can indicate + whether the user is eager to participate in the network. The + value of this attribute is as follows: + + Length Type Value + 4 bytes integer Mood mask (values ORed together) + + The following mood values are defined: + + 0x00000000 MOOD_NORMAL No specific mood, normal mood + 0x00000001 MOOD_HAPPY The user feels happy + 0x00000002 MOOD_SAD The user feels sad + 0x00000004 MOOD_ANGRY The user feels angry + 0x00000008 MOOD_JEALOUS The user feels jealous + 0x00000010 MOOD_ASHAMED The user feels ashamed + 0x00000020 MOOD_INVINCIBLE The user feels invincible + 0x00000040 MOOD_INLOVE The user feels being in love + 0x00000080 MOOD_SLEEPY The user feels sleepy + 0x00000100 MOOD_BORED The user feels bored + 0x00000200 MOOD_EXCITED The user feels excited + 0x00000400 MOOD_ANXIOUS The user feels anxious + + +4 ATTRIBUTE_STATUS_FREETEXT + + This attribute includes the user's online status free text. It + can provide personal status as a text message. The contents of + this attribute is a UTF-8 encoded free text string. + + Length Type Value + variable string Free text status string + + +5 ATTRIBUTE_STATUS_MESSAGE + + This attribute includes the user's online status message. It + could provide for example a multi media message showing the status + of the user. The contents of this attribute is a MIME object, + which can be used to provide for example video, audio, image or + other similar status message. It could also provide a reference + to the message, for example an URL address. + + Length Type Value + variable MIME Status message as MIME object + + +6 ATTRIBUTE_PREFERRED_LANGUAGE + + This attribute indicates the preferred language to be used when + communicating. The encoding of this attribute is as follows: + + Length Type Value + variable string ISO 639-2/T three letter code + + +7 ATTRIBUTE_PREFERRED_CONTACT + + This attribute indicates the preferred contact methods. It can + indicate the method the user prefers when contacting. The value + of this attribute is as follows: + + Length Type Value + 4 bytes integer Contact mask (values ORed together) + + The following contact methods are defined: + + 0x00000000 CONTACT_NONE No specific preferred contact method + 0x00000001 CONTACT_EMAIL Email is preferred + 0x00000002 CONTACT_CALL Phone call is preferred + 0x00000004 CONTACT_PAGE Paging is preferred + 0x00000008 CONTACT_SMS SMS is preferred + 0x00000010 CONTACT_MMS MMS is preferred + 0x00000020 CONTACT_CHAT Chatting is preferred + 0x00000040 CONTACT_VIDEO Video conferencing is preferred + + +8 ATTRIBUTE_TIMEZONE + + This attribute can be used to provide the current local time for + the user. The contents of this attribute is a UTF-8 encoded + string and the format of the string is UTC time zone defined + in the ISO 8601. + + Length Type Value + variable string UTC date, format as in ISO 8601 + + Note that ATTRIBUTE_USER_INFO may also provide this information. + However it is RECOMMENDED that this attribute is used when + current time zone information is provided. + + +9 ATTRIBUTE_GEOLOCATION + + This attribute can be used to provide measured global location of + the user. How this information is gathered is out of scope of + this document. The attribute can provide latitude and longitude + lateral positions, but also a vertical position. A parameter + describing the accuracy of the information can also be provided. + + Length Type Value + variable string Longitude (ex. 31 17 14.321W) + variable string Latitude (ex. 12 11 21.2N) + variable string Altitude + variable string Accuracy in meters + + Note that ATTRIBUTE_USER_INFO may also provide this information, + however it does not have the vertical position, or the accuracy + parameter. It is RECOMMENDED that this attribute is used when + providing current global position information. + + +10 ATTRIBUTE_DEVICE_INFO + + This attribute includes information about the user's device. + The encoding of this attribute is as follows: + + Length Type Value + 4 bytes integer Device type + variable string Name of the device manufacturer + variable string Device version + variable string Device model + variable string Device language (ISO 639-2/T) + + The following Device types are defined: + + 0 DEVICE_COMPUTER Device is a computer + 1 DEVICE_MOBILE_PHONE Device is a mobile phone + 2 DEVICE_PDA Device is a PDA + 3 DEVICE_TERMINAL Device is a terminal + + +11 ATTRIBUTE_EXTENSION + + This attribute indicates that the attribute value is vendor, + application or service specific attribute extension. This field + MUST include a MIME object, which is the extension value. This + document does not specify any explicit MIME objects for this + attribute. + + Length Type Value + variable MIME Attribute extension as MIME object + + +12 ATTRIBUTE_USER_PUBLIC_KEY + + This attribute includes the user's public key or certificate. + As the public key and certificate format depends on which sort + of algorithm or certificate encoding user is using we need to + define a mechanism to differentiate the public key types from + each other. This document specifies the most common public keys + and certificates. This attribute can be used to deliver the + user's public key, and it MUST be present if also the + ATTRIBUTE_USER_DIGITAL_SIGNATURE is present. Note that the + recipient of this attribute SHOULD verify the public key from + a third party, for example from Certification Authority. If + there are more than one ATTRIBUTE_USER_PUBLIC_KEY attributes set + and ATTRIBUTE_USER_DIGITAL_SIGNATURE is also set, the digital + signature SHOULD be verifiable with the first set public key. + + Length Type Value + variable string Public key/certificate type + variable data Public key/certificate data + + The following public key/certificate types are defined: + + ssh-rsa SSH RSA public key [SSH-TRANS] + ssh-dss SSH DSS public key [SSH-TRANS] + silc-rsa SILC RSA public key [SILC1] + silc-dss SILC DSS public key [SILC1] + pgp-sign-rsa OpenPGP RSA certificate [RFC2440] + pgp-sign-dss OpenPGP DSS certificate [RFC2440] + x509v3-sign-rsa X.509 Version 3 RSA certificate [RFC2459] + x509v3-sign-dss X.509 Version 3 DSS certificate [RFC2459] + + Most of these public key/certificate types are equivalent to + the types specified for SSH protocol [SSH-TRANS] and are expected + to be officially assigned by IANA. + + The encoding of the public key/certificate data in the attribute + is done in the manner defined in their respective definitions. + + Note that these public keys are intended for signing. Some + certificates may have a key usage restrictions and same key cannot + be used for both encryption and signing. Therefore, the name + of the certificate type indicates if they are intended for + signing only. + + +13 ATTRIBUTE_SERVER_PUBLIC_KEY + + This attribute includes a third party server or authority public + key or CA certificate and MUST be present if the attribute + ATTRIBUTE_SERVER_DIGITAL_SIGNATURE is also present. The format + for this attribute is identical to the ATTRIBUTE_USER_PUBLIC_KEY + attribute. If there are more than one ATTRIBUTE_SERVER_PUBLIC_KEY + attributes set and ATTRIBUTE_SERVER_DIGITAL_SIGNATURE is also set, + the digital signature SHOULD be verifiable with the first set public + key. + + +14 ATTRIBUTE_USER_DIGITAL_SIGNATURE + + This attribute value includes digital signature of all Attribute + Payloads except this attribute. This signature can be provided by + the user. This attribute SHOULD be last attribute provided in the + reply so that it is easier for the receiver to compute the signature + data to be verified. The format and encoding of this attribute + depends on the public key or certificate used to produce the + signature. See the ATTRIBUTE_USER_PUBLIC_KEY for all public keys + and certificates that can be used to produce a signature. + + Length Type Value + variable data Digital signature data + + The encodings are as follows per public key/certificate type: + + ssh-rsa and ssh-dss Defined in [SSH-TRANS] + silc-rsa and silc-dss Defined in [SILC1] + pgp-sign-rsa and pgp-sign-dss Defined in [RFC2440] + x509v3-sign-rsa and x509v3-sign-dss Defined in [PKCS7] + + The procedure producing the signature and encoding it are done + in the manner defined in their respective definitions, see the + provided references. Also the hash function used with the + signature procedure is defined by the public key/certificate type. + + +15 ATTRIBUTE_SERVER_DIGITAL_SIGNATURE + + This attribute value includes digital signature of all Attribute + Payloads except this attribute, but including the attribute + ATTRIBUTE_USER_DIGITAL_SIGNATURE. This signature can be provided + by a third party server or an authority which has verified the + information provided by the user. How it verifies this information + is out of scope of this document, however it may base its + information to a previous registration information and current + online status of the user in a service. This attribute SHOULD be + last when provided, so that it is easier for the receiver to + compute the signature data to be verified. The format for this + attribute is identical to the ATTRIBUTE_USER_DIGITAL_SIGNATURE + attribute. +.in 3 + + +.ti 0 +3 Security Considerations + +The use of these attributes dictates whether the attributes need to +be secured or not. However, as the attributes are considered to provide +accurate status information about specific user, it is suggested that +the attributes would be secured. The attributes should be digitally +signed whenever it is possible. Attributes can also be encrypted +if it is provided by the protocol using the attributes. A third party, +like a server in the network, could also verify the information and provide +digital signature in case the information is accurate. + +Even though the attributes would be digitally signed by the sender of +the attributes, the information contained in the attribute may still +be incorrect. The third party server should not apply digital signature +unless it can verify every attribute. The receiver of the attributes +should also not trust that the information in fact is correct. + +However, it is possible that the context where these attributes are used +the attributes are provided by a party that can provide the accurate +information. For example a server in the network could reply to the +attributes on behalf of the actual user for some of the attributes. + + +.ti 0 +4 References + +[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + +[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", RFC 2279, January 1998. + +[RFC2425] Howes, T., et al, "A MIME Content-Type for Directory + Information", RFC 2425, September 1998. + +[RFC2426] Dawson, F., et al, "vCard MIME Directory Profile", + RFC 2426, September 1998. + +[SILC1] Riikonen, P., "Secure Internet Live Conferencing (SILC), + Protocol Specification", Internet Draft, May 2002. + +[RFC2440] Callas, J., et al, "OpenPGP Message Format", RFC 2440, + November 1998. + +[RFC2459] Housley, R., et al, "Internet X.509 Public Key + Infrastructure, Certificate and CRL Profile", RFC 2459, + January 1999. + +[SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol", + Internet Draft. + +[PKCS7] Kalinski, B., "PKCS #7: Cryptographic Message Syntax, + Version 1.5", RFC 2315, March 1998. + + + + +.ti 0 +5 Author's Address + +Pekka Riikonen +Snellmaninkatu 34 A 15 +70100 Kuopio +Finland + +EMail: priikone@iki.fi + + +.ti 0 +6 Full Copyright Statement + +Copyright (C) The Internet Society (2003). All Rights Reserved. + +This document and translations of it may be copied and furnished to +others, and derivative works that comment on or otherwise explain it +or assist in its implementation may be prepared, copied, published +and distributed, in whole or in part, without restriction of any +kind, provided that the above copyright notice and this paragraph are +included on all such copies and derivative works. However, this +document itself may not be modified in any way, such as by removing +the copyright notice or references to the Internet Society or other +Internet organizations, except as needed for the purpose of +developing Internet standards in which case the procedures for +copyrights defined in the Internet Standards process must be +followed, or as required to translate it into languages other than +English. + +The limited permissions granted above are perpetual and will not be +revoked by the Internet Society or its successors or assigns. + +This document and the information contained herein is provided on an +"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING +TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING +BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION +HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF +MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + diff --git a/doc/draft-riikonen-silc-ke-auth-08.nroff b/doc/draft-riikonen-silc-ke-auth-08.nroff new file mode 100644 index 00000000..22638c39 --- /dev/null +++ b/doc/draft-riikonen-silc-ke-auth-08.nroff @@ -0,0 +1,1180 @@ +.pl 10.0i +.po 0 +.ll 7.2i +.lt 7.2i +.nr LL 7.2i +.nr LT 7.2i +.ds LF Riikonen +.ds RF FORMFEED[Page %] +.ds CF +.ds LH Internet-Draft +.ds RH 2 February 2003 +.ds CH +.na +.hy 0 +.in 0 +.nf +Network Working Group P. Riikonen +Internet-Draft +draft-riikonen-silc-ke-auth-08.txt 2 February 2004 +Expires: 2 August 2004 + +.in 3 + +.ce 2 +SILC Key Exchange and Authentication Protocols + + +.ti 0 +Status of this Memo + +This document is an Internet-Draft and is in full conformance with +all provisions of Section 10 of RFC 2026. Internet-Drafts are +working documents of the Internet Engineering Task Force (IETF), its +areas, and its working groups. Note that other groups may also +distribute working documents as Internet-Drafts. + +Internet-Drafts are draft documents valid for a maximum of six months +and may be updated, replaced, or obsoleted by other documents at any +time. It is inappropriate to use Internet-Drafts as reference +material or to cite them other than as "work in progress." + +The list of current Internet-Drafts can be accessed at +http://www.ietf.org/ietf/1id-abstracts.txt + +The list of Internet-Draft Shadow Directories can be accessed at +http://www.ietf.org/shadow.html + +The distribution of this memo is unlimited. + + +.ti 0 +Abstract + +This memo describes two protocols used in the Secure Internet Live +Conferencing (SILC) protocol, specified in the Secure Internet Live +Conferencing, Protocol Specification [SILC1]. The SILC Key Exchange +(SKE) protocol provides secure key exchange between two parties +resulting into shared secret key material. The protocol is based +on Diffie-Hellman key exchange algorithm and its functionality is +derived from several key exchange protocols. + +The second protocol, SILC Connection Authentication protocol provides +user level authentication used when creating connections in SILC +network. The protocol is transparent to the authentication data +which means that it can be used to authenticate the connection with, for +example, passphrase (pre-shared secret) or public key (and certificate) +based on digital signatures. + + + +.ti 0 +Table of Contents + +.nf +1 Introduction .................................................. 2 + 1.1 Requirements Terminology .................................. 3 +2 SILC Key Exchange Protocol .................................... 3 + 2.1 Key Exchange Payloads ..................................... 4 + 2.1.1 Key Exchange Start Payload .......................... 4 + 2.1.2 Key Exchange Payload ................................ 8 + 2.2 Key Exchange Procedure .................................... 11 + 2.3 Processing the Key Material ............................... 12 + 2.4 SILC Key Exchange Groups .................................. 14 + 2.4.1 diffie-hellman-group1 ............................... 14 + 2.4.2 diffie-hellman-group2 ............................... 15 + 2.4.3 diffie-hellman-group3 ............................... 15 + 2.5 Key Exchange Status Types ................................. 16 +3 SILC Connection Authentication Protocol ....................... 17 + 3.1 Connection Auth Payload ................................... 18 + 3.2 Connection Authentication Types ........................... 19 + 3.2.1 Passphrase Authentication ........................... 19 + 3.2.2 Public Key Authentication ........................... 20 + 3.3 Connection Authentication Status Types .................... 21 +4 Security Considerations ....................................... 21 +5 References .................................................... 21 +6 Author's Address .............................................. 23 +7 Full Copyright Statement ...................................... 23 + + +.ti 0 +List of Figures + +.nf +Figure 1: Key Exchange Start Payload +Figure 2: Key Exchange Payload +Figure 3: Connection Auth Payload + + +.ti 0 +1 Introduction + +This memo describes two protocols used in the Secure Internet Live +Conferencing (SILC) protocol specified in the Secure Internet Live +Conferencing, Protocol Specification [SILC1]. The SILC Key Exchange +(SKE) protocol provides secure key exchange between two parties +resulting into shared secret key material. The protocol is based on +Diffie-Hellman key exchange algorithm and its functionality is derived +from several key exchange protocols, such as SSH2 Key Exchange protocol, +Station-To-Station (STS) protocol and the OAKLEY Key Determination +protocol [OAKLEY]. + +The second protocol, SILC Connection Authentication protocol provides +user level authentication used when creating connections in SILC +network. The protocol is transparent to the authentication data which +means that it can be used to authenticate the connection with, for example, +passphrase (pre-shared secret) or public key (and certificate) based +on digital signatures. + +The basis of secure SILC session requires strong and secure key exchange +protocol and authentication. The authentication protocol is secured and +no authentication data is ever sent in the network without encrypting +and authenticating it first. Thus, authentication protocol may be used +only after the key exchange protocol has been successfully completed. + +This document constantly refers to other SILC protocol specifications +that should be read to be able to fully understand the functionality +and purpose of these protocols. The most important references are +the Secure Internet Live Conferencing, Protocol Specification [SILC1] +and the SILC Packet Protocol [SILC2]. + +The protocol is intended to be used with the SILC protocol thus it +does not define own framework that could be used. The framework is +provided by the SILC protocol. + + +.ti 0 +1.1 Requirements Terminology + +The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, +MAY, and OPTIONAL, when they appear in this document, are to be +interpreted as described in [RFC2119]. + + +.ti 0 +2 SILC Key Exchange Protocol + +SILC Key Exchange Protocol (SKE) is used to exchange shared secret +material used to secure the communication channel. The protocol use +Diffie-Hellman key exchange algorithm and its functionality is derived +from several key exchange protocols, such as SSH2 Key Exchange protocol, +Station-To-Station (STS) protocol and the OAKLEY Key Determination +protocol [OAKLEY]. The protocol does not claim any conformance +to any of these protocols, they were only used as a reference when +designing this protocol. The protocol can mutually authenticate the +negotiating parties during the key exchange. + +The purpose of SILC Key Exchange protocol is to create session keys to +be used in current SILC session. The keys are valid only for some period +of time (usually an hour) or at most until the session ends. These keys +are used to protect packets traveling between the two entities. +Usually all traffic is secured with the key material derived from this +protocol. + +The Diffie-Hellman implementation used in the SILC SHOULD be compliant +to the PKCS #3. + + +.ti 0 +2.1 Key Exchange Payloads + +During the key exchange procedure public data is sent between initiator +and responder. This data is later used in the key exchange procedure. +There are several payloads used in the key exchange. As for all SILC +packets, SILC Packet Header, described in [SILC2], is at the beginning +of all packets sent in during this protocol. All the fields in the +following payloads are in MSB (most significant byte first) order. +Following descriptions of these payloads. + + +.ti 0 +2.1.1 Key Exchange Start Payload + +The key exchange between two entities MUST be started by sending the +SILC_PACKET_KEY_EXCHANGE packet containing Key Exchange Start Payload. +Initiator sends the Key Exchange Start Payload to the responder filled +with all security properties it supports. The responder then checks +whether it supports the security properties. + +It then sends a Key Exchange Start Payload to the initiator filled with +security properties it selected from the original payload. The payload +sent by responder MUST include only one chosen property per list. The +character encoding for the security property values as defined in [SILC1] +SHOULD be UTF-8 [RFC2279] in Key Exchange Start Payload. + +The Key Exchange Start Payload is used to tell connecting entities what +security properties and algorithms should be used in the communication. +The Key Exchange Start Payload is sent only once per session. Even if +the PFS (Perfect Forward Secrecy) flag is set the Key Exchange Start +Payload is not re-sent. When PFS is desired the Key Exchange Payloads +are sent to negotiate new key material. The procedure is equivalent to +the very first negotiation except that the Key Exchange Start Payload +is not sent. + +As this payload is used only with the very first key exchange the payload +is never encrypted, as there are no keys to encrypt it with. + +A cookie is also sent in this payload. A cookie is used to randomize the +payload so that none of the key exchange parties can determine this +payload before the key exchange procedure starts. The cookie MUST be +returned to the original sender unmodified by the responder. + +Following diagram represents the Key Exchange Start Payload. The lists +mentioned below are always comma (`,') separated and the list MUST NOT +include white spaces (` '). + + +.in 5 +.nf + 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| RESERVED | Flags | Payload Length | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| | ++ + +| | ++ Cookie + +| | ++ + +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Version String Length | | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +| | +~ Version String ~ +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Key Exchange Grp Length | | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +| | +~ Key Exchange Groups ~ +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| PKCS Alg Length | | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +| | +~ PKCS Algorithms ~ +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Encryption Alg Length | | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +| | +~ Encryption Algorithms ~ +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Hash Alg Length | | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +| | +~ Hash Algorithms ~ +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| HMAC Length | | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +| | +~ HMACs ~ +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Compression Alg Length | | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +| | +~ Compression Algorithms ~ +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +.in 3 + +.ce +Figure 1: Key Exchange Start Payload + + +.in 6 +o RESERVED (1 byte) - Reserved field. Sender fills this with + zero (0) value. + +o Flags (1 byte) - Indicates flags to be used in the key + exchange. Several flags can be set at once by ORing the + flags together. The following flags are reserved for this + field: + + No flags 0x00 + + In this case the field is ignored. + + IV Included 0x01 + + This flag is used to indicate that Initial Vector (IV) + in encryption will be included in the ciphertext + which the recipient must use in decryption. The IV + MUST be set after the last ciphertext block. With + this flag it is possible to use SILC protocol on + unreliable transport such as UDP/IP which may cause + packet reordering and packet losses. By default, + this flag is not set and thus IV is not included + in the ciphertext. Setting this flag increases the + ciphertext size by one ciphertext block. Responder + MAY override this flag for the initiator. + + PFS 0x02 + + Perfect Forward Secrecy (PFS) to be used in the + key exchange protocol. If not set, re-keying + is performed using the old key. See the [SILC1] + for more information on this issue. When PFS is + used, re-keying and creating new keys for any + particular purpose MUST cause new key exchange with + new Diffie-Hellman exponent values. In this key + exchange only the Key Exchange Payload is sent and + the Key Exchange Start Payload MUST NOT be sent. + When doing PFS the Key Exchange Payloads are + encrypted with the old keys. + + Mutual Authentication 0x04 + + Both of the parties will perform authentication + by providing signed data for the other party to + verify. By default, only responder will provide + the signature data. If this is set then the + initiator must also provide it. Initiator MAY + set this but also responder MAY set this even if + initiator did not set it. + + Rest of the flags are reserved for the future and + MUST NOT be set. + +o Payload Length (2 bytes) - Length of the entire Key Exchange + Start payload, not including any other field. + +o Cookie (16 bytes) - Cookie that randomize this payload so + that each of the party cannot determine the payload before + hand. This field MUST be present. + +o Version String Length (2 bytes) - The length of the Version + String field, not including any other field. + +o Version String (variable length) - Indicates the version of + the sender of this payload. Initiator sets this when sending + the payload and responder sets this when it replies by sending + this payload. See [SILC1] for definition for the version + string format. This field MUST be present and include valid + version string. + +o Key Exchange Grp Length (2 bytes) - The length of the + key exchange group list, not including any other field. + +o Key Exchange Group (variable length) - The list of + key exchange groups. See the section 2.4 SILC Key Exchange + Groups for definitions of these groups. This field MUST + be present. + +o PKCS Alg Length (2 bytes) - The length of the PKCS algorithms + list, not including any other field. + +o PKCS Algorithms (variable length) - The list of PKCS + algorithms. This field MUST be present. + +o Encryption Alg Length (2 bytes) - The length of the encryption + algorithms list, not including any other field. + +o Encryption Algorithms (variable length) - The list of + encryption algorithms. This field MUST be present. + +o Hash Alg Length (2 bytes) - The length of the Hash algorithm + list, not including any other field. + +o Hash Algorithms (variable length) - The list of Hash + algorithms. The hash algorithms are mainly used in the + SKE protocol. This field MUST be present. + +o HMAC Length (2 bytes) - The length of the HMAC list, not + including any other field. + +o HMACs (variable length) - The list of HMACs. The HMAC's + are used to compute the Message Authentication Code (MAC) + of the SILC packets. This field MUST be present. + +o Compression Alg Length (2 bytes) - The length of the + compression algorithms list, not including any other field. + +o Compression Algorithms (variable length) - The list of + compression algorithms. This field MAY be omitted. +.in 3 + + +.ti 0 +2.1.2 Key Exchange Payload + +Key Exchange payload is used to deliver the public key (or certificate), +the computed Diffie-Hellman public value and possibly signature data +from one party to the other. When initiator is using this payload +and the Mutual Authentication flag is not set then the initiator MUST +NOT provide the signature data. If the flag is set then the initiator +MUST provide the signature data so that the responder can verify it. + +The Mutual Authentication flag is usually used when a separate +authentication protocol will not be executed for the initiator of the +protocol. This is case for example when the SKE is performed between +two SILC clients. In normal case, where client is connecting to a +server, or server is connecting to a router the Mutual Authentication +flag MAY be omitted. However, if the connection authentication protocol +for the connecting entity is not based on digital signatures (it is +based on pre-shared key) then the Mutual Authentication flag SHOULD be +enabled. This way the connecting entity has to provide proof of +possession of the private key for the public key it will provide in +this protocol. + +When performing re-key with PFS selected this is the only payload that +is sent in the SKE protocol. The Key Exchange Start Payload MUST NOT +be sent at all. However, this payload does not have all the fields +present. In the re-key with PFS the public key and a possible signature +data SHOULD NOT be present. If they are present they MUST be ignored. +The only field that is present is the Public Data that is used to create +the new key material. In the re-key the Mutual Authentication flag, that +may be set in the initial negotiation, MUST also be ignored. + +This payload is sent inside SILC_PACKET_KEY_EXCHANGE_1 and inside +SILC_PACKET_KEY_EXCHANGE_2 packet types. The initiator uses the +SILC_PACKET_KEY_EXCHANGE_1 and the responder the latter. + +The following diagram represent the Key Exchange Payload. + + +.in 5 +.nf + 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Public Key Length | Public Key Type | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| | +~ Public Key of the party (or certificate) ~ +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Public Data Length | | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +| | +~ Public Data ~ +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Signature Length | | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +| | +~ Signature Data ~ +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +.in 3 + +.ce +Figure 2: Key Exchange Payload + + +.in 6 +o Public Key Length (2 bytes) - The length of the Public Key + (or certificate) field, not including any other field. + +o Public Key Type (2 bytes) - The public key (or certificate) + type. This field indicates the type of the public key in + the packet. Following types are defined: + + 1 SILC style public key (mandatory) + 2 SSH2 style public key (optional) + 3 X.509 Version 3 certificate (optional) + 4 OpenPGP certificate (optional) + 5 SPKI certificate (optional) + + The only required type to support is type number 1. See + [SILC1] for the SILC public key specification. See + SSH2 public key specification in [SSH-TRANS]. See X.509v3 + certificate specification in [PKIX-Part1]. See OpenPGP + certificate specification in [PGP]. See SPKI certificate + specification in [SPKI]. If this field includes zero (0) + or unsupported type number the protocol MUST be aborted + sending SILC_PACKET_FAILURE message and the connection SHOULD + be closed immediately. + +o Public Key (or certificate) (variable length) - The + public key or certificate of the party. This public key + is used to verify the digital signature. The public key + or certificate in this field is encoded in the manner as + defined in their respective definitions; see previous field. + +o Public Data Length (2 bytes) - The length of the Public Data + field, not including any other field. + +o Public Data (variable length) - The public data to be + sent to the receiver (computed Diffie-Hellman public values). + See section 2.2 Key Exchange Procedure for detailed description + how this field is computed. This field is MP integer and is + encoded as defined in [SILC1]. + +o Signature Length (2 bytes) - The length of the signature, + not including any other field. + +o Signature Data (variable length) - The signature signed + by the sender. The receiver of this signature MUST + verify it. The verification is done using the sender's + public key. See section 2.2 Key Exchange Procedure for + detailed description how to produce the signature. If + the Mutual Authentication flag is not set then initiator + MUST NOT provide this field and the Signature Length field + MUST be set to zero (0) value. If the flag is set then + also the initiator MUST provide this field. The responder + always MUST provide this field. The encoding for signature + is defined in [SILC1]. +.in 3 + + + +.ti 0 +2.2 Key Exchange Procedure + +The key exchange begins by sending SILC_PACKET_KEY_EXCHANGE packet with +Key Exchange Start Payload to select the security properties to be used +in the key exchange and later in the communication. + +After Key Exchange Start Payload has been processed by both of the +parties the protocol proceeds as follows: + + +Setup: p is a large and public safe prime. This is one of the + Diffie Hellman groups. q is order of subgroup (largest + prime factor of p). g is a generator and is defined + along with the Diffie Hellman group. + + 1. Initiator generates a random number x, where 1 < x < q, + and computes e = g ^ x mod p. The result e is then + encoded into Key Exchange Payload, with the public key + (or certificate) and sent to the responder. + + If the Mutual Authentication flag is set then initiator + MUST also produce signature data SIGN_i which the responder + will verify. The initiator MUST compute a hash value + HASH_i = hash(Initiator's Key Exchange Start Payload | + public key (or certificate) | e). The '|' stands for + concatenation. It then signs the HASH_i value with its + private key resulting a signature SIGN_i. + + 2. Responder generates a random number y, where 1 < y < q, + and computes f = g ^ y mod p. It then computes the + shared secret KEY = e ^ y mod p, and, a hash value + HASH = hash(Initiator's Key Exchange Start Payload | + public key (or certificate) | Initiator's public key + (or certificate) | e | f | KEY). It then signs + the HASH value with its private key resulting a signature + SIGN. + + It then encodes its public key (or certificate), f and + SIGN into Key Exchange Payload and sends it to the + initiator. + + If the Mutual Authentication flag is set then the responder + SHOULD verify that the public key provided in the payload + is authentic, or if certificates are used it verifies the + certificate. The responder MAY accept the public key without + verifying it, however, doing so may result to insecure key + exchange (accepting the public key without verifying may be + desirable for practical reasons on many environments. For + long term use this is never desirable, in which case + certificates would be the preferred method to use). It then + computes the HASH_i value the same way initiator did in the + phase 1. It then verifies the signature SIGN_i from the + payload with the hash value HASH_i using the received public + key. + + 3. Initiator verifies that the public key provided in + the payload is authentic, or if certificates are used + it verifies the certificate. The initiator MAY accept + the public key without verifying it, however, doing + so may result to insecure key exchange (accepting the + public key without verifying may be desirable for + practical reasons on many environments. For long term + use this is never desirable, in which case certificates + would be the preferred method to use). + + Initiator then computes the shared secret KEY = + f ^ x mod p, and, a hash value HASH in the same way as + responder did in phase 2. It then verifies the + signature SIGN from the payload with the hash value + HASH using the received public key. + + +If any of these phases is to fail the SILC_PACKET_FAILURE MUST be sent +to indicate that the key exchange protocol has failed, and the connection +SHOULD be closed immediately. Any other packets MUST NOT be sent or +accepted during the key exchange except the SILC_PACKET_KEY_EXCHANGE_*, +SILC_PACKET_FAILURE and SILC_PACKET_SUCCESS packets. + +The result of this protocol is a shared secret key material KEY and +a hash value HASH. The key material itself is not fit to be used as +a key, it needs to be processed further to derive the actual keys to be +used. The key material is also used to produce other security parameters +later used in the communication. See section 2.3 Processing the Key +Material for detailed description how to process the key material. + +If the Mutual Authentication flag was set the protocol produces also +a hash value HASH_i. This value, however, must be discarded. + +After the keys are processed the protocol is ended by sending the +SILC_PACKET_SUCCESS packet. Both entities send this packet to +each other. After this both parties MUST start using the new keys. + + +.ti 0 +2.3 Processing the Key Material + +Key Exchange protocol produces secret shared key material KEY. This +key material is used to derive the actual keys used in the encryption +of the communication channel. The key material is also used to derive +other security parameters used in the communication. Key Exchange +protocol produces a hash value HASH as well. + +The keys MUST be derived from the key material as follows: + +.in 6 +Sending Initial Vector (IV) = hash(0x0 | KEY | HASH) +Receiving Initial Vector (IV) = hash(0x1 | KEY | HASH) +Sending Encryption Key = hash(0x2 | KEY | HASH) +Receiving Encryption Key = hash(0x3 | KEY | HASH) +Sending HMAC Key = hash(0x4 | KEY | HASH) +Receiving HMAC Key = hash(0x5 | KEY | HASH) +.in 3 + + +The Initial Vector (IV) is used in the encryption when doing for +example CBC mode. As many bytes as needed are taken from the start of +the hash output for IV. Sending IV is for sending key and receiving IV +is for receiving key. For receiving party, the receiving IV is actually +sender's sending IV, and, the sending IV is actually sender's receiving +IV. Initiator uses IV's as they are (sending IV for sending and +receiving IV for receiving). + +The Encryption Keys are derived as well from the hash(). If the hash() +output is too short for the encryption algorithm more key material MUST +be produced in the following manner: + +.in 6 +K1 = hash(0x2 | KEY | HASH) +K2 = hash(KEY | HASH | K1) +K3 = hash(KEY | HASH | K1 | K2) ... + +Sending Encryption Key = K1 | K2 | K3 ... + + +K1 = hash(0x3 | KEY | HASH) +K2 = hash(KEY | HASH | K1) +K3 = hash(KEY | HASH | K1 | K2) ... + +Receiving Encryption Key = K1 | K2 | K3 ... +.in 3 + + +The key is distributed by hashing the previous hash with the original +key material. The final key is a concatenation of the hash values. +For Receiving Encryption Key the procedure is equivalent. Sending key +is used only for encrypting data to be sent. The receiving key is used +only to decrypt received data. For receiving party, the receive key is +actually sender's sending key, and, the sending key is actually sender's +receiving key. Initiator uses generated keys as they are (sending key +for sending and receiving key for receiving). + +The HMAC keys are used to create MAC values to packets in the +communication channel. As many bytes as needed are taken from the start +of the hash output to generate the MAC keys. + +These procedures are performed by all parties of the key exchange +protocol. This MUST be done before the protocol has been ended by +sending the SILC_PACKET_SUCCESS packet, to assure that parties can +successfully process the key material. + +This same key processing procedure MAY be used in the SILC in some +other circumstances as well. Any changes to this procedure is defined +separately when this procedure is needed. See the [SILC1] and the +[SILC2] for these circumstances. + + +.ti 0 +2.4 SILC Key Exchange Groups + +The Following groups may be used in the SILC Key Exchange protocol. +The first group diffie-hellman-group1 is REQUIRED, other groups MAY be +negotiated to be used in the connection with Key Exchange Start Payload +and SILC_PACKET_KEY_EXCHANGE packet. However, the first group MUST be +proposed in the Key Exchange Start Payload regardless of any other +requested group (however, it does not have to be the first in the list). + + +.ti 0 +2.4.1 diffie-hellman-group1 + +The length of this group is 1024 bits. This is REQUIRED group. +The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. + +Its hexadecimal value is + +.in 6 +FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 +29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD +EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 +E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED +EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 +FFFFFFFF FFFFFFFF +.in 3 + + +The generator used with this prime is g = 2. The group order q is +(p - 1) / 2. + +This group was taken from RFC 2412. + + +.ti 0 +2.4.2 diffie-hellman-group2 + +The length of this group is 1536 bits. This is OPTIONAL group. +The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 }. + +Its hexadecimal value is + +.in 6 +FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 +29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD +EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 +E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED +EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D +C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F +83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D +670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF +.in 3 + +The generator used with this prime is g = 2. The group order q is +(p - 1) / 2. + +This group was taken from RFC 3526. + + +.ti 0 +2.4.3 diffie-hellman-group3 + +The length of this group is 2048 bits. This is OPTIONAL group. +This prime is: 2^2048 - 2^1984 - 1 + 2^64 * { [2^1918 pi] + 124476 }. + +Its hexadecimal value is + +.in 6 +FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 +29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD +EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 +E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED +EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D +C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F +83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D +670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B +E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 +DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510 +15728E5A 8AACAA68 FFFFFFFF FFFFFFFF +.in 3 + +The generator used with this prime is g = 2. The group order q is +(p - 1) / 2. + +This group was taken from RFC 3526. + +Additional larger groups are defined in RFC 3526 and may be used in SKE +by defining name for them using the above name format. + + +.ti 0 +2.5 Key Exchange Status Types + +This section defines all key exchange protocol status types that may +be returned in the SILC_PACKET_SUCCESS or SILC_PACKET_FAILURE packets +to indicate the status of the protocol. Implementations may map the +status types to human readable error message. All types except the +SILC_SKE_STATUS_OK type MUST be sent in SILC_PACKET_FAILURE packet. +The length of status is 32 bits (4 bytes). The following status types +are defined: + +.in 6 +0 SILC_SKE_STATUS_OK + + Protocol were executed successfully. + + +1 SILC_SKE_STATUS_ERROR + + Unknown error occurred. No specific error type is defined. + + +2 SILC_SKE_STATUS_BAD_PAYLOAD + + Provided KE payload were malformed or included bad fields. + + +3 SILC_SKE_STATUS_UNSUPPORTED_GROUP + + None of the provided groups were supported. + + +4 SILC_SKE_STATUS_UNSUPPORTED_CIPHER + + None of the provided ciphers were supported. + + +5 SILC_SKE_STATUS_UNSUPPORTED_PKCS + + None of the provided public key algorithms were supported. + + +6 SILC_SKE_STATUS_UNSUPPORTED_HASH_FUNCTION + + None of the provided hash functions were supported. + + +7 SILC_SKE_STATUS_UNSUPPORTED_HMAC + + None of the provided HMACs were supported. + + +8 SILC_SKE_STATUS_UNSUPPORTED_PUBLIC_KEY + + Provided public key type is not supported. + + +9 SILC_SKE_STATUS_INCORRECT_SIGNATURE + + Provided signature was incorrect. + + +10 SILC_SKE_STATUS_BAD_VERSION + + Provided version string was not acceptable. + + +11 SILC_SKE_STATUS_INVALID_COOKIE + + The cookie in the Key Exchange Start Payload was malformed, + because responder modified the cookie. +.in 3 + + +.ti 0 +3 SILC Connection Authentication Protocol + +Purpose of Connection Authentication protocol is to authenticate the +connecting party with server. Usually connecting party is client but +server may connect to router server as well. Its other purpose is to +provide information for the server about which type of entity the +connection is. The type defines whether the connection is client, +server or router connection. Server use this information to create the +ID for the connection. + +Server MUST verify the authentication data received and if it is to fail +the authentication MUST be failed by sending SILC_PACKET_FAILURE packet. +If authentication is successful the protocol is ended by server by sending +SILC_PACKET_SUCCESS packet. + +The protocol is executed after the SILC Key Exchange protocol. It MUST +NOT be executed in any other time. As it is performed after key exchange +protocol all traffic in the connection authentication protocol is +encrypted with the exchanged keys. + +The protocol MUST be started by the connecting party by sending the +SILC_PACKET_CONNECTION_AUTH packet with Connection Auth Payload, +described in the next section. This payload MUST include the +authentication data. The authentication data is set according +authentication method that MUST be known by both parties. If connecting +party does not know what is the mandatory authentication method it MAY +request it from the server by sending SILC_PACKET_CONNECTION_AUTH_REQUEST +packet. This packet is not part of this protocol and is described in +section Connection Auth Request Payload in [SILC2]. However, if +connecting party already knows the mandatory authentication method +sending the request is not necessary. + +See [SILC1] and section Connection Auth Request Payload in [SILC2] also +for the list of different authentication methods. Authentication method +MAY also be NONE, in which case the server does not require +authentication. However, in this case the protocol still MUST be +executed; the authentication data is empty indicating no authentication +is required. + +If authentication method is passphrase the authentication data is +plaintext passphrase. As the payload is encrypted it is safe to have +plaintext passphrase. It is also provided as plaintext passphrase +because the receiver may need to pass the entire passphrase into a +passphrase verifier, and a message digest of the passphrase would +prevent this. See the section 3.2.1 Passphrase Authentication for +more information. + +If authentication method is public key authentication the authentication +data is a digital signature of the hash value of hash HASH and Key +Exchange Start Payload, established by the SILC Key Exchange protocol. +This signature MUST then be verified by the server. See the section +3.2.2 Public Key Authentication for more information. + +See the section 4 SILC Procedures in [SILC1] for more information about +client creating connection to server, and server creating connection +to router, and how to register the session in the SILC Network after +successful Connection Authentication protocol. + + +.ti 0 +3.1 Connection Auth Payload + +Client sends this payload to authenticate itself to the server. Server +connecting to another server also sends this payload. Server receiving +this payload MUST verify all the data in it and if something is to fail +the authentication MUST be failed by sending SILC_PACKET_FAILURE packet. + +The payload may only be sent with SILC_PACKET_CONNECTION_AUTH packet. +It MUST NOT be sent in any other packet type. The following diagram +represent the Connection Auth Payload. + + + + + + + +.in 5 +.nf + 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Payload Length | Connection Type | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| | +~ Authentication Data ~ +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +.in 3 + +.ce +Figure 3: Connection Auth Payload + + +.in 6 +o Payload Length (2 bytes) - Length of the entire Connection + Auth Payload. + +o Connection Type (2 bytes) - Indicates the type of the + connection. See section Connection Auth Request Payload + in [SILC2] for the list of connection types. This field MUST + include valid connection type or the packet MUST be discarded + and authentication MUST be failed. + +o Authentication Data (variable length) - The actual + authentication data. Contents of this depends on the + authentication method known by both parties. If no + authentication is required this field does not exist. +.in 3 + + +.ti 0 +3.2 Connection Authentication Types + +SILC supports two authentication types to be used in the connection +authentication protocol; passphrase authentication or public key +authentication based on digital signatures. The following sections +defines the authentication methods. See [SILC2] for defined numerical +authentication method types. + + +.ti 0 +3.2.1 Passphrase Authentication + +Passphrase authentication or pre-shared key based authentication is +simply an authentication where the party that wants to authenticate +itself to the other end sends the passphrase that is required by +the other end, for example server. The plaintext passphrase is put +to the payload, that is then encrypted. The plaintext passphrase +MUST be in UTF-8 [RFC2279] encoding. If the passphrase is in the +sender's system in some other encoding it MUST be UTF-8 encoded +before transmitted. The receiver MAY change the encoding of the +passphrase to its system's default character encoding before verifying +the passphrase. + +If the passphrase matches with the one in the server's end the +authentication is successful. Otherwise SILC_PACKET_FAILURE MUST be +sent to the sender and the protocol execution fails. + +This is REQUIRED authentication method to be supported by all SILC +implementations. + +When password authentication is used it is RECOMMENDED that maximum +amount of padding is applied to the SILC packet. This way it is not +possible to approximate the length of the password from the encrypted +packet. + + + +.ti 0 +3.2.2 Public Key Authentication + +Public key authentication may be used if passphrase based authentication +is not desired. The public key authentication works by sending a +digital signature as authentication data to the other end, say, server. +The server MUST then verify the signature by the public key of the sender, +which the server has received earlier in SKE protocol. + +The signature is computed using the private key of the sender by signing +the HASH value provided by the SKE protocol previously, and the Key +Exchange Start Payload from SKE protocol that was sent to the server. +These are concatenated and hash function is used to compute a hash value +which is then signed. + + auth_hash = hash(HASH | Key Exchange Start Payload); + signature = sign(auth_hash); + +The hash() function used to compute the value is the hash function +negotiated in the SKE protocol. The server MUST verify the data, thus +it must keep the HASH and the Key Exchange Start Payload saved during +SKE and authentication protocols. These values can be discarded after +Connection Authentication protocol is completed. + +If the verified signature matches the sent signature, the authentication +were successful and SILC_PACKET_SUCCESS is sent. If it failed the +protocol execution is stopped and SILC_PACKET_FAILURE is sent. + +This is REQUIRED authentication method to be supported by all SILC +implementations. + + + +.ti 0 +3.3 Connection Authentication Status Types + +This section defines all connection authentication status types that +may be returned in the SILC_PACKET_SUCCESS or SILC_PACKET_FAILURE packets +to indicate the status of the protocol. Implementations may map the +status types to human readable error message. All types except the +SILC_AUTH_STATUS_OK type MUST be sent in SILC_PACKET_FAILURE packet. +The length of status is 32 bits (4 bytes). The following status types +are defined: + +0 SILC_AUTH_OK + + Protocol was executed successfully. + + +1 SILC_AUTH_FAILED + + Authentication failed. + + +.ti 0 +4 Security Considerations + +Security is central to the design of this protocol, and these security +considerations permeate the specification. Common security considerations +such as keeping private keys truly private and using adequate lengths for +symmetric and asymmetric keys must be followed in order to maintain the +security of this protocol. + + +.ti 0 +5 References + +[SILC1] Riikonen, P., "Secure Internet Live Conferencing (SILC), + Protocol Specification", Internet Draft, June 2003. + +[SILC2] Riikonen, P., "SILC Packet Protocol", Internet Draft, + June 2003. + +[SILC4] Riikonen, P., "SILC Commands", Internet Draft, June 2003. + +[IRC] Oikarinen, J., and Reed D., "Internet Relay Chat Protocol", + RFC 1459, May 1993. + +[IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, + April 2000. + +[IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC + 2811, April 2000. + +[IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC + 2812, April 2000. + +[IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC + 2813, April 2000. + +[SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol", + Internet Draft. + +[PGP] Callas, J., et al, "OpenPGP Message Format", RFC 2440, + November 1998. + +[SPKI] Ellison C., et al, "SPKI Certificate Theory", RFC 2693, + September 1999. + +[PKIX-Part1] Housley, R., et al, "Internet X.509 Public Key + Infrastructure, Certificate and CRL Profile", RFC 2459, + January 1999. + +[Schneier] Schneier, B., "Applied Cryptography Second Edition", + John Wiley & Sons, New York, NY, 1996. + +[Menezes] Menezes, A., et al, "Handbook of Applied Cryptography", + CRC Press 1997. + +[OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol", + RFC 2412, November 1998. + +[ISAKMP] Maughan D., et al, "Internet Security Association and + Key Management Protocol (ISAKMP)", RFC 2408, November + 1998. + +[IKE] Harkins D., and Carrel D., "The Internet Key Exchange + (IKE)", RFC 2409, November 1998. + +[HMAC] Krawczyk, H., "HMAC: Keyed-Hashing for Message + Authentication", RFC 2104, February 1997. + +[PKCS1] Kalinski, B., and Staddon, J., "PKCS #1 RSA Cryptography + Specifications, Version 2.0", RFC 2437, October 1998. + +[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + +[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", RFC 2279, January 1998. + + +.ti 0 +6 Author's Address + +.nf +Pekka Riikonen +Snellmaninkatu 34 A 15 +70100 Kuopio +Finland + +EMail: priikone@iki.fi + + +.ti 0 +7 Full Copyright Statement + +Copyright (C) The Internet Society (2003). All Rights Reserved. + +This document and translations of it may be copied and furnished to +others, and derivative works that comment on or otherwise explain it +or assist in its implementation may be prepared, copied, published +and distributed, in whole or in part, without restriction of any +kind, provided that the above copyright notice and this paragraph are +included on all such copies and derivative works. However, this +document itself may not be modified in any way, such as by removing +the copyright notice or references to the Internet Society or other +Internet organizations, except as needed for the purpose of +developing Internet standards in which case the procedures for +copyrights defined in the Internet Standards process must be +followed, or as required to translate it into languages other than +English. + +The limited permissions granted above are perpetual and will not be +revoked by the Internet Society or its successors or assigns. + +This document and the information contained herein is provided on an +"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING +TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING +BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION +HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF +MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. -- 2.43.0