Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows

From: "Reinaldo Penno" <[email-masked]>
Date: Thu, 13 Apr 2006 22:44:50 -0400

I believe it would be similar to what is described in the document sent
by Shockey to the list. Pasted below

10.1.2 Option 2: Digest Access Authentication
The second method of authenticating an Enterprise utilizes the digest
authentication scheme as described in section 22.4
of RFC 3261 [8]. In this model the Service Provider assigns the
Enterprise Network a username and password (referred to
as a "Network Account" hereafter) that is valid within the Service
Provider's domain (realm). It is important to note that if
the digest authentication scheme is employed, it does not eliminate the
requirement to utilize TLS between the Service
Provider and Enterprise Network SIP Proxy Servers.
When this model is employed, the following rules must be observed:
1. When processing an INVITE request from an unauthenticated PBX, the
SIP Application Server MUST challenge
the message, only accepting authentication credentials that are valid
within its realm.
2. When processing a REGISTER request from an unauthenticated PBX, the
SIP Application Server MUST
challenge the message, only accepting authentication credentials that
are valid within its realm.
3. When challenged by the SIP Application Server, the PBX MUST respond
with authentication credentials that are
valid within the Service Provider's realm (i.e. the network account
username and password supplied by the
Service Provider).
4. In order to avoid unnecessary challenges, the PBX SHOULD include its
authentication credentials using the
current nonce in each request sent to the SIP Application Server.

Finally, as with any peering "endeavour" I believe there will always be
the casethat they have physical/co-location security so TLS is not
needed.

Regards,

reinaldo

> -----Original Message-----
> From: Hadriel Kaplan [mailto:[email-masked]]
> Sent: Thursday, April 13, 2006 7:32 PM
> To: 'Michael Hammer (mhammer)'; [email-masked]
> Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows
> 
> I was confused by the registration as well but it must be for
different
> reasons because doing subscribe/notify doesn't solve my confusion.  :)
It
> has benefits for other things, and was what I was assuming would be
used
> for
> some policy exchanges ultimately, but not the piece I was confused
with
> this
> draft.
> 
> In the draft it says it's used for mutual proxy authentication.  For a
> typical register challenge method to do that, they have to have
> shared/known
> passwords and usernames. (are we assuming that?)  If a "key" is
exchanged
> in
> the register to be used as the password, as shown in the draft I
think, it
> does nothing; a man-in-the-middle has a view of those keys and can use
> them,
> and there's no authentication scheme for one proxy to believe the key
of
> the
> other anyway. (unless "key" means a nonce?)
> 
> Regardless, why not just use mutually-authenticated TLS?  The details
of
> how
> to believe the certs of each side though are still being discussed in
the
> sip mailing list I think. (I haven't been following it)
> 
> -hadriel
> 
> 
> > -----Original Message-----
> > From: Michael Hammer (mhammer) [mailto:[email-masked]]
> > Sent: Thursday, April 13, 2006 2:09 PM
> > To: [email-masked]; Reinaldo Penno; [email-masked]
> > Subject: RE: [Speermint] SPEERMINT Routing Architecture Message
Flows
> >
> > To the authors of draft-penno-message-flows-00.txt,
> >
> > One part of this that didn't seem quite right to me was the use of
> > mutual Registrations between Proxy 1 or domain A and Proxy 2 of
domain
> > B.  (e.g., Do you intend to do some type of Contact routing?)
> >
> > Could I ask by way of suggestion why you don't use mutual
> > Subscribe/Notify?  That would require the same authentication and
> > authorization to the requesting domain and would likely be much
richer
> > in terms of XML documents that could be supplied to the other domain
in
> > a Notify.  An event package per federation type could be defined,
for
> > example.
> >
> > What do you think?
> >
> > Mike
> >
> >
> > > -----Original Message-----
> > > From: Henry Sinnreich [mailto:[email-masked]]
> > > Sent: Thursday, April 13, 2006 12:55 PM
> > > To: 'Reinaldo Penno'; [email-masked]
> > > Subject: RE: [Speermint] SPEERMINT Routing Architecture Message
Flows
> > >
> > > The call flows shown are pretty much as would be expected
> > > from the trapezoid model in RFC 3261 using well defined SIP
> > > proxy behavior (lengthy section in RFC 3261).
> > >
> > > Why use B2BUA that have no defined behavior at all?
> > >
> > > Is it possible to standardize undefined behavior?
> > >
> > > Thanks, Henry
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Reinaldo Penno [mailto:[email-masked]]
> > > Sent: Wednesday, April 12, 2006 3:27 PM
> > > To: [email-masked]
> > > Subject: [Speermint] SPEERMINT Routing Architecture Message Flows
> > >
> > > Hello,
> > >
> > > We wrote a draft to help frame our discussions.
> > >
> > > Thanks,
> > >
> > > Reinaldo
> > >
> > >
> > > A New Internet-Draft is available from the on-line
> > > Internet-Drafts directories.
> > >
> > >
> > > 	Title		: SPEERMINT Routing Architecture Message Flows
> > > 	Author(s)	: R. Penno, et al.
> > > 	Filename	: draft-penno-message-flows-00.txt
> > > 	Pages		: 19
> > > 	Date		: 2006-4-12
> > >
> > > This draft describes the message flows associated with the
> > > SPEERMINT routing architecture. We show message flows in
> > > several peering scenarios.
> > >
> > >
> > > A URL for this Internet-Draft is:
> > >
http://www.ietf.org/internet-drafts/draft-penno-message-flows-00.txt
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Speermint mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/speermint
> > >
> >
> > _______________________________________________
> > Speermint mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/speermint
> 
> 
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint

_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Fri, 14 Apr 2006 00:20:55 -0400

Ahh, so the "key" in the draft is a nonce then?
The sip-connect model assumed the enterprise would be given the
password/username by the provider servicing it.  That would be possible for
the static peer-to-peer connection, but you could just as easily challenge
the first invite in that case, and not "register" anything.  For the dynamic
connect model it would be impractical to have configured pass/user info per
potential peer wouldn't it? (I don't know, just assuming)  Wouldn't it be
cleaner to just have it check the SAN of the cert matches a rule for
previous/next-peer domain authorization?

If they have physical/co-location "security" then why bother with
proxy-proxy authentication for that case?  I would think you'd only need it
for insecure peering links, where spoofing, mitm, and such can occur.

-hadriel

> Sent: Thursday, April 13, 2006 10:45 PM
> To: Hadriel Kaplan; Michael Hammer (mhammer); [email-masked]

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 14 Apr 2006 13:11:34 -0400

>the casethat they have physical/co-location security so TLS is not

I wonder about that.

Seems to me there are a few cases of interest:
1. Peering is conducted in a closed environment, where you have no L3
connectivity unless you are allowed L5/L7 connectivity

2. Peering is conducted in an open environment where you have open L3, and
need restricted L5/L7

3. Peering is conducted in a closed L3 environment, but needs authorization
for L5/L7

In case 1, you don't need any form of authentication.  If you can connect,
you are allowed to peer.

In case 2, TLS is appropriate

In case 3, you want some form of authorization, but don't need privacy or
integrity protection.  What you need is authorization.  TLS mutual
authentication would be very appropriate.  You don't have to engage
encryption or MAC processing, just the authentication part.  

I think the registration mechanisms discussed are a misuse of SIP.
Registration in 3261 is described as UAC to Registrar, not proxy to proxy.

There are also problems with using the Proxy-Authenticate process defined in
section 22.4.  Section 22 of 3261 discusses User to User and User to proxy
authentication.  Proxy to proxy is noticeably not discussed in 3261.
RFC3603 gives some private extensions for proxy to proxy within PacketCable
DCS, but these are not generalizable to SPEERMINT.

Thus, I suggest we consider using TLS mutual authentication when peers need
to authenticate with one another.