Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-netboot-07

From: "Zimmer, Vincent" <[email-masked]>
Date: Wed, 6 Jan 2010 13:51:36 -0800

Yes.   There are a plurality of security considerations possibly.   Given the state of DHCP security and our attempt to have some behavior parity with IPV4 netboot, we were not intending exhaustive treatment of this subject area.

You are correct Thomas that HTTP-S was added based upon the suggestion of a Lucent engineer during IETF74 dhc session in SF as a possibility.   

>From the UEFI perspective, we prefer the following approach as described in the draft:

   or that the boot loader
   implementation implement a mechanism for signing boot images and a
   configurable signing key in memory, so that if a malicious image is
   provided, it can be detected and rejected.

to address issues of a DHCP hijacking or other MITM attacks.

Vincent

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Huth
Sent: Sunday, December 27, 2009 3:14 AM
To: Alfred Hönes; [email-masked]
Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-netboot-07

Hello Alfred!

Sorry for the late reply, but I got a lot of holiday stress
recently ... ;-)

Alfred Hönes <[email-masked]> wrote on 22/12/2009 14:47:56:

> (1) Major issue:
>   Confusion about URIs, IRIs, and URLs, and appropriate charsets.
>
> The draft is inconsistent in the use of "URL" vs. "URI".
> If it really wants to use URIs, it should use the more modern
> term, and not "URL".

Actually we really mean URL, not URI, since IMHO it does not make too much
sense to boot from a URN.

> Per STD 66 (RFC 3986) URIs per definition are tied to the US-ASCII
> charset.  You specify UTF-8 for the "boot-file-url" field.

That's also what I've originally thought and we had this in an older
version of our draft, but Ted Lemon told us to use UTF-8 instead:

http://www.ietf.org/mail-archive/web/dhcwg/current/msg10165.html

Ted, any comments on this?

> That does not make sense.  Even if you have an IRI (represented in
> UTF-8), it would have to be converted to US-ASCII, according to
> RFC 3987, before it can be handed out as a URI (or "URL").
> If you really want to use IRIs instead (PS so far, subject to
> revision), you can stay with UTF-8, but **please** refrain from
> calling them "URL", and rename all fields and code point identifiers
> to clearly say so.

I think we should not use IRIs here. I guess most firmware implementations
do not have a full blown i18n implementation and if I've got RFC3987 right,
HTTP also does not work well with IRIs:

"On the other hand, in the HTTP protocol [RFC2616], the Request URI is
defined
 as a URI, which means that direct use of IRIs is not allowed in HTTP
requests."

So I think we should stay with URLs in our draft.,

> (2)  Issue: Unrealistic text in Security Considerations
>
> Section 7, in its last paragraph, contains an allusion to HTTPs usage.
> Is that, realistically, an option in a Boot ROM environment???
> Serious use of HTTPS includes certificate and certificate path
> validation, online CRL lookup, or OCSP or SCVP usage, etc.
> Where should the necessary trust anchors come from at the Boot ROM
> level?

I think this is just a matter of firmware implementation. If somebody has
really need for this, it can be implemented in firmware, too.>
And IIRC, HTTPS for booting has been suggested by someone at the IETF 74
meeting in San Francisco, so there seems to be real interest in this topic
(I wasn't there at that meeting, so maybe one of the attendees can say
something about this? Vincent?)

> (3) General textual issue: length field descriptions
>
> There seems to be textual confusion between the length of a field
> and the (overall) length of a DHCP option, with much verbiage added
> with the apparent intent to clarify the (IMO) improper terms used.
> The length field of a DHCPv6 Option generally specifies the length
> ot the option value.  If the option value consists of a single data
> field, the shortmost and most precise phrase possible would be to
> simply say so for the length.  Using positive language enumerating
> what is included seems to be much more clear and preferable over
> using "subtractive" notion.

Ok... I thought some explicit words might help here to make it easier to
read, but if people prefer it more condensed, that's fine for me, too. So
has anybody else any thoughts on this?

> (4)  more editorial nits
[...]

Ok, thanks for spotting these! I will correct them with the next update.

Mit freundlichen Grüßen / Kind regards,
   Thomas Huth
                                                                           
    IBM Deutschland                 Vorsitzender des Aufsichtsrats:        
    Research & Development GmbH     Martin Jetter                          
    Schönaicher Str. 220            Geschäftsführung: Dirk Wittkopp        
    71032 Böblingen                 Sitz der Gesellschaft: Böblingen       
    Tel.: +49-7031-16-2183          Registergericht: Amtsgericht           
                                    Stuttgart, HRB 243294                  

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Theodore Vojnovich <[email-masked]>
Date: Wed, 6 Jan 2010 17:27:02 -0500

Arent you really going to want to say key is provide by independent 
resource from the boot image resource.   Ie if key is in memory, how did 
it get there?   This leads to the whole thread of key mgmt and deployment.
I dont think you want to get into all that but also dont think you want 
limit this to just  "configurable key in memory"...maybe at least hint at 
the fact there may be
several simple to substantive approaches supported (since you may not care 
how the key got into memory....just that it did not come from same 
resource as boot image....otherwise might be hackable/spoofable/etc)

Just my 2 cents.

Thanks

Ted Vojnovich
STSM Blade Center Storage Solutions
IBM Corp.
N202 / B205
3039 Cornwallis Dr
RTP NC, 27709
Voice:  919-254-0730 (T/L 444-0730)
Fax: 919-543-2820
Cell Phone:   919-656-5061
Email:  [email-masked]

"Zimmer, Vincent" <[email-masked]> 
Sent by: [email-masked]
01/06/2010 04:51 PM

To
Thomas Huth <[email-masked]>, Alfred Hönes <[email-masked]>, 
"[email-masked]" <[email-masked]>
cc

Subject
Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-netboot-07

Yes.   There are a plurality of security considerations possibly.   Given 
the state of DHCP security and our attempt to have some behavior parity 
with IPV4 netboot, we were not intending exhaustive treatment of this 
subject area.

You are correct Thomas that HTTP-S was added based upon the suggestion of 
a Lucent engineer during IETF74 dhc session in SF as a possibility. 

   or that the boot loader

Vincent

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of 
Thomas Huth
Sent: Sunday, December 27, 2009 3:14 AM
To: Alfred Hönes; [email-masked]
Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-netboot-07

Hello Alfred!

I think we should not use IRIs here. I guess most firmware implementations
do not have a full blown i18n implementation and if I've got RFC3987 
right,
HTTP also does not work well with IRIs:

[...]

---

From: "H. Peter Anvin" <[email-masked]>
Date: Wed, 06 Jan 2010 18:57:12 -0800

On 01/06/2010 02:27 PM, Theodore Vojnovich wrote:
> limit this to just  "configurable key in memory"...maybe at least hint
> at the fact there may be
> several simple to substantive approaches supported (since you may not
> care how the key got into memory....just that it did not come from same

Well, there really are only two options, aren't there... either the key
came from somewhere physically on the system (ROM, TPM, or even disk),
installed through some previous means, or it was fetched from some
trusted portion of the network...  Either which way it seems somewhat
outside the scope of this particular RFC.

	-hpa

---

From: Thomas Narten <[email-masked]>
Date: Thu, 07 Jan 2010 13:58:39 -0500

I think I'm too blame for rasing the UTF-8 issue.

I think we want UTF-8 for the "Boot File Parameters Option". That is
just data (bytes) passed from the server to the client. The current
wording on the documents calls for UTF-8 here now and is good IMO.

For the URI/URL, I don't know the right answer. Getting someone from
that community to help us get the details right is what we need to do.

Thomas

---

From: Thomas Huth <[email-masked]>
Date: Fri, 8 Jan 2010 09:45:01 +0100

> that community to help us get the details right is what we need to do.

I've discussed this with Ted Lemon and Lisa Dusseault: RFC3986 / STD66
currently requires ASCII encoding (with percent encoding for non-ASCII
characters). But since this might be subject to change in the future, we
now simply say in version 08 of our draft that the URL string must comply
with STD66, without specifying the encoding there. So when STD66 gets
updated one day, we do not have to update the netboot document anymore.

---

From: Alfred Hönes <[email-masked]>
Date: Fri, 8 Jan 2010 12:11:34 +0100 (MEZ)

Thomas Narten wrote:

> I think I'm too blame for raising the UTF-8 issue.
> 

Agreed, that sounds reasonable, and that meets my expectations.

> that community to help us get the details right is what we need to do.

The advice from W3C already has been fed into an IETF Full Standard:

Quoting from STD 66, RFC 3986 (Section 1.1.3, bottom of page 7):

         [...]  Future specifications and related documentation should
   use the general term "URI" rather than the more restrictive terms
   "URL and "URN" [RCF3305].

Indeed, RFC 3305 (co-published as a W3C NOTE in 2002) contains the
applicable rationale.  However, please note that a significant part
of RFC 3305 now is OBE (outdated by events), in what RFC 3305 says
"should be done" (in the IETF) has been done subsequently, to a great
extent; RFCs 3986, 3987, and 4395 are the result; unfortunately, the
URN namespace related RFCs have not been updated so far (source of
some repeated confusion!).

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+