Subject: Re: [secdir] secdir review of draft-ietf-dhc-access-network-identifier-08

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 10 Jul 2015 16:19:37 +0000

Hi Catherine,

Thanks for the review.

> However, what needs to be go in the Security Considerations Section is a discussion of the security risks raised by *this* document and possible mitigation.  The information about DHCP security risks is useful, but not of primary importance.

Agree with this comment. The  draft is defining some new information elements that are carried between the DHCP entities and any new security considerations are around exposing that data to third parties.

"The information elements that this draft is exposing is the client’s access-network information. These pertains to the access network to which the client is attached, such as Access Technology Type (Ex: WLAN, Ethernet…etc), Access Point Identity (Name, BSSID), Operator Id/Realm. Exposing these information elements to  has no implication on the end-user security. But, in deployments where this information is considered secure and when such threat cannot be mitigated using the currently available security tools, then the administrators have to consider disabling this capability on the DHCP entities."

Is this sufficient ?

Regards
Sri

From: Catherine Meadows <[email-masked]<mailto:[email-masked]>>
Date: Thursday, June 25, 2015 at 7:56 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Catherine Meadows <[email-masked]<mailto:[email-masked]>>
Subject: secdir review of draft-ietf-dhc-access-network-identifier-08
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-To: <[email-masked]<mailto:[email-masked]>>
Resent-Date: Thursday, June 25, 2015 at 7:56 AM

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.

This draft specifies the format and mechanisms used for encoding network identifiers in DHCPv4 and DHCPv6 by defining new access identifier options and sub-options.
The Security Considerations section gives a discussion of the security risks in using DHCP and their mitigation.  However, what needs to be go in the Security Considerations
Section is a discussion of the security risks raised by *this* document and possible mitigation.  The information about DHCP security risks is useful, but not of primary importance.

My impression is that this document gives formats for presenting fields whose use is already discussed in previous RFC’s, e.g. RFC3315, in which case there are no new
security considerations.  If that is so, then the Security Considerations Section should
include (preferably begin with) a statement to the effect that, since this document only gives instructions for formatting and encoding fields whose use has already been specified
in these previous RFC’s, it presents no additional security considerations beyond what is covered in those RFCs.  If that is not the case, you should say what new security risks are introduced
by *this* draft, e.g. does it enable a use of DHCP that was not possible before and could cause a new type of security risk if DHCP was used without authentication?

Recommendation:  Ready With Issues

Cathy Meadows

Catherine Meadows
Naval Research Laboratory
Code 5543
4555 Overlook Ave., S.W.
Washington DC, 20375
phone: 202-767-3490
fax: 202-404-7942
email: [email-masked]<mailto:[email-masked]>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 10 Jul 2015 16:27:20 +0000

Something happened at "elements to  has no".

The IETF is a strange place these days with all of the pervasive monitoring concerns :). If people can capture relay traffic (since we're only adding this now there), there's a lot more that they can monitor. Ah well.

And, actually the RFC 3315 IPsec requirements for relay traffic can apply here:

21.1. Security of Messages Sent Between Servers and Relay Agents

   Relay agents and servers that exchange messages securely use the
   IPsec mechanisms for IPv6 [7].  If a client message is relayed

IPsec should also hide this information from pervasive monitoring (though how much IPsec is in use is an open question). Note also that as this is relay to server (or relay to relay) communication, one would hope that most SPs have taken measures to 'secure' this traffic either by using IPsec or VPNs.

-          Bernie

From: Sri Gundavelli (sgundave)
Sent: Friday, July 10, 2015 12:20 PM
To: Catherine Meadows; [email-masked]; [email-masked]; [email-masked]
Subject: Re: secdir review of draft-ietf-dhc-access-network-identifier-08

Hi Catherine,

Thanks for the review.

"The information elements that this draft is exposing is the client's access-network information. These pertains to the access network to which the client is attached, such as Access Technology Type (Ex: WLAN, Ethernet...etc), Access Point Identity (Name, BSSID), Operator Id/Realm. Exposing these information elements to  has no implication on the end-user security. But, in deployments where this information is considered secure and when such threat cannot be mitigated using the currently available security tools, then the administrators have to consider disabling this capability on the DHCP entities."

Is this sufficient ?

Regards
Sri

My impression is that this document gives formats for presenting fields whose use is already discussed in previous RFC's, e.g. RFC3315, in which case there are no new
security considerations.  If that is so, then the Security Considerations Section should
include (preferably begin with) a statement to the effect that, since this document only gives instructions for formatting and encoding fields whose use has already been specified
in these previous RFC's, it presents no additional security considerations beyond what is covered in those RFCs.  If that is not the case, you should say what new security risks are introduced
by *this* draft, e.g. does it enable a use of DHCP that was not possible before and could cause a new type of security risk if DHCP was used without authentication?

Cathy Meadows

Catherine Meadows

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 10 Jul 2015 16:35:19 +0000

> “Exposing these information elements to < > "

Strange … it disappeared.

I was debating which Govt/Organization :) to point to, but then got distracted.

Regards
Sri

From: "Bernie Volz (volz)" <[email-masked]<mailto:[email-masked]>>
Date: Friday, July 10, 2015 at 9:27 AM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>
Cc: Catherine Meadows <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: secdir review of draft-ietf-dhc-access-network-identifier-08

Something happened at “elements to  has no”.

The IETF is a strange place these days with all of the pervasive monitoring concerns :). If people can capture relay traffic (since we’re only adding this now there), there’s a lot more that they can monitor. Ah well.

IPsec should also hide this information from pervasive monitoring (though how much IPsec is in use is an open question). Note also that as this is relay to server (or relay to relay) communication, one would hope that most SPs have taken measures to ‘secure’ this traffic either by using IPsec or VPNs.

-          Bernie

From: Sri Gundavelli (sgundave)
Sent: Friday, July 10, 2015 12:20 PM
To: Catherine Meadows; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: secdir review of draft-ietf-dhc-access-network-identifier-08

Hi Catherine,

Thanks for the review.

Is this sufficient ?

Regards
Sri

Cathy Meadows

Catherine Meadows

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 10 Jul 2015 18:27:44 +0100

Hiya,

On 10/07/15 17:27, Bernie Volz (volz) wrote:
> IPsec should also hide this information from pervasive monitoring
> (though how much IPsec is in use is an open question). Note also that
> as this is relay to server (or relay to relay) communication, one
> would hope that most SPs have taken measures to 'secure' this traffic
> either by using IPsec or VPNs.

Do we have any data as to whether or not such protection does
get deployed? I'd not be surprised if there's not much public,
but if there were it'd be good to know.

I also believe we have had reported cases where pieces of
the network infrastructure of various kinds of operator have
been targeted for PM purposes, so while yes, it is really
strange that someone would want to do that, it seems to be
a real, and not notional, threat.

Ta,
S.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 10 Jul 2015 17:43:26 +0000

I am not aware of such data. My guess is that most SPs place this kind of traffic in what they hope to be an isolated network (i.e., behind firewalls, ...).

Also, much of this data is pretty easy to find anyway ... SSIDs are mostly broadcast (or easy to snoop for), which mobile operator you use is probably discoverable in seconds (heck I bet you’d answer if I asked, or if I had your number a google query would probably tell me ...). So, I'm not really sure how critical this information tends to be. But, yet protecting it is better than not protecting it. But I think steps should have been taken for the other data in DHCP (relay to server).

- Bernie

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Friday, July 10, 2015 1:28 PM
To: Bernie Volz (volz); Sri Gundavelli (sgundave)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [secdir] secdir review of draft-ietf-dhc-access-network-identifier-08

Hiya,

> either by using IPsec or VPNs.

Do we have any data as to whether or not such protection does get deployed? I'd not be surprised if there's not much public, but if there were it'd be good to know.

I also believe we have had reported cases where pieces of the network infrastructure of various kinds of operator have been targeted for PM purposes, so while yes, it is really strange that someone would want to do that, it seems to be a real, and not notional, threat.

Ta,
S.

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 27 Jul 2015 16:24:36 +0000

Hi Stephen /Catherine,

Please lets us know if this text is sufficient to resolve this comment.

Slightly tweaking the text per Bernie’s comment. Now including IPsec reference.

"The information elements that this draft is exposing is the client’s access-network information. These pertains to the access network to which the client is attached, such as Access Technology Type (Ex: WLAN, Ethernet…etc), Access Point Identity (Name, BSSID), Operator Id/Realm. Exposing these information elements to an eavesdropper has no implication on the end-user security. But, in deployments where this information is considered secure and when such threat cannot be mitigated using IPsec [RFC4301] or other security protocols, then the administrators have to consider disabling the capability specified in this document on the DHCP entities."

Regards
Sri

On 7/10/15, 10:43 AM, "Bernie Volz (volz)" <[email-masked]<mailto:[email-masked]>> wrote:

- Bernie

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]]
Sent: Friday, July 10, 2015 1:28 PM
To: Bernie Volz (volz); Sri Gundavelli (sgundave)
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [secdir] secdir review of draft-ietf-dhc-access-network-identifier-08

Hiya,

Ta,
S.