Subject: [Sipping] Comments on config-framework-14 - security considerations

From: "Elwell, John" <[email-masked]>
Date: Thu, 06 Dec 2007 21:03:56 +0000

Sumanth,

Sorry about the delay in reviewing this section. Comments below.

1. In section 9: "It
   is also important for the device to ensure the authenticity of the
   PNC since impersonation of the SIP service provider can lead to
   Denial of Service and Man-in-the-Middle attacks."
Should it also mention the PCC, i.e. "ensure the authenticity of the PNC
and the PCC"?

2. Concerning that same paragraph, the last few sentences are concerned
with content indirection and retrieval from a PCC. The next paragraph is
specifically about content indirection from a PCC. Therefore there seems
to be some duplication. In the first of these paragraph, are the
sentence beginning "Even is the profile data is provided using content
indirection" and subsequent sentences redundant? Is this case covered
adequately by the next paragraph, and if not, would it not be clearer to
cover everything to do with content indirection in that next paragraph?

3. In 9.1: "It also prohibits devices from responding to
   authentication challenges in the absence of TLS.  Responding to
   unauthenticated challenges allows for dictionary attacks that can
   reveal weak passwords."
The second sentence does not tie up with the first sentence. The use of
TLS does not mean that a challenge is an "authenticated challenge". Of
course, if TLS is used on all hops (which the device might trust to be
the case if SIPS is used), there will have been hop-by-hop
authentication, but I am not sure this is sufficient to consider a
challenge as being an "authenticated challenge". I don't have any
specific proposal here because I don't fully understand the reasoning
behind the present text.

4. Concerning the same text, during bootstrapping the device might not
have a CA to validate a TLS server certificate, so in this case
authentication is simply not possible, even when TLS is used. Special
security considerations for bootstrapping need to be mentioned.

5. "In
   such cases the device can validate the SIP Identity header to verify
   the source of the local-network profile."
In the case of content indirection it can only be used to verify the
source of the notification.

6. Concerning the same text, what about considerations for bootstrapping
mode? In this mode, a device probably will be unable to validate a
received identity.

7. In 9.2: "The
   profile data may also contain identities and credentials (temporary
   or long-term) that can be used to obtain further profile data from
   the network.  If it contains such sensitive data, the framework
   recommends the use of the SIP Identity header by the PDS."
I believe the framework recommends use of SIP Identity independently of
whether the profile data contains sensitive information.

8. "If such
   methods are used then large-entropy credentials MUST be used, or
   quickly replaced with such, to minimize the impact of dictionary
   attacks."
It doesn't make sense to say use "such methods" (referring to PIN etc.)
and at the same time to say use large-entropy credentials. All we can
say is that large-entropy credentials must replace the weaker ones. Also
the words "need to be replaced with such" seem to indicate that
large-entropy credentials need to be replaced, which doesn't make sense.
Suggest:
"If such methods are used, those credentials MUST be quickly replaced by
large-entropy credentials, to minimize the impact of dictionary
attacks."

9. "Future enhancements to this framework may specify device
   capabilities that allow for authentication without any pre-
   configuration (e.g., X.509 certificates using PKI)."
I am not sure what is meant by "without any pre-configuration". Somehow
the X.509 certificate and private key need to be obtained by the device
- isn't this pre-configuration?

10. "Alternatively, a
   PDS can use secure content indirection mechanisms such as HTTPS to
   provide the bootstrapping data."
This does not seem to make sense in the context. The previous sentences
have been talking about providing a device with credentials so that it
can authenticate itself with the PDS. Content indirection with HTTPS is
not an alternative to this.

11. "Authentication of profile retrieval via
   content indirection for sensitive profiles is via HTTPS."
The previous sentences have been talking about the PDS authenticating
the device, so presumably this sentence too is concerned with the same
subject. But HTTPS does not provide a means of authenticating the device
(unless digest authentication too is used).

Nits:
N1. "The framework specified in this documents"
Change to
"The framework specified in this document"

N2. "If specific to
   an entity, it and may"
Change to
"If specific to
   an entity, it may"

N3: "The framework also
   requires that a PDS presenting sensitive profile data to use digest
   authentication."
Change to:
"The framework also
   requires a PDS presenting sensitive profile data to use digest
   authentication."

John

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Sumanth Channabasappa" <[email-masked]>
Date: Mon, 10 Dec 2007 11:00:33 -0700

John,

Appreciate your comments on Section 9. Responses inline, after removing
comments I agree with (and plan to incorporate).

3. In 9.1: "It also prohibits devices from responding to
   authentication challenges in the absence of TLS.  Responding to
   unauthenticated challenges allows for dictionary attacks that can
   reveal weak passwords."
The second sentence does not tie up with the first sentence. The use of
TLS does not mean that a challenge is an "authenticated challenge". Of
course, if TLS is used on all hops (which the device might trust to be
the case if SIPS is used), there will have been hop-by-hop
authentication, but I am not sure this is sufficient to consider a
challenge as being an "authenticated challenge". I don't have any
specific proposal here because I don't fully understand the reasoning
behind the present text.
[S] The intent was that allowing for authentication challenge/response
pairs in the clear allows for disruptive (such as MiM) and
non-disruptive threats (such as rogue snooping devices that can launch
offline dictionary attacks). The presence of a SIPS URI, resulting in
hop-by-hop TLS, ensures that you are communicating with the intended
entity and prevents such threats. Thus, the framework prohibits you from
responding to challenges in the absence of TLS. If you agree with the
intent, I can make changes.

4. Concerning the same text, during bootstrapping the device might not
have a CA to validate a TLS server certificate, so in this case
authentication is simply not possible, even when TLS is used. Special
security considerations for bootstrapping need to be mentioned.
[S] Yes, and this is indicated in 9.2 (device profile). I already have a
note (from previous comments) to make this more explicit earlier in the
section.

6. Concerning the same text, what about considerations for bootstrapping
mode? In this mode, a device probably will be unable to validate a
received identity.
[S] Yes, and this is indicated in Section 9.2

9. "Future enhancements to this framework may specify device
   capabilities that allow for authentication without any pre-
   configuration (e.g., X.509 certificates using PKI)."
I am not sure what is meant by "without any pre-configuration". Somehow
the X.509 certificate and private key need to be obtained by the device
- isn't this pre-configuration?
[S] I think I should clarify that the pre-configuration indicated in the
quoted text needs to indicate 'no provider specific configuration'. For
example, a device can be preconfigured with a Root CA (using PKI) and as
long as the provider (or the SIP proxy the device connects to) can
present a cert that chains to a generic root, it can work. This is
common practice in currently deployed cable clients, but unsure of other
PKI uses. In any case, this is not within the scope of the framework and
was presented as an example.

10. "Alternatively, a
   PDS can use secure content indirection mechanisms such as HTTPS to
   provide the bootstrapping data."
This does not seem to make sense in the context. The previous sentences
have been talking about providing a device with credentials so that it
can authenticate itself with the PDS. Content indirection with HTTPS is
not an alternative to this.
[S] The intent is that you can use "content indirection" mechanisms if
other credentials are present (such as those that can be used with
HTTPS). So, it forms an alternative when you want to provide sensitive
data, but you cannot do so within the SIP NOTIFY (due to lack of a SIPS
URI)

11. "Authentication of profile retrieval via
   content indirection for sensitive profiles is via HTTPS."
The previous sentences have been talking about the PDS authenticating
the device, so presumably this sentence too is concerned with the same
subject. But HTTPS does not provide a means of authenticating the device
(unless digest authentication too is used).
[S] Use of digest over a server-side authenticated TLS is the intent
here (as indicated in the security requirements section). I can make
that clear here as well.

Thanks!
- S

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 12 Dec 2007 07:59:12 +0000

Sumanth,

See below.

John 

> -----Original Message-----
> From: Sumanth Channabasappa [mailto:[email-masked]] 
> Sent: 10 December 2007 18:01
> To: Elwell, John; [email-masked]
> Subject: RE: Comments on config-framework-14 - security considerations
> 
> John,
> 
> entity and prevents such threats.
[JRE] But the present text does not mention SIPS.

> Thus, the framework 
> prohibits you from
[JRE] I am not sure what changes you are proposing. One possible
improvement would be to change "in the absence of TLS" to "in the
absence of TLS on all hops as a result of using a SIPS URI"?

> note (from previous comments) to make this more explicit 
[JRE] OK

> [S] Yes, and this is indicated in Section 9.2
[JRE] OK

> was presented as an example.
[JRE] Yes, some clarification along these lines would do.

> data, but you cannot do so within the SIP NOTIFY (due to lack 
[JRE] So you will clarify this?

> here (as indicated in the security requirements section). I can make
[JRE] OK

---

From: "Sumanth Channabasappa" <[email-masked]>
Date: Wed, 12 Dec 2007 10:07:50 -0700

John,

Responses inline...

[JRE] But the present text does not mention SIPS.
[S] Yes, and this will be corrected.

[S] Yes.

[S] OK.

[S] Yes.

- S