marcelo bagnulo braun | 14 Dec 18:01 2008
Picon

WGLC for Proxy SeND problem statement

Hi,

As we agreed in the last CSI meeting, we are issuing the WGLC for 
draft-ietf-csi-sndp-prob-00.txt

Please review the document and send comments before Dec 30 2008.

for you convenience, the document can be found at:

http://tools.ietf.org/id/draft-ietf-csi-sndp-prob-00.txt

Regards, marcelo

marcelo bagnulo braun | 14 Dec 18:25 2008
Picon

IETF73 CSI meeting minutes

Hi,

the draft minutes are available at:

http://www.ietf.org/proceedings/08nov/minutes/csi.txt

Thanks TJ for taking them

Send me any comments or corrections that you think are needed.

Regards, marcelo

marcelo bagnulo braun | 14 Dec 19:41 2008
Picon

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
(Continue reading)

Sean Shen | 15 Dec 04:40 2008

Re: Public Key algorithm agility in CGAs

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: cga-ext-bounces@... 
>[mailto:cga-ext-bounces@...] On Behalf Of marcelo bagnulo braun
>Sent: Monday, December 15, 2008 2:41 AM
>To: cga-ext@...
>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:
(Continue reading)

Tony Cheneau | 15 Dec 15:01 2008
Picon

Re: Public Key algorithm agility in CGAs

Hello Marcelo,

As Sean stated, we (Michaela, Sean, Maryline and I) are currently working on
some solutions for the problems you exposed. Unfortunately, we didn't finish
writing the drafts yet. The comments during the last WG meeting provided us
some really good insight. We hope this discussion will make clearer what is
possible and what is not.

I will try to explain how we envision to solve theses problems. Comments
inline.

On Sun, 14 Dec 2008, marcelo bagnulo braun wrote:

> Hi,
>
> there have been some discussion about how to support multiple public key 
> algorithms in CGAs.
We think multiple keys can be a good transition mechanism in network
that are (or will be) deployed with 3971 version of SEND. I explain why
this is good and how we can make it backward compatible with the actual
SEND specification.

> 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
(Continue reading)

marcelo bagnulo braun | 15 Dec 15:05 2008
Picon

Crypto agility - interop

Hi,

We are chartered to provide crypto agility support for SeND and CGAs. 
That include both public key algorithm and hash algorithm agility.
So far, only CGAs have hash algorithm agility defined and we have some 
drafts covering the remaining pieces.
Now, i guess it makes sense to look at the big picture of how to provide 
agility for all these and draw some big lines about how this should be 
supported.

So, first we have identified the main elements that use the algortihms 
and they are:
- the certificates contain both a public key and use a hash
- the SEND protocol itself sends the RSA signature option and use hash 
algorithm.
- the CGA includes a public key and uses a hash algorithm

Next, we should agree of what level of backward compatibility we aim for.
First, it should be noted that SEND has two different behaviours. Some 
messages are in the request response format and another ones are just a 
message (like the periodic RADV).
Second, it should be noted that the public key and the hash algorithm 
are tightly coupled to the CGA and also to the certificates.

So, types of nodes and elements can we have in a scenario with crypto 
agility?

for hosts
H1- we can have a host that only supports crypto suite 1 and has no 
capabilities of doing any operations of algorithms that are not part of 
(Continue reading)

marcelo bagnulo braun | 15 Dec 15:40 2008
Picon

Re: Public Key algorithm agility in CGAs

Hi tony,

thanks for the answer

your points seem reasonable to me and i am expecting to draft to comment 
further.

please check the other mail i sent about interop, you may want to cover 
these as well in your draft.

some replies in line...

Tony Cheneau escribió:
> Hello Marcelo,
>
> As Sean stated, we (Michaela, Sean, Maryline and I) are currently 
> working on
> some solutions for the problems you exposed. Unfortunately, we didn't 
> finish
> writing the drafts yet. The comments during the last WG meeting 
> provided us
> some really good insight. We hope this discussion will make clearer 
> what is
> possible and what is not.
>
> I will try to explain how we envision to solve theses problems. Comments
> inline.
>
>
> On Sun, 14 Dec 2008, marcelo bagnulo braun wrote:
(Continue reading)

Tony Cheneau | 15 Dec 17:38 2008
Picon

Re: Crypto agility - interop

Hi,

Comments inline.

On Mon, 15 Dec 2008, marcelo bagnulo braun wrote:

[...]

> So, first we have identified the main elements that use the algortihms and 
> they are:
> - the certificates contain both a public key and use a hash
> - the SEND protocol itself sends the RSA signature option and use hash 
> algorithm.
> - the CGA includes a public key and uses a hash algorithm
>
> Next, we should agree of what level of backward compatibility we aim for.
> First, it should be noted that SEND has two different behaviours. Some 
> messages are in the request response format and another ones are just a 
> message (like the periodic RADV).
> Second, it should be noted that the public key and the hash algorithm are 
> tightly coupled to the CGA and also to the certificates.
>
> So, types of nodes and elements can we have in a scenario with crypto 
> agility?
>
> for hosts
> H1- we can have a host that only supports crypto suite 1 and has no 
> capabilities of doing any operations of algorithms that are not part of this 
> crypto suite (e.g. the node supports only RSA and SHA1 and it is not capable 
> of verifying ECC nor MD5 nor any other algorithm). this node has generated 
(Continue reading)

marcelo bagnulo braun | 15 Dec 18:31 2008
Picon

Re: Crypto agility - interop

Tony Cheneau escribió:
> Hi,
>
> Comments inline.
>
> On Mon, 15 Dec 2008, marcelo bagnulo braun wrote:
>
> [...]
>
>> So, first we have identified the main elements that use the 
>> algortihms and they are:
>> - the certificates contain both a public key and use a hash
>> - the SEND protocol itself sends the RSA signature option and use 
>> hash algorithm.
>> - the CGA includes a public key and uses a hash algorithm
>>
>> Next, we should agree of what level of backward compatibility we aim 
>> for.
>> First, it should be noted that SEND has two different behaviours. 
>> Some messages are in the request response format and another ones are 
>> just a message (like the periodic RADV).
>> Second, it should be noted that the public key and the hash algorithm 
>> are tightly coupled to the CGA and also to the certificates.
>>
>> So, types of nodes and elements can we have in a scenario with crypto 
>> agility?
>>
>> for hosts
>> H1- we can have a host that only supports crypto suite 1 and has no 
>> capabilities of doing any operations of algorithms that are not part 
(Continue reading)

Tony Cheneau | 15 Dec 21:14 2008
Picon

Re: Crypto agility - interop

Hi again,

Comments inline.

On Mon, 15 Dec 2008, marcelo bagnulo braun wrote:

[...]

>> >  for hosts
>> >  H1- we can have a host that only supports crypto suite 1 and has no 
>> >  capabilities of doing any operations of algorithms that are not part of 
>> >  this crypto suite (e.g. the node supports only RSA and SHA1 and it is 
>> >  not capable of verifying ECC nor MD5 nor any other algorithm). this node 
>> >  has generated its own CGA with this suite of algorithms.
>> >  H2- we can have a host that supports multiple crypto algorithm suite but 
>> >  has only one CGA, generated with one of the crypto suites. So, in this 
>> >  case, the node has generated its CGA with crypto suite1, but he can also 
>> >  verify CGAs, and certs and signatures using other crypto suites.
>> >  H3- we then can have a host that supports multiple crypto suites and 
>> >  that he has generated as many different CGAs as crypto suites it 
>> >  supports.
>> >  H4- we can also have a node that supports multiple crypto suites and 
>> >  that he has generated one CGA that includes multiple public keys, one 
>> >  per public key algorithm it supports but using a single hash function 
>> >  though.
>> > 
>> >  for routers
>> >  R1- a router with a single certificate generated with a given crypto 
>> >  suite. The router supports only the crypto suite that was used for 
>> >  generating the cert and it cannot perform crypto operations for other 
(Continue reading)


Gmane