Subject: [Sipping] config-framework-07

From: "Cullen Jennings" <[email-masked]>
Date: Fri, 29 Jul 2005 12:29:06 -0400

Many comments - but this is really getting better. I think the top level of
how it works I am understanding now but seems like there are some
contradictions and details missing still.

The two biggest areas of confusion for me are what the username/password
credentials used various place are. When getting a local profile, I don't
think any credentials can be required. When getting a user or applications,
I think it should be the same credentials that would be used in a SIP
REGISTER for the aor being used. The hard one is the device profile. I think
this needs a new username password that corresponds to that users
credentials on the configuration server - but perhaps I'm nuts. Open to any
suggestions but it needs to be defined one way or another.

The second area of confusion is exactly how the client gets the user and
applications URI to subscribe to *and* how it gets the credentials to use
for these.

The document needs an example flow with the whole sequence for some simple
phone.

It was unclear to me if the server had to support content indirection and if
the client had to. Should be clear for HTTP, HTTPS, TLS, Content
Indirection, Identity, hash in content indirection, and xcap-diff stuff.
There are parts in the doc that talk about these but seems a little
contradictor and not quite right.

Section 5.1
a latter diagram would really help here - I'm glad to do one if you want

step 7 implies that the profile has URI to the profile - this seems fraught
with danger and loops

The text that the client checks the common name in the certificate sends me
absolutely ballistic every time I read it. SIP uses the SubjectAltName.
These certificates are commonly available - they are marketed under the name
of a Microsoft Small Bossiness Server certificate. If we waver on this,
there are going to be many attacks on SIP possible by some people doing
SubjectALtName and others doing Common Name. There are good reason that we
use SubjectAltName - they are basically the same reasons that pkix WG
decided to ass SubjectAltName.

Section 5.2

Agree with it but needs more detail.

Section 6

- not clear what is at the device level. Is it only the list of users and
applications? Don't understand the difference between user and application.
Is user just a special application known as SIP UA? I've asked these many
times - I'm OK with having user and application but I have no idea how to
tell what I should put where. More explanation on what these are and what
goes where is needed. I suspect you have some separation of SP and ASP model
in mind - it will probably make sense to me - but I don't get it yet.

bottom page 13

say that if network-user is in SUB then most be in NOT. Why? What good does
this do?

Para top page 14 duplicate stuff already said

Table on page 16
- I think the dreaded table in 3261 should be proof enough this is a really
bad idea but I note the table already contradicts the text in the document
in several ways.
* network user is optional in things like device
* the s is wrong it that it should only be provided if it is known
I see no value in this table

section 7.5
2nd Para, "In this way Content-ID ...unnecessary interruption". I don't get
this at all, how does it help with this?

Section 7.6 - 2nd Para. This says that the client must support content
indirection and https. I don't think this is what we agreed to. I think we
came to content indirection was options for client, but if it did do it, it
had to https. The servers also don't have to do content indirection but if
they do, they have to do http and https.

section 7.8 - these should go through Identity service as required in
section 10

page 21 - examples have requests with to tags

page 22: we basically define a pseudo URN called MAC:. The apps area ADs
hate sort of defined URLs - we might just want to add and IANA section and
define a URN for mac address here and make it official. I note that IEEE
defines MAC-48, EUI-48, and EUI-64. Not sure if we need to differentiate
between these or anything. Just don't know.

section 8.1.1 1st Para : "SHOULD not" -> SHOULD NOT

8.1.2 2nd Para - says UA should allow the user to accept or reject the
discovered URI. I think this needs to be MAY not SHOULD because for a many
UA without displays, this would be very difficult

last 2 Para on page 27 - make clear these are both MAY level strength

Section 8.2 - 2nd to last sentence - move SHOULD to MAY - many will not want
to do this because of the DOS problems - suspect most SP would not while
most enterprises would. last sentence - section 7.5 seems wrong.

8.5 - this is not covered in the profile things - it is more a transport
than data model issue. You may just want to delete 8.5 and not open this can
of worms till later

Section 8.6 - Either this is way to much information or way too little I
can't decide which. But reading it I am sure of one thing, as an
implementer, I could not figure out how to form all the paths.

section 10 - would change MUST implement HTTPS or HTTP to MUST implement
HTTP and MAY implement HTTPS however, I don't think they do have to do HTTP
so I'm confused

Section 10.1 - see my previous common name rant

The part where you say the server may challenge the device for it cert to
use for S/MIME is complete gibberish. It can't do this for the SIP
connection. It can do this for the HTTP connection but it sounds like a bad
idea. A TLS cert may not be the same as the S/MIME cert. If you really want
to do this, I would just have the device upload the S/MIME cert.

How all the S/MIME stuff would work in here seems widely underspecified. I
would just remove all the S/MIME options because this can be secured without
using S/MIME.

last Para page 35 - the mutual auth with carts needs way more detail and
only works over https

the user approval of the sub server seems completely unnecessary here (not
to mention impossible on many devices and totally prove to be ignored by
users)

_______________________________________________
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