headers
Jan Pechanec | 11 Nov 2008 16:59
Picon

Re: Elliptic-Curve Algorithm Integration in the Secure Shell Transport Layer

On Wed, 1 Oct 2008, Douglas Stebila wrote:

> A new version of the ECC in SSH draft is now available for review.
>
> http://www.ietf.org/internet-drafts/draft-green-secsh-ecc-03.txt

	hi Douglas,

	I like the draft, and have some comments.

	- section 1, ECMQV has been dropped from the National Security
Agency's Suite B. I don't know when but it's not there now:

	http://www.nsa.gov/ia/industry/crypto_suite_b.cfm

	I'm wondering if an inclusion of that in this draft may not cast 
some shadow on it in general as including something that might have 
potential legal issues if used.

	- section 4, this might be just a language issue; does this imply 
that the remote key pair is ephemeral as well or not? Or would it be better 
to say "and ephemeral remote public key"?

   The Elliptic Curve Diffie-Hellman (ECDH) key exchange method
   generates a shared secret from an ephemeral elliptic curve local
   private key and remote public key.

	- section 4, you may want to reference RFC 4251, 4.1 (Host Keys) and
section 9.3.4 (Man-in-the-middle) in the "*" paragraph. Same in section 5.
Or it could be at one common place so that it's not duplicated.
(Continue reading)

Permalink | Reply | 503 comments |
headers
der Mouse | 11 Nov 2008 18:24

Re: Elliptic-Curve Algorithm Integration in the Secure Shell Transport Layer

> 	- section 4, this might be just a language issue; does this imply 
> that the remote key pair is ephemeral as well or not? Or would it be better 
> to say "and ephemeral remote public key"?
> 
>    The Elliptic Curve Diffie-Hellman (ECDH) key exchange method
>    generates a shared secret from an ephemeral elliptic curve local
>    private key and remote public key.

Maybe "...from ephemeral elliptic curve local private and remote public
keys"?

> 	wrt the SSH protocol I think it should work as defined but obviously 
> a reference implementation might reveal more.

I think reference implementations are a bad idea; I much prefer sample
implementations.  (The difference is that a reference implementation by
definition _is_ the spec in an operational form, and if it disagrees
with some other spec, there's no a priori way to tell which is wrong.
If a sample implementation disagrees with the spec, there's no question
- the sample implementation is wrong.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse <at> rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
Permalink | Reply | 0 comments |
headers
Douglas Stebila | 16 Nov 2008 02:55
Picon
Gravatar

Re: Elliptic-Curve Algorithm Integration in the Secure Shell Transport Layer

Thanks for the comments, Jan.  I've implemented all of the changes you  
suggested and am responding to your other questions below.  A new  
draft will appear next week when the Internet Draft submission tool is  
back online.

> 	- section 1, ECMQV has been dropped from the National Security
> Agency's Suite B. I don't know when but it's not there now:
>
> 	http://www.nsa.gov/ia/industry/crypto_suite_b.cfm
>
> 	I'm wondering if an inclusion of that in this draft may not cast
> some shadow on it in general as including something that might have
> potential legal issues if used.

While it's no longer part of NIST Suite B, it is a useful protocol  
that I am to understand a number of organizations wish to use.  I have  
added language clarifying that the ECMQV portion is optional.

> 	- section 5. I don't know very much about ECC so I have a question.
> I understand that we can use implicit server authentication since  
> server's
> private key is already involved in the generation of the shared  
> secret. So,
> HMAC instead of the ECDSA is then used just because it's faster?

That's right.

> 	- is it needed to include shared secret in the hash input when we
> already use it in HMAC on the resulting hash? I'd say to break it is  
> equally
(Continue reading)

Permalink | Reply | 0 comments |
headers
Douglas Stebila | 17 Nov 2008 17:29
Picon
Gravatar

Fwd: New Version Notification for draft-green-secsh-ecc-04

Begin forwarded message:

> From: IETF I-D Submission Tool <idsubmission <at> ietf.org>
> Date: November 17, 2008 11:29:07 AM GMT-05:00
> To: douglas <at> stebila.ca
> Subject: New Version Notification for draft-green-secsh-ecc-04
>
>
> A new version of I-D, draft-green-secsh-ecc-04.txt has been  
> successfuly submitted by Douglas Stebila and posted to the IETF  
> repository.
>
> Filename:	 draft-green-secsh-ecc
> Revision:	 04
> Title:		 Elliptic-Curve Algorithm Integration in the Secure Shell  
> Transport Layer
> Creation_date:	 2008-11-15
> WG ID:		 Independent Submission
> Number_of_pages: 25
>
> Abstract:
> This document describes algorithms based on Elliptic Curve
> Cryptography (ECC) for use within the Secure Shell (SSH) transport
> protocol.  In particular, it specifies: Elliptic Curve Diffie-Hellman
> (ECDH) key agreement, Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key
> agreement and Elliptic Curve Digital Signature Algorithm (ECDSA) for
> use in the SSH Transport Layer protocol.
>
>
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tero Kivinen | 17 Nov 2008 17:39
Picon
Picon
Favicon

Review of draft-igoe-secsh-aes-gcm-00.txt

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

The document describes how to use combined mode aes-gcm ciphers in the
secure shell. I think this document have several problems:

1) The draft does not define how the per encryption IV is defined. I
   assume it is some kind of counter with most likely initial value
   and fixed part taken from the appropriate IV generated by the secsh
   key derivation part, but also things like byte order of the counter
   etc needs to be defined. RFC 5116 provides just generic
   instructions for the nonce generation (generation of distinct
   nonces for each operation for given key) in section 3.1 and then
   provides recommended format for the nonce in section 3.2, and then
   there is another format for the nonce in section 3.2.1, but nothing
   in this document says which format is used.

2) This is first combined mode cipher for the secsh, so it should also
   provide information required to support combined mode ciphers in
   secsh. For example it should say that combined mode encryption is
   run only once and what key it is using (most likely the encryption
   key from section 7.2 from RFC 4253 etc). It also needs to say that
   mac generation DOES NOT follow section 6.4 of RFC 4253 (i.e. no
   MAC(key, sequence_number || unencrypted_packet)).

3) I am not sure if there is need adding sequence_number to the
   authenticated data of the combined mode. That sequence_number is
(Continue reading)

Permalink | Reply | 0 comments |
headers
eaeeie09 | 27 Nov 2008 11:00
Picon

call for papers EAEEIE09 Conference

(We apologize for multiples copies) (Please distribute)

Dear colleagues:

The 20th EAEEIE Annual Conference will take place in Valencia (22-24 June 2009), organized by the
Technical University of Valencia.

The objective of the Conference is to bring together lecturers, researchers and professionals in the
field of Electrical and Information Engineering (EIE) all over Europe with the aim to exchange ideas and
information and contribute to the development of EIE education. We cordially invite you to participate
and submit your contribution to EAEEIE 2009, which includes (but is not limited to), the following topics:

· Innovation in pedagogical way of teaching

· Application of ICTs in Education

· European Curricula in Electrical and Information Engineering

· International Partnerships in Teaching

· Cooperation with Industry in Teaching

· Gender Issues, Women in Engineering

· The Student Perspective of Electrical and Information Engineering

· Virtual Learning Environments in Electrical and Information Engineering

· Lifelong Learning in Electrical and Information Engineering
(Continue reading)

Permalink | Reply | 0 comments |

Gmane