Subject: Re: [dhcwg] AD review of draft-ietf-dhc-relay-agent-auth-01.txt

From: Mark Stapp <[email-masked]>
Date: Tue, 01 Jul 2003 13:47:29 -0400

Thomas,
Thanks for the comments. Replies/questions inline:

At 02:17 PM 6/24/2003 -0400, Thomas Narten wrote:
>The WG has requested publication of this document as a PS. My review
>comments:

[...]

>Second, I'm confused about the Relay Indentifier field, when it is
>needed (and why). It kind of seems to me that its needed to identify
>which relay agent added a particular set of relay agent options, but
>in that case, this isn't an authentication-specfic issue and would
>perhaps better be handeled in a way that isn't specific to the
>authentication suboption. (i.e, so it could also be used if the
>authentication suboption is not present).
>
> >    The Relay Identifier field is used by relay agents that do not set
> >    giaddr, as described in RFC 3046 [2], Section 2.1.
>
>I reread this section, and didn't feel like I completely understood...
>
>There are times when a relay agent just adds more suboptions to an
>existing relay-agent option, rather than appending a new set? That
>makes it harder to identify who inserted what option... This is even
>worse when one node signs (cryptographicall) information provided by
>another, and the "trust" is not based on strong crypto...

As the relay-agent option spec is written right now, there can only be a 
single instance of the relay-agent option. It's forbidden for a second 
relay to add another option, or modify the contents of an existing option.

We've talked within the working-group about deployments where there are 
multiple relay agents present, and in which more than one agent would like 
to insert relay options. I'm hoping that once authentication is possible 
between servers and agents, it will become possible to trust multiple 
instances of the option.

For the present, since we haven't decided how to (or whether to) revise 
3046, I needed some technique to allow for some of the known cases where 
more than one relay agent is involved. I consciously avoided trying to 
introduce a new option that could only be used for this purpose, tying the 
fate of agent authentication to it.

> >    selects an appropriate Replay Detection value.  The sender places its
> >    identifier into the Relay ID field, if necessary, or sets the field
> >    to all zeroes.  The sender sets the suboption length, places the
>
>Why not just always include it, since the field is there anyway...
>That would seem to simplify things...

The semantics of the giaddr field is very clear - it's an ip address. The 
relay-id is (I hope) also clear, but potentially different. We allow the 
relay-id to be something other than an ip address, so requiring that the 
two fields be set to the same value may be confusing if a site has 
established some other basis for assigning relay-id values.

>Nits below.

I've fixed the typos you caught.

[...]

> >    Four bits are reserved for future use.  These bits SHOULD be set to
> >    zero, and MUST be ignored when the suboption is processed.
>
>Not quite true, as the integrity check includes them? Reword?
>
> > 4.2 Replay Detection
>[...]
>less than, or less than or equal?

Quite right: should be <=.

> >    The Key ID exists only to allow the sender and receiver to specify a
> >    shared secret in cases where more than one secret is in use among a
> >    network's relays and DHCP servers.  The Key ID values are entirely a
> >    matter of local configuration; they only need to be locally unique.
> >    This specification does not define any semantics or impose any
> >    requirements on this algorithm's Key ID values.
>
>name space could be clearer. Would it be better to just say the
>combination of relay id/key ID is unique?  or something else? Or is it
>really intended that IDs are a flat space for the entire site?

Hmmm. I wrote "they only need to be locally unique." Is that unclear? Yes, 
I intended that the space be flat for the entire site. I don't expect more 
than a handful of keys to be in use, so I felt that that was adequate.

> >    should expect an Authentication suboption.  The receiver MAY be
> >    configured to drop incoming messages that do not contain a valid
> >    relay agent information option and Authentication suboption.
>
>better: MUST support configuration that allows ...

OK.

>NOte: since the signature is at the end of the option, wouldn't it be
>better to have the integrity check be performed up to the signature,
>but exclude it? What is the value in setting it to zero an including
>it in the check?
>
> > Use of the authentication suboption SHOULD be disabled by default.
>
>Seems unnecessary. How can the  suboption be used in the absence of
>keying info, which needs to be manually configured?

The user-visible behavior is different, though: 'disabled' is not the same 
as 'incompletely or incorrectly configured'. I wanted to provide a 
suggestion about the default since admins will have to deploy new software 
into their networks in order to get authentication. If the new 
authentication feature is disabled, the admin doesn't get an error message. 
If the new feature is enabled, then the admin immediately has a 
'misconfiguration' if there are no credentials, and the admin probably 
starts getting errors. That didn't seem helpful.

> > 4.7.1 Receiving Messages from Other Relay Agents
> >
> >    There are network configurations in which one relay agent adds the
> >    relay agent option, and then forwards the DHCP message to another
> >    relay.  For example, a layer-2 switch might be directly connected to
> >    a client, and it might forward messages to an aggregating router,
> >    which sets giaddr and then forwards the message to a DHCP server.
> >    When a DHCP relay which implements the Authentication suboption
> >    receives a message, it MAY use the procedures in Section 4.6 to
> >    verify the source of the message before forwarding it.
>
>Example could be better. An L2 switch presumably is not a relay
>agent...

Actually, it is true in some interesting configurations. For example, it 
may be the relay in an L2 switch that has access to information like which 
device/slot/port the client is on, and knows the 802.1x information 
associated with the client.

-- Mark

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

---

From: Ralph Droms <[email-masked]>
Date: Thu, 03 Jul 2003 09:14:41 -0400

Thomas ... comments in line.

At 04:03 PM 6/27/2003 -0400, Thomas Narten wrote:
>Hi Ralph.
>
> > The two techniques in this document both address the same
> > problem: the authentication of messages exchanged between
> > DHCP relay agents and DHCP servers.
>
>Yes. But the solutions are very different, and will likely be
>implemented by different people or as different products. I.e,. the
>IPsec part will require help from the platform on which the server
>runs, as opposed to be part of the DHC package. In fact, it may be
>implementable without touching the DHC server at all.

Your last sentence points out one of the reasons to write
one document: it's not clear that the IPsec solution is
really a separate protocol.

The consensus of the WG was that the two solutions are complementary
alternatives to a single problem, and that writing a single document
that addresses the relay agent message authentication problem
makes it easier for admins to evaluate and choose between the
two solutions.

>Another thing, when vendors say "we've implemented RFC XX", will that
>mean the IPsec technique, or the relay agent option, or both? Having
>both in the same document will likely be a bit more confusing.

"Implementing RFC XXXX" will mean having a solution to the
relay agent message authentication problem.

> > The title of the document should, perhaps, read "Authentication of
> > DHCP Message Exchanged Between Relay Agents and Servers".  The two
> > techniques for authentication are described in a single document
> > because they are applicable in different scenarios.
>
>If both were likely to be implemented together, I'd not have an issue
>with this. But I suspect this won't be the case.

OK.

Thomas, your last sentence here sounds like you have a solution
in mind already that is in conflict with the consensus of the WG,
as expressed in the WG meeting in SF.

> > Prior to the last dhc WG meeting, you had asked for a comparison
> > of the two techniques, which John Schnizlein published on the
> > dhc WG mailing list.  Based on that comparison, the consensus
> > of the WG was that the two techniques should be advanced
> > together, because neither was appropriate for all operational
> > scenarios.
>
>I have no problem with this.
>
> > At the dhc WG meeting in San Francisco we agreed
> > to advance the two techniques in a single document.
>
>I guess I wasn't paying attention during this part of the
>conversation, and am suggesting that keeping them in separate
>documents would be preferable.

OK ... but this suggestion is in opposition to the expressed
consensus of the WG.  We will have to go back to the WG
for consensus that rewriting the specification as two
documents is acceptable.

> > The description of the use of IPsec for authentication was copied
> > from an earlier draft of the DHCPv6 specification.  The text in
> > draft-ietf-dhc-relay-agent-auth-01.txt is the same as in the version
> > of the DHCPv6 specification that has been accepted as a Proposed
> > Standard.  The more detailed list of rules in the DHCPv6
> > specification will be used as the basis to provide additional detail
> > in this document.
>
>Fair enough. For background, I was also partly reflecting a private
>comment bellovin made a while back when I pointed him to the
>document. He said it was "thin" (or some such) and would probably need
>more detail. But he didn't provide specifics. It's also the case that
>in the IESG, we've seen a number of documents that for security say
>"just use IPsec". But in practice, the details can sometimes be tricky
>if you really want interoperability. E.g., there is a whole document
>on the topic for L2tp (RFC 3193). And MIPv6 also has a separate
>document (draft-ietf-mobileip-mipv6-ha-ipsec-03.html). In any case, I
>think we probably agree that there are fairly few words. If folk from
>the IPsec community think that is all that is needed, great. But we
>haven't seen such a review yet, AFAIK.
>
>Thomas

I fully agree that the text *in the current document* is inadequate.  I
suggest using text that addresses essentially the same problem from
a specification that has already been accepted by the IESG.

We have seen a review of the same list of rules in the DHCPv6 specification.
Do you have some reason to believe that those rules will not be
acceptable in this document?

- Ralph