Re: [dhcwg] A new draft of draft-jiang-dhc-secure-dhcpv6 is submitted. Comments are welcome!

["Bernie Volz (volz)" <[e-mail]>]

If you want to extend the AUTH option to handle relay-agent to
relay-agent or relay-agent-to-server authentication, I don't think that
means you'd have to use a new option.

---

>option, more options MAY add other options after the relay message
option
>and these more options are option of B (not of A).  It is comply and
>consistent with RFC3315. See RFC3315, Section 7 :
>      options        MUST include a "Relay Message option" (see
>                     section 22.10); MAY include other options added by
>                     the relay agent. 

You'll note that this text in RFC 3315 states nothing about ordering.

- Bernie

-----Original Message-----
From: Sean Shuo Shen [mailto:[e-mail]] 
Sent: Monday, July 14, 2008 6:49 AM
To: Bernie Volz (volz); Mark Stapp (mjs); 'Sheng Jiang'
Cc: [e-mail]
Subject: RE: [dhcwg] A new draft of draft-jiang-dhc-secure-dhcpv6 is
submitted. Comments are welcome!

Hi, Bernie

> -----Original Message-----
> From: Bernie Volz (volz) [mailto:[e-mail]]
> Sent: Sunday, July 13, 2008 10:08 PM
> To: Sean Shuo Shen; Mark Stapp (mjs); Sheng Jiang
> Cc: [e-mail]
> Subject: RE: [dhcwg] A new draft of draft-jiang-dhc-secure-dhcpv6 is
submitted.
> Comments are welcome!
> 
> Sean:
> 
> Regarding point 1 and 2, the AUTH option was designed to carry
> authentication data. What that data is and how it is used depends on
the
> *protocol* field. The existing protocols are just the CURRENTLY
defined
> possibilities. New protocols can define new mechanisms. As 21.2 of RFC
> 3315 states:
> 
>    The Authentication option provides a framework for multiple
>    authentication protocols.  Two such protocols are defined here.
>    Other protocols defined in the future will be specified in separate
>    documents.
> 
I think your question is: can the CGA signature be put into the current
DHCPv6 auth framwork as the 3rd auth protocol besides the current two.  
This is a good question and actually we tried to fit the signature
option
into current AUTH framework at the beginning. The AUTH framework is open
for
more auth protocols and is a good place to carry more auth mechanisms.
But
there is a issues should be noticed:  DHCPv6 AUTH only allow one auth
option, thus only client and server can authenticate each other via auth
option. The relay agents have to be authenticated via IPSEC.  Our
proposal
trys to avoid this IPSEC requirement and makes sure that all the relay
agents in the middle can be authenticated and be trusted by the
receiver.
> 
> >However, in that
> >way, it is much more complicated for verifier to tell what contents
are
> >covered by this signature or not (especially when more options are
> added
> >during transmission).
> 
> As I keep trying to tell you this does NOT happen in DHCPv6. Messages
> are ENCAPSULATED; options are not "added" along the way (such as is
done
> in DHCPv4 with the relay-agent option). Once a message is formed (yes,
> the entity forming the message adds options), that's it - nothing else
> (no other entity) adds anything to the message. And, having the
complete
> message be part of the "signature" is the proper way to go.
> 
> For DHCPv6, the intent was that the way one handles options that have
> positional requirements is to ENCAPSULATE them within other options.
> That's why we have IA options (IA_NA, IA_TA, and IA_PD) which
> encapsulate the addresses (prefixes) and why those IAADDR/IAPREFIX
> options can encapsulate other options. The ordering of options at a
> particular level is immaterial and should NEVER need to be in any
> specific order.
We have been clarified before that once a message A with signature was
sent
by the client, no more options is added to this message A. The relay
agents
will generate relay message B which encapsulate A in B's relay message
option, more options MAY add other options after the relay message
option
and these more options are option of B (not of A).  It is comply and
consistent with RFC3315. See RFC3315, Section 7 :
      options        MUST include a "Relay Message option" (see
                     section 22.10); MAY include other options added by
                     the relay agent.
Regard,
Sean

> - Bernie
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Sean Shuo Shen
> Sent: Thursday, July 10, 2008 6:19 AM
> To: Mark Stapp (mjs); 'Sheng Jiang'
> Cc: [e-mail]
> Subject: Re: [dhcwg] A new draft of draft-jiang-dhc-secure-dhcpv6 is
> submitted. Comments are welcome!
> 
> Hi Mark,
> Thanks for the detailed comments. Please see answers in lines.
> 
> >it's certainly worthwhile to explore use of asymmetric keys to secure
> >dhcpv6, so it's helpful to see this work. but there are a number of
> >issues with the details in this draft:
> 
> Before going through each problem, it will be helpful to clarify a
> point:
> the mechanism we proposed is not just an alternate auth which uses
> asymmetric keys (instead of symmetric keys), it also prevent IP
spoofing
> because CGA (rfc3972) provides bound between public key and IP
address.
> 
> >1. it's not clear why the existing extensible authentication option
> >couldn't be used. I believe I could map everything proposed for the
new
> 
> >"Signature Option" into the existing option, so I have to ask: why
not
> >do that? I suspect that you can make a case that it would be awkward
to
> 
> >try to fit the CGA parameters data into the body of the
authentication
> >option, and so make the case for the new CGA params option. but I'd
> like
> >to see that tradeoff discussed.
> 
> There was a similar discussion with Bernie Volz yesterday and the day
> before
> yesterday. For unknown reasons, mails from Sheng did not show up on
the
> mail
> list. However, we paste some discussion context the following:
> 
> Overall, we are aiming to provide additional security on top of
current
> DHCPv6 by using CGA. A CGA address is designed cryptographically bound
> with
> the client (or server) public key, this public/private key pair can be
> used
> to provide IP address verification and data integrity WITHOUT any
> separate
> key management mechanisms. (I don't think any current DHC options can
do
> IP
> address verification.)
> 
> When CGA is used as a secure and identity-bound IPv6 address, no extra
> authentication key mechanism is needed. Also public key management is
> very
> easy and does not need to transmit key related material in plaintext
> like
> DHCP AUTH does. In summary, the newly proposed Signature Option can
> achieve
> the same security purposes with a simpler and safer foundations - key
> management.
> 
> Additionally, CGA can be used not particularly for DHCPv6, but also
used
> for
> other scenarios when a save and identity-bound IPv6 address (like
SEND)
> is
> desired.
> 
> >2. an important benefit of using the existing option and
specification
> >that supports it is that the text in rfc3315 is much more detailed
and
> >rigorous than the text in this draft. the 3315 text is clear and
> correct
> >about the actual computations based on the structure of dhcpv6
> messages.
> >I don't think there'd be much benefit in extending this draft so that
> it
> >duplicates that existing specification text. I'd much rather see a
> focus
> >on the specifics of the steps required to produce and verify the
> >key-pair-based hash and signatures.
> 
> The same answer for point 1. We provide new security mechanisms
> DIFFERENT
> from the current.
> According to the verifications, there are rigorous descriptions in
> rfc3971
> and rfc3972. Surely we can make a clear reference or give short
> descriptions
> for sender/receiver activities.
> 
> >2a. doing (2) would help get you out of thinking that you depend on
the
> 
> >ordering of options - the text in 3315 is correct about that. I
second
> >Bernie's point that there's no need to require special ordering.
> 
> The order design is to simplify the verification processing at the
> receiver
> side. It is certainly doable if the signature option is somewhere in
the
> middle and still protect message contents after itself. However, in
that
> way, it is much more complicated for verifier to tell what contents
are
> covered by this signature or not (especially when more options are
added
> during transmission).
> 
> >3. there are an unusual number of instances of direct quotation from
> >RFCs. IMO, it's generally better to refer to RFCs because small
quotes
> >can be misleading without the context of an entire protocol. it's one
> >thing to use quotations if you're trying to establish a clarification
> of
> >the meaning of a specific passage, but I don't think that's what's
> >happening here.
> 
> The reason we do these direct quotations is because DHCPv6 has more
> security
> issues than our mechanism can solve. What we are quoting is what
DHCPv6
> [RFC3315] states as security issues and we can solve it.
> 
> >4. it would be more useful to describe a general-purpose way to use
> >asymmetric key pairs. the only things specific about the CGA
> application
> >as described here is the details of the use of the CGA parameters
> >structure and the dependency on seeing the client's original IP
source
> >address. but isn't that really just a specialized case, that only
> >extends the general case in a couple of ways?
> 
> As we state at the beginning, our proposal is not only substitute
> symmetric
> key with asymmetric key, but also verification of IP address and
simpler
> also safer key management.
> 
> >5. do you intend this only to be used when DHCPv6 is used to convey
> >configuration options? are there any differences required to support
> >address configuration, or prefix delegation?
> 
> Any scenarios that the sender can use certain source address rather
than
> unspecific addresses can be protected.
> 
> >6. what happens in relayed environments - where the client's original
> IP
> >source address is no longer visible to the DHCP server? is this just
> >meant to be hop-by-hop integrity protection?
> 
> Reply agents will add its own CGA option and Signature option out of
> encapsulated client/server DHCP message.
> 
> >7. I don't see anything here about authorization. anyone who can
> >generate a key pair can use this, right? so ... it's just message
> >integrity protection? do you propose to configure clients with server
> or
> >relay public keys? something like SEND, would it be interesting to
> >authorize relays and servers via certs? or validate clients' keys
with
> >certs?
> 
> I think you are talking about authentication of the message sender.
This
> is
> exactly what the signature does. A malicious node can certainly
generate
> a
> key pair, sign the message with private key and send the public key
with
> the
> message. But the receiver can find out that this public key is not
> trustworthy according to local public key list or certs. Certificate
is
> a
> safe way to use asymmetric cryptosystem and it's not the only way.
> 
> 
> Thank you!
> 
> Sheng & Sean
> 
> 
> 
> 
> Sheng Jiang wrote:
> > A new draft of draft-jiang-dhc-secure-dhcpv6 is submitted. Comments
> are
> > welcome!
> >
> > Filename:    draft-jiang-dhc-secure-dhcpv6
> > Version:    00
> > Staging URL:
> >
>
http://www3.ietf.org/proceedings/staging/draft-jiang-dhc-secure-dhcpv6-0
> 0.tx
> t
> > Title:     Secure DHCPv6 Using CGAs
> > Creation_date:    2008-07-04
> > WG ID:     Indvidual Submission
> > Number_of_pages: 14
> > Abstract:
> > The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables
DHCP
> 
> > servers to pass configuration parameters. It offers configuration
> > flexibility. If not secured, DHCPv6 is vulnerable to various attacks
> > particularly fake attack. This document analyzes the security issues
> of
> > DHCPv6 and specifies security mechanisms, mainly using CGAs.
> >
> > Best regards,
> >
> > Sheng JIANG, Ph.D.
> >
> > IP Research Department, Networking Research Department, Network
> Product
> > Line, Huawei Technologies Co. Ltd.
> >
> >
> >
> >
> >
>
------------------------------------------------------------------------
> >
> > _______________________________________________
> > dhcwg mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dhcwg
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
> 
> 
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg


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