Subject: PublicKeyFile Format Security Considerations

From: "Brent McClure" <[email-masked]>
Date: Fri, 25 Jul 2003 09:13:24 -0600

I'm wondering if the following is a sufficient statement for
the security considerations of the "SSH Public Key File Format"
document:
<http://www.ietf.org/internet-drafts/draft-ietf-secsh-publickeyfile-03.txt>

-----
Security Considerations

  There are no known security issues raised by this document.

-----

I mulled over a couple possibilities such as cautions about
parsing illegal UTF-8, but wasn't sure how that might constitute
a security issue.

Any other ideas?

thanks, Brent

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 25 Jul 2003 11:31:18 -0400

>   There are no known security issues raised by this document.

Sorry, this is a good way to get laughed at by the IESG these days.

This is an out of band exchange format for public keys, so it's
going to be shovelled around between systems. 

The big one which jumps out at me is:

 - by design, the file format does not provide meaningful integrity
protection or authentication of the contents (i.e., this is not a
certificate) so you have to be careful with how you move the file
around and how you store it..

					- Bill

---

From: "Brent McClure" <[email-masked]>
Date: Fri, 25 Jul 2003 17:22:06 -0600

----- Original Message -----
From: "Bill Sommerfeld" <[email-masked]>
> around and how you store it..

Bill, Thanks for the help. 

Here's another crack at it.

--Brent

----
Security Considerations

  The file format described by this document provides no mechanism
  to verify the integrity or otherwise detect tampering of the
  data stored in such files. It is the responsibility of the parties
  that create or exchange files written in this format to ensure that 
  appropriate access controls are applied to such files, and that 
  the files, if transfered, are exchanged over a trusted channel.

  The data encoded using this file format is sensitive. Implementors
  are cautioned to verify the correctness of the encoding/decoding
  routines used to save and read files in this format. A malfunctioning
  decoder used to read a public-key file will most likely produce 
  unsound data of unknown cryptographic properties that in the worst
  case could be vulnerable various forms of cryptographic attack.

  This file format allows for headers that contain data associated with
  a public key. This header data could contain an unlimited range of
  information. While in many environments the information conveyed by a 
  "Subject:" header would be considered innocuous public information, the
  potential exposure of information through header data should be 
  reviewed by sites that deploy this file format.

----

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 25 Jul 2003 19:25:44 -0400

>   The data encoded using this file format is sensitive. 

"sensitive" in what sense?  

>   Implementors are cautioned to verify the correctness of the
>   encoding/decoding routines used to save and read files in this
>   format. A malfunctioning decoder used to read a public-key file
>   will most likely produce unsound data of unknown cryptographic
>   properties that in the worst case could be vulnerable various
>   forms of cryptographic attack.

					- Bill

---

From: "Brent McClure" <[email-masked]>
Date: Fri, 25 Jul 2003 17:45:47 -0600

----- Original Message ----- 
From: "Bill Sommerfeld" <[email-masked]>
To: "Brent McClure" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, July 25, 2003 5:25 PM
Subject: Re: PublicKeyFile Format Security Considerations 

> "sensitive" in what sense?  

In the sense that it's important for authentication. Ie, if the data 
causes the wrong thing to happen it could be bad thing. Saying "sensitive"
seemed vague when I wrote it. 

How about:

  The data encoded using this file format is critical for authentication
  to work correctly.

Or, I'm open to suggestions.

--Brent

---

From: RJ Atkinson <[email-masked]>
Date: Sat, 26 Jul 2003 10:44:43 -0400

On Friday, Jul 25, 2003, at 19:25 America/Montreal, Bill Sommerfeld 
>>   forms of cryptographic attack.

Suggested text fragment:

	"Given the potential of an adversary tampering with data stored
	in such files on filesystems, system-specific measures (e.g.
	Access Control Lists, UNIX permissions, other Discretionary
	and/or Mandatory Access Controls) SHOULD be used to protect
	these files."

(edit to taste)

Ran

---

From: "Brent McClure" <[email-masked]>
Date: Wed, 30 Jul 2003 10:33:20 -0600

Revised the Public-key file format Security Considerations
based on comments:

- Removed use of vague term "sensitive".
- Added in text suggestion from Ran.

Is the blurb about information disclosure by "Comment" headers
too strong, unnecessary or OK?

thanks, Brent

----
Security Considerations

  The file format described by this document provides no mechanism
  to verify the integrity or otherwise detect tampering with the
  data stored in such files. Given the potential of an adversarial
  tampering with this data, system-specific measures (e.g. Access Control Lists, 
  UNIX permissions, other Discretionary and/or Mandatory Access Controls) 
  SHOULD be used to protect these files. Also, if the contents of these 
  files are transferred it SHOULD be done over a trusted channel.

  Implementors are cautioned to verify the correctness of the encoding/decoding
  routines used to save and read files in this format. A malfunctioning
  decoder used to read public-key data will most likely produce 
  invalid data with unknown cryptographic properties. In the worst
  case this cata could be vulnerable various forms of cryptographic attack.

  The header data allowed by this file format could contain an unlimited range of
  information. While in many environments the information conveyed by this
  header data may be considered innocuous public information, it may constitute
  a channel through which information about a user, a key or its use may be
  disclosed intentionally or otherwise (e.g "Comment: Mary E. Jones, 123 Main St, 
  Home Phone:..."). The presence and use of this header data SHOULD be 
  reviewed by sites that deploy this file format.

--Brent

---

From: "Joel N. Weber II" <[email-masked]>
Date: Wed, 30 Jul 2003 12:56:20 -0400

> case this cata could be vulnerable various forms of cryptographic attack.

I'm not sure that a cryptographic attack is the worst case.  Are we
sure that a malfunctioning decoder can't possibly be vulnerable to a
buffer overflow?

---

From: "Brent McClure" <[email-masked]>
Date: Wed, 30 Jul 2003 15:13:57 -0600

From: "Joel N. Weber II" <[email-masked]>
> sure that a malfunctioning decoder can't possibly be vulnerable to a

That's true. So, should I just change the use of the wording "worst case" 
to something like this?:

  "... A malfunctioning decoder used to read public-key data will most 
  likely produce invalid data with unknown cryptographic properties which
  may leave this data vulnerable various forms of cryptographic attack."

On the other hand, your suggestion of a buffer overflow makes me wonder
if this caution about properly implementing the parsing/decoding of
public-key data is too much a statement of the obvious. Ie. if there
isn't a specific concern about the decoding of public keys here that
warrants mentioning, then maybe I should just strike it. After all
if what I wrote above is just another way of saying "Implementors should
avoid bugs, and especially buffer overruns in their code" then maybe
it doesn't add anything of value.

--Brent

---

From: "Joel N. Weber II" <[email-masked]>
Date: Wed, 30 Jul 2003 17:37:39 -0400

> After all

It does seem to be the case that the text we're discussing covers a
subject that is assumed to be obvious in just about every other IETF
document.  If we want to say ``don't write buffer overflows, and
verify your data, and stuff'' in a very general way, it might be
appropriate to write up a protocol-independent RFC saying those
things, and have the security considerations section of every RFC
refer to that generic, protocol-independent writeup.  This discussion
makes me wonder if it is a bug that there is no RFC talking about
buffer overflows, as far as I know.  There *is* an RFC about random
numbers, for example.  But I'm sure an RFC about buffer overflows is
beyond the scope of this working group.

If there is a specific reason why being careful about parsing the data
is more important, or more difficult, or more subtle with an ssh
public key file than in a generic case of parsing data, then
explaining that would be useful.

---

From: "Brent McClure" <[email-masked]>
Date: Thu, 31 Jul 2003 10:55:22 -0600

----- Original Message ----- 
....
> explaining that would be useful.

I can't make a case that this parsing of the encoded key data presents
a specific condition that warrants it being mentioned. So, unless 
someone else can then I'll drop it from the security considerations.

So, here's the text as I currently have it, does this work?

----
Security Considerations

thanks, Brent

---

From: "Joel N. Weber II" <[email-masked]>
Date: Thu, 31 Jul 2003 13:26:56 -0400

> So, here's the text as I currently have it, does this work?

It mostly looks fine to me.

> data stored in such files. Given the potential of an adversarial

I believe that should be ``adversary''.

> tampering with this data, system-specific measures (e.g. Access Control Lists, 

[...]

> reviewed by sites that deploy this file format.

RFC 2119 says:

| 3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
|    may exist valid reasons in particular circumstances to ignore a
|    particular item, but the full implications must be understood and
|    carefully weighed before choosing a different course.

So to take this excessively literally, it sounds like sites that
aren't going to review the presence and use of this header data must
understand and carefully weigh the full implications of skipping this
review before choosing to not do this review.

It may be that you should just write the word ``should'' without the
capital letters.

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 31 Jul 2003 13:39:08 -0400

On Thursday, Jul 31, 2003, at 13:26 America/Montreal, Joel N. Weber II 
wrote:
> So to take this excessively literally, ...

Lets not be silly, please. :-)

> It may be that you should just write the word ``should'' without the

SHOULD with capitals is helpful in this case, IMHO, because it
adds emphasis.

Ran