diff options
Diffstat (limited to 'doc/rfc/rfc2726.txt')
| -rw-r--r-- | doc/rfc/rfc2726.txt | 619 |
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc2726.txt b/doc/rfc/rfc2726.txt new file mode 100644 index 0000000..9e6e70b --- /dev/null +++ b/doc/rfc/rfc2726.txt @@ -0,0 +1,619 @@ + + + + + + +Network Working Group J. Zsako +Request for Comments: 2726 BankNet +Category: Standards Track December 1999 + + + PGP Authentication for RIPE Database Updates + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1999). All Rights Reserved. + +Abstract + + This document presents the proposal for a stronger authentication + method of the updates of the RIPE database based on digital + signatures. The proposal tries to be as general as possible as far as + digital signing methods are concerned, however, it concentrates + mainly on PGP, as the first method to be implemented. The proposal + is the result of the discussions within the RIPE DBSEC Task Force. + +1. Rationale + + An increasing need has been identified for a stronger authentication + of the database maintainer upon database updates (addition, + modification and deletion of objects). The existing authentication + methods have serious security problems: the MAIL-FROM has the + drawback that a mail header is very easy to forge whereas CRYPT-PW is + exposed to message interception, since the password is sent + unencrypted in the update mail message. + + The goal was to implement a digital signature mechanism based on a + widely available and deployed technology. The first choice was PGP, + other methods may follow at a later date. PGP is presently quite + widely used within the Internet community and is available both in + and outside the US. + + The current aim is for an improved authentication method and nothing + more (in particular, this paper does not try to cover authorization + issues other than those related to authentication). + + + + +Zsako Standards Track [Page 1] + +RFC 2726 PGP Authentication for RIPE Database Updates December 1999 + + +2. Changes to the RIPE database + + In order to make the database as much self consistent as possible, + the key certificates are stored in the RIPE database. For efficiency + reasons a local keyring of public keys will also be maintained, + however, the local keyring will only contain a copy of the key + certificates present in the database. The synchronization of the + database with the local keyring will be made as often as possible. + The database objects will be created only via the current e-mail + mechanism (auto-dbm@ripe.net), in particular no public key + certificate will be retrieved from a key server by the database + software. + + The presence of the key certificates in the database will allow the + users of the database to check the "identity" of the maintainer, in + the sense that they can query the database for the certificate of the + key the database software uses for authenticating the maintainer. + This key certificate can then be checked for existing signatures and + can possibly be compared with the key certificate obtained by other + means for the same user (e.g. from the owner himself of from a public + key server). Although the key certificates can be stored in the RIPE + database with any number of signatures, since the RIPE database is + not communicating directly with the public key servers, it is a good + practice to add the key certificate with the minimum number of + signatures possible (preferably with just one signature: the one of + itself). See also section 4. for more details. + +2.1. The key-cert object + + A new object type is defined below for the purpose of storing the key + certificates of the maintainers: + + key-cert: [mandatory] [single] [primary/look-up key] + method: [generated] [single] [ ] + owner: [generated] [multiple] [ ] + fingerpr: [generated] [single] [ ] + certif: [mandatory] [single] [ ] + remarks: [optional] [multiple] [ ] + notify: [optional] [multiple] [inverse key] + mnt-by: [mandatory] [multiple] [inverse key] + changed: [mandatory] [multiple] [ ] + source: [mandatory] [single] [ ] + + The syntax and the semantics of the different attributes are + described below. + + + + + + +Zsako Standards Track [Page 2] + +RFC 2726 PGP Authentication for RIPE Database Updates December 1999 + + + key-cert: Is of the form PGPKEY-hhhhhhhh, where hhhhhhhh stands for + for the hex representation of the four bytes ID of the PGP key. + The key certificate detailed in the certif attribute belongs to + the PGP key with the id hhhhhhhh. The reason for having PGPKEY- as + a prefix is to allow for other types of key certificates at a + later date, and at the same time to be able to clearly + differentiate at query time between a person query and a key + certificate query. At the time of the creation/modification of + the key-cert object, the database software checks whether the key + certificate in the certif attribute indeed belongs to the PGP id + specified here. The creation/modification is authorized only upon + the match of these two ids. + + method: Line containing the name of the signing method. This is the + name of the digital signature method. The present certificate + belongs to a key for digitally signing messages using the + specified method. The method attribute is generated automatically + by the database software upon creation of the key-cert object. + Any method attribute present in the object at the time of the + submission for creation is ignored. The method has to be + consistent with both the prefix of the id in the key-cert + attribute and with the certificate contained in the certif + attributes. If these latter two (i.e. prefix and certificate) are + not consistent, the key-cert object creation is refused. For the + PGP method this will be the string "PGP" (without the quotes). + + owner: Line containing a description of the owner of the key. For a + PGP key, the owners are the user ids associated with the key. For + each user id present in the key certificate, an owner attribute is + generated automatically by the database software upon creation of + the key-cert object. Any owner attribute present in the object at + the time of the submission for creation is ignored. + + fingerpr: A given number of hex encoded bytes, separated for better + readability by spaces. It represents the fingerprint of the key + associated with the present certificate. This is also a field + generated upon creation of the object instance. Any fingerpr + attribute submitted to the robot is ignored. The reason for + having this attribute (and the owner attribute) is to allow for an + easy check of the key certificate upon a query of the database. + The querier gets the owner and fingerprint information without + having to add the certificate to his/her own public keyring. + Also, since these two attributes are _generated_ by the database + software from the certificate, one can trust them (as much as one + can trust the database itself). + + + + + + +Zsako Standards Track [Page 3] + +RFC 2726 PGP Authentication for RIPE Database Updates December 1999 + + + certif: Line containing a line of the ASCII armoured key + certificate. The certif attribute lines contain the key + certificate. In the case of PGP, they also contain the delimiting + lines (BEGIN/END PGP PUBLIC KEY BLOCK). Obviously the order of + the lines is essential, therefore the certif attribute lines are + presented at query time in the same order as they have been + submitted at creation. A database client application could + contain a script that strips the certif attribute lines (returned + as a result of a query) from the leading "certif:" string and the + following white spaces and import the remainder in the local + keyring. + + mnt-by: The usual syntax the usual semantics this attribute is + _mandatory_ for this object. Therefore, the existence of a mntner + object is a prerequisite for the creation of a key-cert object. + The mntner referenced in the mnt-by attribute may not have the + auth attribute set to NONE. + + remarks:, + notify:, + changed:, + source: the usual syntax and semantics. + + In the case of PGP, when a key-cert object is created, the associated + key is also added to a local keyring of public keys. When a key-cert + object is deleted, the corresponding public key is deleted from the + local keyring as well. Whenever a key-cert object is modified, the + key is deleted from the local keyring and the key associated with the + new certificate is added to the keyring (obviously this is performed + only when the database update is authorized, in particular if the new + key certificate does belong to the id specified in the attribute + key-cert, see above). + +2.2. Changes to the mntner object + + The only change is that there is a new possible value for the auth + attribute. This value is of the form PGPKEY-<id>, where <id> is the + hex representation of the four bytes id of the PGP public key used + for authentication. + + The semantics of this new value is that the PGP key associated with + the key certificate stored in the key-cert object identified by + PGPKEY-id is used to check the signature of any + creation/modification/deletion message sent to auto-dbm@ripe.net + affecting an object maintained by this mntner. + + + + + + +Zsako Standards Track [Page 4] + +RFC 2726 PGP Authentication for RIPE Database Updates December 1999 + + + Just as with other values, the auth attribute can be multiple. It + does not make much sense to have two auth attributes with different + methods (e.g. PGPKEY-<id> and NONE :)) ), just as it didn't earlier + either. + + If there are several auth methods with a PGPKEY-<id> value, the + semantics is the already known one, namely that _either_ signature is + accepted. + +3. The PGP signed creation/modification/deletion + + The whole message has to be signed. This means, that the database + software first checks whether the message is a PGP signed message. If + it is, it checks for a valid signature and associates this signature + with the objects submitted in the message. A message may contain only + one PGP signature. + + If an object present in a message has a mnt-by attribute, and the + respective mntner has auth attribute(s) with PGPKEY-<id> value, the + database software checks whether the object has a signature + associated with it (i.e. whether the message being processed had been + signed) and whether the type of the signature (PGP in this + implementation phase) and the id of the key used for signing the + message is the same as the one in (one of) the auth attribute(s). The + creation/modification/deletion of the object is performed only if + this authentication succeeds. + + This approach allows for a simplification of the message parsing + process. A different approach would be necessary if one would sign + the _objects_, rather then the update messages. In case the objects + would be signed, the parser would have to identify which objects were + signed, check the signature(s) on each object individually and + permit/refuse the update at an object level, depending on (amongst + others) whether the signature is valid and whether it belongs to (one + of) the maintainer(s). This approach would allow for mixing in the + same e-mail message objects signed by different maintainers (which + would probably not be typical), and it would also allow for storing + the signature in the database (in order to allow for the verification + of the signature at query time). This latter (i.e. storing the + signatures in the database) is beyond the scope of the first phase of + the implementation. It may become a goal at a later date. + + It is recommended to check that the mailer program does not make any + transformations on the text of the e-mail message (and possibly + configure it not to do any). Such common transformations are line- + wrapping after a given number of characters, transforming of tabs in + spaces, etc. Also check that you only use ASCII characters in the + message. + + + +Zsako Standards Track [Page 5] + +RFC 2726 PGP Authentication for RIPE Database Updates December 1999 + + +4. Requirements the PGP key certificates must meet + + There is no limitation imposed with respect to the version of the PGP + software that is/was used for the creation of the key. Key of both + version 2.x and 5.0 are supported, although the keys generated with + version 5.0 are recommended. + + The key certificates submitted for creating a key-cert object must + contain a signature of the key itself. Although the certificate may + contain other signatures as well, it is recommended to create the + key-cert object with as few signatures as possible in the + certificate. Anyone concerned about the trustfulness of the key + should retrieve a copy of the key certificate from a public key + server (or by any other appropriate means and check the signatures + present in _that_ certificate. If such a check is performed one + should take care to check both the key fingerprint and the key type + and length in order to make sure the two certificates (the one + retrieved from the RIPE database and the one retrieved from the + public key server or collected by other means) belong to the same + key. + + Although it is highly unlikely, it may happen that a key-cert with + the id identical to the id of the key of a maintainer already exists + in the RIPE database. In case this latter key had been used for a + while and it had been registered at public key servers for some time, + the given person should contact the RIPE NCC and report this to + ripe-dbm@ripe.net. Anyway, he/she may have to create a new key and + register _its_ certificate into the RIPE database. Such a procedure, + although highly unlikely to happen, should not create serious + problems to the respective maintainer. + +5. Short overview of the tasks to be performed in order to use PGP + authentication + + You must have a mntner object in the RIPE database with auth: other + than NONE. The mntner object has to be created in the traditional + way. + + You must get a certificate of your own key and prepare a key-cert + object from it. The object has to reference in mnt-by the mntner + mentioned above. + + Create the key-cert object in the RIPE database, by sending the + object prepared above to auto-dbm@ripe.net. Obviously you must pass + the authentication checks required by the mntner object (i.e. mail + from a predefined address or send the correct password). + + + + + +Zsako Standards Track [Page 6] + +RFC 2726 PGP Authentication for RIPE Database Updates December 1999 + + + Change the mntner object to have the auth: attribute value of + PGPKEY-<id>, where <id> is the hex id of your PGP key. + + Check all objects maintained by the given mntner (preferably with the + command This is the only way to benefit from the stronger + authentication method in order to assign more trustfulness to the + database. Remember that you are the only person who can check for and + correct possible inconsistencies. + + From now on always sign the (whole) update messages that refer to + objects maintained by you, with the key you submitted to the RIPE + database. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zsako Standards Track [Page 7] + +RFC 2726 PGP Authentication for RIPE Database Updates December 1999 + + +6. Example of objects using the new feature + + mntner: AS3244-MNT + descr: BankNet, Budapest HU + descr: Eastern European Internet Provider via own VSAT network + admin-c: JZ38 + tech-c: JZ38 + tech-c: IR2-RIPE + upd-to: ncc@banknet.net + mnt-nfy: ncc@banknet.net + auth: PGPKEY-23F5CE35 + remarks: This is the maintainer of all BankNet related objects + notify: ncc@banknet.net + mnt-by: AS3244-MNT + changed: zsako@banknet.net 19980525 + source: RIPE + + key-cert: PGPKEY-23F5CE35 + method: PGP + owner: Janos Zsako <zsako@banknet.net> + fingerpr: B5 D0 96 D0 D0 D3 2B B2 B8 C2 5D 22 D4 F5 78 92 + certif: -----BEGIN PGP PUBLIC KEY BLOCK----- + Version: 2.6.2i + + + mQCNAzCqKdIAAAEEAPMSQtBNFFuTS0duoUiqnPHm05dxrI76rrOGwx+OU5tzGavx + cm2iCInNtikeKjlIMD7FiCH1J8PWdZivpwhzuGeeMimT8ZmNn4z3bb6ELRyiZOvs + 4nfxVlh+kKKD9JjBfy8DnuMs5sT0jw4FEt/PYogJinFdndzywXHzGHEj9c41AAUR + tB9KYW5vcyBac2FrbyA8enNha29AYmFua25ldC5uZXQ+iQCVAwUQMjkx2XHzGHEj + 9c41AQEuagP/dCIBJP+R16Y70yH75kraRzXY5rnsHmT0Jknrc/ihEEviRYdMV7X1 + osP4pmDU8tNGf0OfGrok7KDTCmygIh7/me+PKrDIj0YkAVUhBX3gBtpSkhEmkLqf + xbhYwDn4DV3zF7f5AMsbD0UCBDyf+vpkMzgd1Pbr439iXdgwgwta50qJAHUDBRAy + OSsrO413La462EEBAdIuAv4+Cao1wqBG7+gIm1czIb1M2cAM7Ussx6y+oL1d+HqN + PRhx4upLVg8Eqm1w4BYpOxdZKkxumIrIvrSxUYv4NBnbwQaa0/NmBou44jqeN+y2 + xwxAEVd9BCUtT+YJ9iMzZlE= + =w8xL + -----END PGP PUBLIC KEY BLOCK----- + remarks: This is an example of PGP key certificate + mnt-by: AS3244-MNT + changed: zsako@banknet.net 19980525 + source: RIPE + + + + + + + + + + + +Zsako Standards Track [Page 8] + +RFC 2726 PGP Authentication for RIPE Database Updates December 1999 + + +7. Security Considerations + + This document addresses authentication of transactions for making + additions, deletions, and updates to the routing policy information + through strong cryptographic means. The authorization of these + transactions are addressed in [1]. + +8. Acknowledgements + + The present proposal is the result of the discussions within the RIPE + DBSEC Task Force, which was set up at RIPE 27 in Dublin at the + initiative of Joachim Schmitz and Wilfried Woeber. The list of + participants who have contributed to the discussions at different + ocasions (TF meetings and via e-mail) is (in alphabetical order): + Cengiz Allaettinoglu, Joao Luis Silva Damas, Havard Eidnes, Chris + Fletcher, Daniel Karrenberg, David Kessens, Jake Khuon, Craig + Labovitz, Carl Malamud, Dave Meyer, Maldwyn Morris, Sandy Murphy, + Mike Norris, Carol Orange, Joachim Schmitz, Tom Spindler, Don + Stikvoort, Curtis Villamizar, Gerald Winters, Wilfried Woeber, Janos + Zsako. + +9. References + + [1] Meyer, D., Villamizar, C., Alaettinoglu, C. and S. Murphy, + "Routing Policy System Security", RFC 2725, December 1999. + +10. Author's Address + + Janos Zsako + BankNet + 1121 Budapest + Konkoly-Thege ut 29-33. + Hungary + + Phone: +36 1 395 90 28 + Fax: +36 1 395 90 32 + EMail: zsako@banknet.net + + + + + + + + + + + + + + +Zsako Standards Track [Page 9] + +RFC 2726 PGP Authentication for RIPE Database Updates December 1999 + + +11. Notices + + PGP is a commercial software. + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zsako Standards Track [Page 10] + +RFC 2726 PGP Authentication for RIPE Database Updates December 1999 + + +12. Full Copyright Statement + + Copyright (C) The Internet Society (1999). 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Zsako Standards Track [Page 11] + |