Subject: [Sipping] Review of draft-ietf-sipping-config-framework-11

From: Cullen Jennings <[email-masked]>
Date: Fri, 9 Mar 2007 15:35:40 -0800

My overall feeling was that it was easer to understand and making  
progress in the right direction but still had a long way to go. This  
is all sent with my individual hat on and I apologize that many of  
the comments are not all that clear but I am trying to get thorough a  
bunch of drafts right now - I'm happy to rewrite or clarify any  
comments that make so little sense that you can't figure them out.

Cullen <with my individual hat on>

I think the separation of the security stuff into the security  
section is causing serious problems. I think the best path would be  
to describe the normative things the various software must do like in  
the place it makes sense outside the security section. Then have the  
security section only focus on explaining the threats, the overall  
model, why it is secure, and any limitations.

I think the device ID should be carried in the contact and nowhere else.

I think the rules for how the users id gets inserted are the same for  
all profiles types

3.3 2nd para, last para, should be clear applies to devices enrolled  
to that profile not all enrolled devices

3,2 - for the security to work we need to put some additional  
explanation about what is in the profiles.

Local network - typically will not have any information that could  
not be revealed to everyone
Device Profile - typically has significant users specific private  
information including  pointers to the user profiles and the  
credentials to access them
User PRofiles - typical has significant private information

5.1 - need to deal with ordering if both v4 and v6 are available

5.1.1.1 -
point 1 -  we have no guarantee that sipuaconfig.domainj is not  
already in use for something else. I feel pretty strongly we can't  
use this. I suggestion the _ approach.
in point 3 - duplicates point 1
point 4 - put in contact header

ALso the AOR may not be known to the device at this point.

5.1.1.2

I don't think the request URI needs the device id - this is in the  
contact

5.1.1.2.1

The MAC stuff is forming a new URI type and would need registration -  
this will be a bunch of work and this is 100% a subset of UUID.  
Originally people claimed this would be done long before UUID so we  
could not block on UUID - this is no longer true since UUID is an  
RFC. I think we should make this document simpler and drop the MAC  
stuff.

Section 5.1.1.2.2

The draft has
    Devices MUST follow the procedures specified below in the order
    presented, unless exceptions are made by device manufacturers or
    Device Providers who may provide an option for the user to choose  
the
    order (to suit specific deployment models, for example).
We need to remove unless wiggle room like this to make it so the  
draft specifies something that would be interoperable. The draft has  
the specific places where a device can use some manufacture or  
manually specified sort of way of getting some information - that's  
part of the spec and does not need a you MUST do X unless you decide  
to do something else.

In point 1
Has
      The details of how this is
       accomplished are beyond the scope of this document.
I disagree - i think this clearly explain what happens when the dim  
or flash provides the domain of the PDS or some other info

point 2, the MUST could be removed from this para

2a - "devices that support DHCP" - we need to decide if this spec  
requires devices to support DHCP - I suspect it does because we have  
no other way to get local network profile

2b - why do we really need both of approaches described  in 2b -  
could we simplify and just have one of them

in point 3 3
have
      the device SHOULD provide a means for the user
       to present information that may help with the retrieval process.
this is way too vague - suggest chaining to
       the device SHOULD provide a means for the user
       to manual enter the domain

later
        The user MAY be
          allowed to present information pertaining to a configuration
          server that provides the device profile, not using a PDS as
          defined in this framework.  This framework specifies one such
          possible process in Section 5.5.1.
way too vague to be implementable - just remove

Section 5.1.1.4
  Things like "... should be carefully considered." leave me not  
knowing what this means to an implementor.

draft has
   When cached, the device
    should use the cached Subscription URI upon a reset.  Exceptions
    include cases where the device identifier has changed (for example,
    new network card with a new MAC address), Service Provider
    information has changed (for example, user initiates change) or the
    device cannot obtain its profile using the Subscription URI.

I think there are some subtleness of what a reset is here that we  
need to cover. Clearly if it reboots, power cycles, etc it needs to  
cache. However if the users does "reset to factory ship" sort of  
state, then it should not cache. I don't know the best way to write  
this up but it will take some text. Basically the device should cache  
this as long as it the user does not tell the device to blow it's  
brains out. I think it is fine if a device profile updates the URL  
for future device profiles - this should also be mentioned.

I think the
    or the
    device cannot obtain its profile using the Subscription URI.
is the wrong thing to do. Basically, when you loose this ache, the  
phone will in many cases will enroll in the local network. This means  
that if I took my phone to a hotspot, and it temporarily could not  
connect to the right thing, it might go and enroll in the local  
system - this is not what we want.

5.1.1.4 has not mention of user URI - it should

5.1.2

the points that a device MUST do something specified elsewhere in the  
document is really confusing as a MUST - just put the normative  
language in the other section and remove the MUST here

You have
    A device SHOULD follow suitable BackOff and Retry mechanisms if a
    successful Profile Enrollment does not happen within the expected
    period.
This needs to be specified how this all works

5.1.3.
The document needs to deal with what happens if a profile is  
downloaded but that profile data has an error in it. There needs to  
be a way for the PDS to understand the client will not perform the  
update.

The do has
    o  the device SHOULD cache (i.e. store persistently) the contents of
       retrieved profiles, until overridden by subsequent Profile Change
       Notifications (this avoids situations where a PDS is unavailable,
       leaving the device without required configuration)
I don't think we want this for the local network - the problem is  
that if you can't access the local PDS - your info is likely to be  
very wrong and assuming no local PDS is likely better.

Stuff like
    the device MUST retry using alternate methods for
    creation of the enrollment subscription and transmit an enrollment
    request.
seems really confusing - how do I implement that MUST in an  
interoperable way? Just delete  all this sort of stuff from the draft.

section 5.2

    Profile Content Retrieval protocols and frameworks are out of scope
    for this specification.
I don't think this is true. The document specifies it is mandatory to  
implement http and https as well as NOTIFY - it provides a way to  
negotiate what transports (such as https or ftp) can be used and it  
specifies a way to negotiate what body types are understood by the  
client.

All this should be described at a high level here along with a way  
for the client to find out the PDS can not produce any profile  
content type that the client can understand.

5.4 - delete "compliant with this framework"

Section 5.5.1

Paragraph 1 - this example makes absolutely no sense as a motivation.  
If DNS does not work for SIP, it's not going to work for HTTP either.  
The solution if you want it to wok when DNS does not is to use an IP  
address in the SIP URI for the profile.

Things like
    devices expected to encounter scenarios where propogation of the
    device profile can be hindered may employ the specified - or any
    alternative - process.
make no sense for figure out out to make this work in an  
interoperable way.

The problem with this HTTP approach revolves around the only reason  
you would do it was if the SUB/NOT did not work. But if the SUB/NOT  
did not work, it is not going to work after the HTTP fetch. At this  
point their is no way to find out about future updates and apply  
them. The point of this framework and reason it was in RAI not apps  
was because it requires real time notifications of change updates.  
This section breaks that and offers no benefits that I understand.   
There are also issues with what the credentials are because the URI  
now has to be long lived and contain contain the secret in part of  
the URI. It is also unclear how the PDS finds out that the NOTIFY are  
not working.

I am very much in favor of removing all of 5..5.1 unless someone can  
clearly articulate why the existing approaches in the rest of the  
draft are not adequate.

5.5.2

There are some issues to explain this draft for devices that do not  
know about a user - I would leave it out of scope for now but I don't  
feel too strongly about this.

5.5.3

has
     As an example, the device profile
       may contain the list of codecs to be used by the device and the
       user Profile (for a user on the device) may contain the codecs
       preferred by the user.  Thus, the same data (usable codecs) is
       present in two profiles.
I think this is a bad example - the device profile has a list of  
"allowed codecs" which is merged with the inherent "supported codecs"  
that the device has software to support, and then this list can be  
combined or ordered with the users "preferred codecs" lists. The  
allowed, supported, and preferred all seem to be fairly different  
information to me.

6.2
I think the device-id and network-user should be removed from the  
Event header. The network-user can be found in the From and device-id  
in the contact. Having them two places will only lead to problems  
within they are not the same and means we do not need to deal with  
the privacy of them separately in two different places.  I have not  
heard any compelling reasons they need to be here.

6.2.5
need to specify that the units for the effective-by is seconds. WOuld  
be nice to specify an upper bound on the number too (like 32 bits or  
something)

6.5 - this is vague about who has to support TLS, - I think what you  
want is both client and PDS

the draft has
Further, if the Accept header of the
    SUBSCRIBE included the MIME type message/external-body (indicating
    support for content indirection) the content indirection SHOULD be
    used in the NOTIFY body for providing the profiles.
I think this SHOULD needs to be a MAY - the PDS should be able to  
choose. ALso need to say somewhere that if the UA does not support  
cid, then PDS MUST send the profile in the NOTIFY

here it says
    If none are
    specified, the Profile Data frameworks are responsible for, and MUST
    specify, the MIME type to be assumed.
This does not make sense - I think UA has to say what it supports and  
only those can be used

section 6.6
    If
    the NOTIFY is expected to contain profile contents or the  
Notifier is
    unsure, the SUBSCRIBE SHOULD be either authenticated or transmitted
    over an integrity protected SIP communication channels.
this is looking pretty wacky to implement without knowing an awful  
lot about the data before you decide to even accept the subscribe.

In generally all the stuff about how and when a subscribe id  
authenticated is very confusing. I think we need to work through in a  
very clear way. In general, I think the approach should be along  
lines of
1) PDS receives subscribe (regardless of profile type) and decided if  
the From is an AOR that it is authoritative for
2) if not it marks the request "unauthenticated"
3) if it is, it challenges and if the challenges succeeds it marks  
the the request as  "authenticated"
4) when profiles data schema are defined, the are specified as either  
working for unauthenticated, authenticated requests, or both
5) if it us an unauthenticated request and profile data that requires  
authentication, no result is returned
6) if it in an unauthenticated request and a profile that returns  
both, the profile defines how to construct the returned data such  
that no privacy is revealed for the unauthenticated request.

Everywhere the document has "integrity protected SIP communications  
channel" just change it to to TLS, it's the only one we have defined  
for SIP where the application can detect this is the case and can  
understand who it is integrity protected too.

Section 6.7

Does the Subscriber have to support content indirection? I would  
actually prefer not to require this but can be convinced either way.

     If the SUBSCRIBE was received over an integrity protected SIP
    communications channel, the Notifier SHOULD send the NOTIFY over the
This would be a change to 3261. Imagine a case where SUB came via a  
proxy that did not RR. By default the NOTIFY would not. I basically  
think that the best way to deal with this is just say that clients  
have to use outbound but I'm also ok with saying nothing on this  
subject.

draft has
    If the Subscriber wishes to support alternative URI schemas
    it MUST be indicated in the "schemes" Contact header field parameter
    as defined in [RFC4483].  If the subscriber does not specify the URI
    scheme, the Notifier may use either "http:" or "https:".
I think it would be better to go with the Notifier MUST not use any  
scheme that was not indicated in the schemes

6.8

This does not cover what happens with the error handling when the  
Subscriber gets some profile data that they are not capable of  
interpreting because it has a syntax error or something. I think he  
PDS needs to know that the stuff it wanted to be effective by item X  
is not going to happen.

6.9

ANy advice on how to stop or what to do if forking does happen.

I ignored all the example sections

Section 9 prior to 9.1 seemed like it might not be needed but we can  
ignore till more of the nuts and bolts is clear.

I don't read this and get the felling that we have a simple clear  
description of how security works. As I said on the call, I think you  
need to clearly explain how both the device and PDS are authenticated  
for each profile type, where the credentials come for for  
authentication, how the integrity of the profile data is ensure, and  
then how the privacy of profile data is protected. To me it seems  
that for

Can you just change "service credential" to credential - I have no  
idea what a service is after reading the sipping list :-)

  o  devices and PNCs complying with this framework MUST implement TLS
       as specified in [RFC3268], including support for both mutual and
       one-way authentication (server-side)

This is for SIP or HTTP? mutual TLS is not really possible in SIP for  
the type of devices we are talking about here. I would like to see  
this defined assuming that the way a UA authenticates to a server is  
using digest. If at some later date some sets up a certificate based  
approach for doing this then that can state that it is an alternative  
to digest and can be used where digest is used.

   o  a PNC capable of propagating device and user profiles MUST contain
       a X.509 certificate.  This certificate MUST contain the PNC's
       Fully Qualified Domain Name in the 'SubjectAltName', establishing
       the PNC as a host in the Service Provider's domain

Uh - it needs to be more subtle this this - we need to say must  
implement not must use. We also need to allow for certificates that  
use CN instead of SAN.

   o  a PNC capable of propagating local-network profiles or
       unauthenticated device profiles MUST support the use of the SIP
       Identity header as defined in [RFC4474] for inclusion in profile
       notifications

What identity would it assert - this never seems to be discussed.

       *  the PNC MUST authenticate the identity of the user (if set to
          anything other than the default)

what is the default? this seem like the wrong way to go

      *  the PNC MAY NOT authenticate requests for the local-network
          profile that do not result in any user-specific sensitive data
          (irrespective of the value of the From field)
I know what you are getting at here but keep in mind it means the PNC  
needs to be able to know what requests will result in this and what  
will not.

      *  the PNC MUST include the SIP Identity header as defined in
          [RFC4474] within profile notifications sent in response to
          local-network profile enrollment, unless an integrity- 
protected
          channel exists (for example, using S/MIME)
I think that Identity is a good way to provide integrity for the body  
but keep in mind it is just the body and not the header with the cid.  
This would need to be clear about when you did not need to send it. I  
think we can safely assume that no one will use S/MIME in the short  
term and that our solution needs to work without it.

        *  a device receiving profile notifications for local-network
          profiles MUST verify the SIP Identity header, unless
          transmitted over a previously established authenticated,
          integrity-protected channel.
keep in mind the name we are verifying against we discovered with  
DHCP so I am having a hard time figuring out what this buys us from a  
security point of view for this profile - I understand for device and  
user.

          If none exists, the
          device MUST establish a TLS connection with the PNC and verify
          the PNC's certificate.
Are we only going to allow config to be used in places where there is  
not edge proxy? this seems too limited to me

I think that in the case of a phone that has no credentials and is  
getting a device profile for the first time, explaining the baby duck  
imprint and why this is OK because the phone does not reveal anything  
that was not already known to the system it imprinted on is worth  
explaining

draft has
         If the PNC authentication fails or a
          secure communications channel cannot be established, the  
device
          MUST treat it as a device profile enrollment failure and take
          measures such as retry enrollment
what does retry mean here? if it means dumping the cached URI, that  
would be really bad from a security point of view

Worth talking about how a new device with no AOR or credential gets  
enrolled.

Section 9.2

   o  devices and PCCs compliant with this framework MUST implement HTTP
       Digest authentication as specified in [RFC2617]; this is used
       whenever an authentication challenge is initiated using HTTP  
based
       protocols specified for interoperability
need to describe where do the credentials fro this come from? and how  
does device know which one to use

    o  a PCC complying with this framework MUST contain a X.509
       certificate.
I think we want must implement not must use

Need to discuss how names of certs are validated

Section 9.3

I did not understand
    o  an entity that is allowed to make updates MUST contain a AOR that
       is known to the network and the requirements for making changes
       are the same as that for user profile content retrieval, with the
       authorized entity playing the role of a user

Section 10
OLD
     Rohan Mahy from Plantronics
NEW
    Rohan Mahy from Cisco, Airespace, Plantronics, and couting

(and Jon is from Neustar)

_______________________________________________
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: Adam Roach <[email-masked]>
Date: Tue, 13 Mar 2007 15:48:42 -0500

Cullen Jennings wrote:
> already in use for something else. I feel pretty strongly we can't use 
> this. I suggestion the _ approach.

I'm not certain I understand the suggestion made by this comment, but it 
touches on something that's kind of bothered me for years.

Cullen: are you suggesting that the client should use a SIP URI with "_" 
in them? I don't think that's necessarily valid for A records -- it is 
my understanding that the use of _ in DNS is reserved for special 
purposes (such as its use in SRV lookup). Alternately, it sounds like 
you might be suggesting the use of something akin to yet another level 
of DNS redirection. I can imagine a scheme along the lines of:

   1. Perform a DNS lookup on the **SRV** record for
      "_sipuaconfig._tcp.domain"
   2. Discard the port number. Use the string present in the target of
      the DNS result as the domain portion of the SIP URI.

This certainly works -- but I'm concerned that it is really hack-ish. 
It's using SRV in a way that it was clearly not intended to be used. The 
use of TXT records in a similar fashion would eliminate this concern, 
but the semantics around TXT are nonexistent, and there's no collision 
prevention (aside from RFC 1464, which is experimental). We could do 
something very similar with NAPTR records by defining a new service 
field for SIP UA configuration, but I'm a bit worried about the size of 
NAPTR responses if we start stuffing everything into the domain-level 
NAPTR records.

Do any of these line up with what you were thinking? If not, could you 
try to clarify what you meant?

/a

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 16 Mar 2007 06:04:30 +0100

So yo porbably knwo more abotu this than me but ... Underscore names  
as leaf names have been used as a way of reserving special names in  
DNS that are guaranteed not to be taken (because underscore is not  
legal in a hostname).  The SRV registrations are one example of this,  
there are other such as how DKIM does a lookup. There is some work  
going on to get an IANA registry for them as they clearly need to be  
IANA registered.

I was thinking it would be an A lookup but I don't actually know if  
that is legal or not - let's try and sort this one out.

On Mar 13, 2007, at 9:48 PM, Adam Roach wrote:

> I'm not certain I understand the suggestion made by this comment,  
> but it touches on something that's kind of bothered me for years.
>
> Cullen: are you suggesting that the client should use a SIP URI  
> with "_" in them? I don't think that's necessarily valid for A  
> records -- it is my understanding that the use of _ in DNS is  
> reserved for special purposes (such as its use in SRV lookup).  
> Alternately, it sounds like you might be suggesting the use of  
> something akin to yet another level of DNS redirection. I can  
> imagine a scheme along the lines of:
>
> This certainly works -- but I'm concerned that it is really hack- 
> ish. It's using SRV in a way that it was clearly not intended to be  
> used. The use of TXT records in a similar fashion would eliminate  
> this concern, but the semantics around TXT are nonexistent, and  
> there's no collision prevention (aside from RFC 1464, which is  
> experimental). We could do something very similar with NAPTR  
> records by defining a new service field for SIP UA configuration,  
> but I'm a bit worried about the size of NAPTR responses if we start  
> stuffing everything into the domain-level NAPTR records.
>
> Do any of these line up with what you were thinking? If not, could  
> you try to clarify what you meant?
>
> /a