< draft-ietf-sidr-rpsl-sig-03.txt		draft-ietf-sidr-rpsl-sig-04.txt >
	SIDR R. Kisteleki		SIDR R. Kisteleki
	Internet-Draft RIPE NCC		Internet-Draft RIPE NCC
	Intended status: Standards Track B. Haberman		Intended status: Standards Track B. Haberman
	Expires: January 11, 2011 JHU APL		Expires: October 8, 2012 JHU APL
	July 10, 2010		April 6, 2012
	Securing RPSL Objects with RPKI Signatures		Securing RPSL Objects with RPKI Signatures
	draft-ietf-sidr-rpsl-sig-03.txt		draft-ietf-sidr-rpsl-sig-04.txt
	Abstract		Abstract
	This document describes a method to allow parties to electronically		This document describes a method to allow parties to electronically
	sign RPSL-like objects and validate such electronic signatures. This		sign RPSL-like objects and validate such electronic signatures. This
	allows relying parties to detect accidental or malicious		allows relying parties to detect accidental or malicious
	modifications on such objects. It also allows parties who run		modifications on such objects. It also allows parties who run
	Internet Routing Registries or similar databases, but do not yet have		Internet Routing Registries or similar databases, but do not yet have
	RPSS-like authentication of the maintainers of certain objects, to		RPSS-like authentication of the maintainers of certain objects, to
	verify that the additions or modifications of such database objects		verify that the additions or modifications of such database objects
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on January 11, 2011.		This Internet-Draft will expire on October 8, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2012 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 3, line 23 ¶		skipping to change at page 3, line 23 ¶
	authentication is not guaranteed. This means when downloading an		authentication is not guaranteed. This means when downloading an
	object stored in this database, one can reasonably safely claim that		object stored in this database, one can reasonably safely claim that
	the object is authentic, but for an imported object one cannot.		the object is authentic, but for an imported object one cannot.
	Also, once such an object is downloaded from the database, it becomes		Also, once such an object is downloaded from the database, it becomes
	a simple (but still structured) text file with no integrity		a simple (but still structured) text file with no integrity
	protection. More importantly, the authentication and integrity		protection. More importantly, the authentication and integrity
	guarantees associated with these objects do not always ensure that		guarantees associated with these objects do not always ensure that
	the entity that generated them is authorized to make the assertions		the entity that generated them is authorized to make the assertions
	implied by the data contained in the objects.		implied by the data contained in the objects.
	A potential use for resource certificates [I-D.ietf-sidr-res-certs]		A potential use for resource certificates [RFC6487] is to use them to
	is to use them to secure such (both imported and downloaded) database		secure such (both imported and downloaded) database objects, by
	objects, by applying a form of digital signature over the object		applying a form of digital signature over the object contents. A
	contents. A maintainer of such signed database objects MUST possess		maintainer of such signed database objects MUST possess a relevant
	a relevant resource certificate, which shows him/her as the		resource certificate, which shows him/her as the legitimate holder of
	legitimate holder of an Internet number resource. This mechanism		an Internet number resource. This mechanism allows the users of such
	allows the users of such database objects to verify that the contents		database objects to verify that the contents are in fact produced by
	are in fact produced by the legitimate holder(s) of the Internet		the legitimate holder(s) of the Internet resources mentioned in those
	resources mentioned in those objects. It also allows the signatures		objects. It also allows the signatures to cover whole RPSL objects,
	to cover whole RPSL objects, or just selected attributes of them. In		or just selected attributes of them. In other words, a digital
	other words, a digital signature created using the private key		signature created using the private key associated with a resource
	associated with a resource certificate can offer object security in		certificate can offer object security in addition to the channel
	addition to the channel security already present in most of such		security already present in most of such databases. Object security
	databases. Object security in turn allows such objects to be hosted		in turn allows such objects to be hosted in different databases and
	in different databases and still be independently verifiable.		still be independently verifiable.
	The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",		The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
	"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and		"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	[RFC2119].		[RFC2119].
	2. Signature Syntax and Semantics		2. Signature Syntax and Semantics
	When signing an RPSL object, the input for the signature process is		When signing an RPSL object, the input for the signature process is
	transformed into a sequence of strings of (ASCII) data. The approach		transformed into a sequence of strings of (ASCII) data. The approach
	skipping to change at page 4, line 33 ¶		skipping to change at page 4, line 33 ¶
	2. Reference to the certificate corresponding to the private key		2. Reference to the certificate corresponding to the private key
	used to sign this object (field "c"). This is a URL of type		used to sign this object (field "c"). This is a URL of type
	"rsync" or "http(s)" that points to a specific resource		"rsync" or "http(s)" that points to a specific resource
	certificate in an RPKI repository. The value of this field MUST		certificate in an RPKI repository. The value of this field MUST
	be an "rsync://..." or an "http[s]://..." URL. Any non URL-safe		be an "rsync://..." or an "http[s]://..." URL. Any non URL-safe
	characters (including semicolon ";" and plus "+") must be URL		characters (including semicolon ";" and plus "+") must be URL
	encoded.		encoded.
	3. Signature method (field "m"): what hash and signature algorithms		3. Signature method (field "m"): what hash and signature algorithms
	were used to create the signature. The allowed algorithms which		were used to create the signature. The allowed algorithms which
	can be used for the signature are specified in		can be used for the signature are specified in [RFC6485].
	[I-D.ietf-sidr-rpki-algs].
	4. Time of signing (field "t"). The format of the value of this		4. Time of signing (field "t"). The format of the value of this
	field is the number of seconds since Unix EPOCH (00:00:00 on		field is the number of seconds since Unix EPOCH (00:00:00 on
	January 1, 1970 in the UTC time zone). The value is expressed as		January 1, 1970 in the UTC time zone). The value is expressed as
	the decimal representation of an unsigned integer.		the decimal representation of an unsigned integer.
	5. The signed attributes (field "a"). This is a list of attribute		5. The signed attributes (field "a"). This is a list of attribute
	names, separated by an ASCII "+" character (if more than one		names, separated by an ASCII "+" character (if more than one
	attribute is enumerated). The list must include any attribute at		attribute is enumerated). The list must include any attribute at
	most once.		most once.
	skipping to change at page 6, line 13 ¶		skipping to change at page 6, line 13 ¶
	attributes are referenced in the signature. If not, the verifier		attributes are referenced in the signature. If not, the verifier
	MUST reject the signature and threat the object as a regular, non-		MUST reject the signature and threat the object as a regular, non-
	signed RPSL object.		signed RPSL object.
	2.3. Storage of the Signature Data		2.3. Storage of the Signature Data
	The result of applying the signature mechanism once is exactly one		The result of applying the signature mechanism once is exactly one
	new attribute for the object. As an illustration, the structure of a		new attribute for the object. As an illustration, the structure of a
	signed RPSL object is as follows:		signed RPSL object is as follows:
	attribute1: value1		attribute1: value1
	attribute2: value2		attribute2: value2
	attribute3: value3		attribute3: value3
	...		...
	signature: v=1; c=rsync://.....; m=sha256WithRSAEncryption; t=9999999999;		signature: v=1; c=rsync://.....; m=sha256WithRSAEncryption;
	a=attribute1+attribute2+attribute3+...;		t=9999999999;
	b=<base64 data>		a=attribute1+attribute2+attribute3+...;
			b=<base64 data>
	2.4. Number Resource Coverage		2.4. Number Resource Coverage
	Even if the signature(s) over the object are valid according to the		Even if the signature(s) over the object are valid according to the
	signature validation rules, they may not be relevant to the object;		signature validation rules, they may not be relevant to the object;
	they also need to cover the relevant Internet number resources		they also need to cover the relevant Internet number resources
	mentioned in the object.		mentioned in the object.
	Therefore the Internet number resources present in the RFC3779		Therefore the Internet number resources present in [RFC3779]
	[RFC3779] extension of the certificate referred to in the "c" field		extensions of the certificate referred to in the "c" field of the
	of the signature (or in the union of such extensions in the "c"		signature (or in the union of such extensions in the "c" fields of
	fields of the certificates, in case multiple signatures are present)		the certificates, in case multiple signatures are present) MUST cover
	MUST cover the resources in the primary key of the object (e.g.,		the resources in the primary key of the object (e.g., value of the
	value of the "aut-num:" attribute of an aut-num object, value of the		"aut-num:" attribute of an aut-num object, value of the "inetnum:"
	"inetnum:" attribute of an inetnum object, values of "route:" and		attribute of an inetnum object, values of "route:" and "origin:"
	"origin:" attributes of a route object, etc.).		attributes of a route object, etc.).
	2.5. Validity Time of the Signature		2.5. Validity Time of the Signature
	The validity time interval of a signature is the intersection of the		The validity time interval of a signature is the intersection of the
	validity time of the certificate used to verify the signature, the		validity time of the certificate used to verify the signature, the
	"not before" time specified by the "t" field of the signature, and		"not before" time specified by the "t" field of the signature, and
	the optional "not after" time specified by the "x" field of the		the optional "not after" time specified by the "x" field of the
	signature.		signature.
	When checking multiple signatures, these checks are applied to each		When checking multiple signatures, these checks are applied to each
	skipping to change at page 8, line 7 ¶		skipping to change at page 8, line 7 ¶
	("\n").		("\n").
	4. Numerical fields must be converted to canonical representations.		4. Numerical fields must be converted to canonical representations.
	These include:		These include:
	* Date and time fields MUST be converted to 64-bit NTP Timestamp		* Date and time fields MUST be converted to 64-bit NTP Timestamp
	Format [RFC5905].		Format [RFC5905].
	* AS numbers MUST be converted to ASPLAIN syntax [RFC5396].		* AS numbers MUST be converted to ASPLAIN syntax [RFC5396].
	* IPv6 addresses must be canonicalized as defined in		* IPv6 addresses must be canonicalized as defined in [RFC5952].
	[I-D.ietf-6man-text-addr-representation].
	* IPv4 addresses MUST be converted to a 32-bit representation		* IPv4 addresses MUST be converted to a 32-bit representation
	(e.g., Unix's inet_aton()).		(e.g., Unix's inet_aton()).
	* All IP prefixes (IPv4 and IPv6) MUST be represented in CIDR		* All IP prefixes (IPv4 and IPv6) MUST be represented in CIDR
	notaion [RFC4632].		notaion [RFC4632].
	5. The name of each attribute MUST be converted into lower case, and		5. The name of each attribute MUST be converted into lower case, and
	MUST be kept as part of the attribute line.		MUST be kept as part of the attribute line.
	skipping to change at page 8, line 34 ¶		skipping to change at page 8, line 33 ¶
	8. All line endings MUST be converted to a singe new line ("\n")		8. All line endings MUST be converted to a singe new line ("\n")
	character (thus avoiding CR vs. CRLF differences).		character (thus avoiding CR vs. CRLF differences).
	3.2. Signature Creation		3.2. Signature Creation
	Given an RPSL object, in order to create the digital signature, the		Given an RPSL object, in order to create the digital signature, the
	following steps MUST be performed:		following steps MUST be performed:
	1. For each signature, a new key pair and certificate SHOULD be		1. For each signature, a new key pair and certificate SHOULD be
	used. Therefore the signer SHOULD create a single-use key pair		used. Therefore the signer SHOULD create a single-use key pair
	and end-entity resource certificate (see		and end-entity resource certificate (see [RFC6487]) to be used
	[I-D.ietf-sidr-res-certs]) to be used for signing this object		for signing this object this time.
	this time.
	2. Create a list of attribute names referring to the attributes that		2. Create a list of attribute names referring to the attributes that
	will be signed (contents of the "a" field). The minimum set of		will be signed (contents of the "a" field). The minimum set of
	these attributes is determined by the object type; the signer MAY		these attributes is determined by the object type; the signer MAY
	select additional attributes.		select additional attributes.
	3. Arrange the selected attributes according to the selection		3. Arrange the selected attributes according to the selection
	sequence specified in the "a" field as above, omiting all		sequence specified in the "a" field as above, omiting all
	attributes that will not be signed.		attributes that will not be signed.
	4. Construct the new "signature" attribute, with all its fields,		4. Construct the new "signature" attribute, with all its fields,
	leaving the value of the "b" field empty.		leaving the value of the "b" field empty.
	5. Apply canonicalization rules to theresult (including the		5. Apply canonicalization rules to the result (including the
	"signature" attribute).		"signature" attribute).
	6. Create the signature over the results of the canonicalization		6. Create the signature over the results of the canonicalization
	process (according to the signature and hash algorithms specified		process (according to the signature and hash algorithms specified
	in the "m" field of the signature attribute).		in the "m" field of the signature attribute).
	7. Insert the base64 encoded value of the signature as the value of		7. Insert the base64 encoded value of the signature as the value of
	the "b" field.		the "b" field.
	8. Append the resulting "signature" attribute to the original		8. Append the resulting "signature" attribute to the original
	skipping to change at page 9, line 27 ¶		skipping to change at page 9, line 27 ¶
	In order to validate a signature over such an object, the following		In order to validate a signature over such an object, the following
	steps MUST be performed:		steps MUST be performed:
	1. Verify the syntax of the "signature" attribute (ie. whether it		1. Verify the syntax of the "signature" attribute (ie. whether it
	contains the mandatory and optional components and the syntax of		contains the mandatory and optional components and the syntax of
	these fields mathces the specification as described in section		these fields mathces the specification as described in section
	2.1.)		2.1.)
	2. Fetch the certificate referred to in the "c" field of the		2. Fetch the certificate referred to in the "c" field of the
	"signature" attribute, and check its validity using the steps		"signature" attribute, and check its validity using the steps
	described in [I-D.ietf-sidr-res-certs].		described in [RFC6487].
	3. Extract the list of attributes that were signed using the signer		3. Extract the list of attributes that were signed using the signer
	from the "a" field of the "signature" attribute.		from the "a" field of the "signature" attribute.
	4. Verify that the list of signed attributes matches the miminum set		4. Verify that the list of signed attributes matches the miminum set
	of attributes for that object type.		of attributes for that object type.
	5. Arrange the selected attributes according to the selection		5. Arrange the selected attributes according to the selection
	sequence provided in the value of the "a" field, omitting all		sequence provided in the value of the "a" field, omitting all
	non-signed attributes.		non-signed attributes.
	skipping to change at page 11, line 36 ¶		skipping to change at page 11, line 36 ¶
	o For the route[6] object type: the resource in the "route[6]" or		o For the route[6] object type: the resource in the "route[6]" or
	"origin" (or both) attributes.		"origin" (or both) attributes.
	5. Keys and Certificates used for Signature and Verification		5. Keys and Certificates used for Signature and Verification
	The certificate that is referred to in the signature (in the "c"		The certificate that is referred to in the signature (in the "c"
	field):		field):
	o MUST be an end-entity (ie. non-CA) certificate		o MUST be an end-entity (ie. non-CA) certificate
	o MUST conform to the X.509 PKIX Resource Certificate profile		o MUST conform to the X.509 PKIX Resource Certificate profile
	[I-D.ietf-sidr-res-certs]		[RFC6487]
	o MUST have an RFC3779 [RFC3779] extension that contains or covers		o MUST have an [RFC3779] extension that contains or covers at least
	at least one Internet number resource included in a signed		one Internet number resource included in a signed attribute.
	attribute.
	o SHOULD NOT be used to verify more than one signed object (ie.		o SHOULD NOT be used to verify more than one signed object (ie.
	should be a "single-use" EE certificate, as defined in		should be a "single-use" EE certificate, as defined in [RFC6487]).
	[I-D.ietf-sidr-res-certs]).
	6. Security Considerations		6. Security Considerations
	[To be Completed.]		RPSL objects stored in the IRR databases are public, and as such
			there is no need for confidentiality. Each signed RPSL object can
			have its integrity and authenticity verified using the supplied
			digital signature and the referenced certificate.
			Since the RPSL signature approach leverages X.509 extensions, the
			security considerations in [RFC3779] apply here as well.
	7. IANA Considerations		7. IANA Considerations
	[Note to IANA, to be removed prior to publication: there are no IANA		[Note to IANA, to be removed prior to publication: there are no IANA
	considerations stated in this version of the document.]		considerations stated in this version of the document.]
	8. Acknowledgements		8. Acknowledgements
	The authors would like to acknowledge the valued contributions from		The authors would like to acknowledge the valued contributions from
	Jos Boumans and Steve Kent in preparation of this document.		Jos Boumans and Steve Kent in preparation of this document.
	9. Normative References		9. Normative References
	[I-D.ietf-6man-text-addr-representation]
	Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
	Address Text Representation",
	draft-ietf-6man-text-addr-representation-07 (work in
	progress), February 2010.
	[I-D.ietf-sidr-res-certs]
	Huston, G., Michaelson, G., and R. Loomans, "A Profile for
	X.509 PKIX Resource Certificates",
	draft-ietf-sidr-res-certs-18 (work in progress), May 2010.
	[I-D.ietf-sidr-rpki-algs]
	Huston, G., "A Profile for Algorithms and Key Sizes for
	use in the Resource Public Key Infrastructure",
	draft-ietf-sidr-rpki-algs-01 (work in progress), May 2010.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP		[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
	Addresses and AS Identifiers", RFC 3779, June 2004.		Addresses and AS Identifiers", RFC 3779, June 2004.
	[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing		[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
	(CIDR): The Internet Address Assignment and Aggregation		(CIDR): The Internet Address Assignment and Aggregation
	Plan", BCP 122, RFC 4632, August 2006.		Plan", BCP 122, RFC 4632, August 2006.
			[RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
			J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
			Signatures", RFC 4871, May 2007.
	[RFC5396] Huston, G. and G. Michaelson, "Textual Representation of		[RFC5396] Huston, G. and G. Michaelson, "Textual Representation of
	Autonomous System (AS) Numbers", RFC 5396, December 2008.		Autonomous System (AS) Numbers", RFC 5396, December 2008.
	[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network		[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
	Time Protocol Version 4: Protocol and Algorithms		Time Protocol Version 4: Protocol and Algorithms
	Specification", RFC 5905, June 2010.		Specification", RFC 5905, June 2010.
			[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
			Address Text Representation", RFC 5952, August 2010.
			[RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for
			Use in the Resource Public Key Infrastructure (RPKI)",
			RFC 6485, February 2012.
			[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
			X.509 PKIX Resource Certificates", RFC 6487,
			February 2012.
	Authors' Addresses		Authors' Addresses
	Robert Kisteleki		Robert Kisteleki
	Email: robert@ripe.net		Email: robert@ripe.net
	URI: http://www.ripe.net		URI: http://www.ripe.net
	Brian Haberman		Brian Haberman
	Johns Hopkins University Applied Physics Lab		Johns Hopkins University Applied Physics Lab
End of changes. 18 change blocks.
	67 lines changed or deleted		68 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/