hi, Marcelo,
We (Tony, Micheala, Mariline and me) are writing two drafts for the agility
work: one is the agility support for CGA, the other is the agility support
for SeND. Basically the CGA agility will simply let an CGA associated with
multiple public keys, in the extension part of Public Key field in the CGA
PDS. SeND Agility will deal with how to get agreement on an algorithm which
both nodes can use in SeND. We separate the job of two protocols to clarify
roles of CGA and SeND in agility, such that CGA will provide enough support
when it is used in protocols other than SeND
We just had a discussion last night and made more improvement. Tony is
sorting out our discussions and will soon send our detailed answer soon.
Best,
Sean
>-----Original Message-----
>From: [email protected]
>[mailto:[email protected]] On Behalf Of marcelo bagnulo braun
>Sent: Monday, December 15, 2008 2:41 AM
>To: [email protected]
>Subject: [CGA-EXT] Public Key algorithm agility in CGAs
>
>Hi,
>
>there have been some discussion about how to support multiple
>public key algorithms in CGAs.
>I include some thoughts below to continue the discussion
>
>RFC3972 states that only RSA are supported and there is a
>mandatory Public Key filed in the CGA PDS that contains:
>
> The public key MUST be formatted as a DER-encoded
> [ITU.X690.2002] ASN.1 structure of the type SubjectPublicKeyInfo,
> defined in the Internet X.509 certificate profile
>[RFC3280]. SEND
> SHOULD use an RSA public/private key pair. When RSA is used, the
> algorithm identifier MUST be rsaEncryption, which is
> 1.2.840.113549.1.1.1, and the RSA public key MUST be formatted by
> using the RSAPublicKey type as specified in Section 2.3.1 of RFC
> 3279 [RFC3279]. The RSA key length SHOULD be at least 384 bits.
> Other public key types are undesirable in SEND, as they
>may result
> in incompatibilities between implementations. The length of this
> field is determined by the ASN.1 encoding.
>
>So we have two options to support alternative public key
>algorithms in CGAs:
>- one option is to allow to include a public key of another
>algortihm in the Public Key field. In order to do that, we
>must provide a way to tell which algorithm is used.
>According to RFC3280,
> SubjectPublicKeyInfo ::= SEQUENCE {
> algorithm AlgorithmIdentifier,
> subjectPublicKey BIT STRING }
>and
>
> AlgorithmIdentifier ::= SEQUENCE {
> algorithm OBJECT IDENTIFIER,
> parameters ANY DEFINED BY algorithm OPTIONAL }
>
>I understand that RFC3279 defines the different algorithm
>identifiers for RSA.
>So, this option would be to simply allow to use other
>algorithms and see if the Algorithm identifiers for these
>algorithms have been properly defined.
>While it seems that current RFC3972 allows this already, we
>may want to update it to make it more explicitly.
>In addition, we want to make sure that the ECC support is
>properly defined.
>
>The main issue here is that we need a mechanism to deal with
>the case that different nodes support different algorithms.
>Note that today, CGAs are used by SEND, MIPv6 and SHIM6 and
>they all assume that the key is RSA I understand that in the
>case that a different AlgorithmIdentifier is included in the
>Public Key field of the CGA PDS, the receiving peer will fail
>the verification. Since the key is bound to the address, the
>sender will need to retry, but using a different public key,
>hence using a different address. It seems that what may be
>needed then is an error message in these protocols. The
>potential problem of such error message is that it could open
>the door for downgrading attacks.
>In any case, it seems clear that if we go this path, we should
>reccomend that the usage of alternative aplgorithms would
>break the aforementioned protocols assumptions and needs to be
>deployed and used in a controlled manner, to avoid failure modes.
>
>The other option is to define a new CGA extension that could
>carry an additional public key (of eventually a different
>algorithm) In this case, a node could have multipla public
>keys of different algorithms, associated to the same CGA. this
>would have no backward compatibility problems, since the
>"main" public key would be RSA and the additional ones could
>be of other algortihms.
>The problem here, is that in order to do this, we impose that
>all nodes must have a RSA public key and one of the
>motivations for this was that some lighweight nodes couldn't
>use RSA. However, this approach seems particularly attractive
>imho for routers and servers, that need to communicate both
>with normal SEND nodes and lighweight nodes. In this case,they
>can choose to use RSA for backward comaptibility and also to
>use ECC when talking to lighwieght nodes.
>One intermediate approach could be to require to all nodes to
>always be capable of verifying RSA signatures, but not
>requiring to have a RSA key itself. This would allow to always
>be able to fall back to RSA when at least one of the nodes has
>an rsa key to have a secure channel .
>
>I think we probably need to do both, but i am not certian yet.
>
>comments?
>
>Regards, marcelo
>
>_______________________________________________
>CGA-EXT mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/cga-ext
>
_______________________________________________
CGA-EXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cga-ext
