Subject: [drinks] security considerations...

From: "Ali, Syed Wasim" <[email-masked]>
Date: Fri, 26 Aug 2011 00:03:30 -0400

Hi,

I am proposing addition of the following to the security considerations section.

Thoughts?

For high visibility implementation, there may be additional concerns regarding repudiation issues and SPPP implementations may need to provide proof that the message did not change since leaving the sender and to further validate the sender of SPPP message. Therefore, the SPPP implementations SHOULD provide support for XML Signature standard to manage this concern.

It is not uncommon for the logging systems to document on-the-wire messages for various purposes, such as, debug, audit, and tracking. At the minimum, the various support and administration staff will have access to these logs. Also, if an unprivileged user gains access to the SPPP deployments and/or support systems, it will have access to the information that is potentially deemed confidential. To manage information disclosure concerns beyond the transport level, the SPPP implementations SHOULD support XML Encryption standard to facilitate information hiding at the message level.

Anti-replay protection ensures that a given SPPP object is not played back at a later time and affect the integrity of the system. SPPP protocol provides at least two mechanisms to aid the implementers in this regard: client transaction identifier and embedded create timestamps for the SPPP objects. The client transaction identifier allows the sender to correlate the response with the request and verify that the transaction was returned from the intended SPPP implementation. The timestamps in the modify SPPP objects that reflect the time it was created MUST reflect the current time and the SPPP implementations SHOULD test the time values to make sure that they are not replayed inadvertently, or with a malicious intent.
<<<<<

Thanks,

-Syed

-Syed

---

From: Dean Willis <[email-masked]>
Date: Thu, 25 Aug 2011 23:53:49 -0500

On 8/25/11 11:03 PM, Ali, Syed Wasim wrote:
> For high visibility implementation, there may be additional concerns
> regarding repudiation issues and SPPP implementations may need to
> provide proof that the message did not change since leaving the sender
> and to further validate the sender of SPPP message. Therefore, the SPPP
> implementations SHOULD provide support for XML Signature standard to
> manage this concern.

This further restricts protocol bindings to be XML-based instead of, for 
example, RESTful. Given that we're already deeply tied to XML at the 
"architecture" document that we're calling a protocol document (rather 
than in a transport binding, where I would personally have preferred to 
map to XML) I suppose this doesn't matter. But it is sort of running 
salt into the wound.

Also needs a reference to the XML Signature standard.

And most likely, to use XML Signature in an interoperable way, we're 
going to need to talk a lot more about what is being signed, what it is 
being signed with, and what the assumptions about key management are.

> It is not uncommon for the logging systems to document on-the-wire
> messages for various purposes, such as, debug, audit, and tracking. At
> the minimum, the various support and administration staff will have
> access to these logs. Also, if an unprivileged user gains access to the
> SPPP deployments and/or support systems, it will have access to the
> information that is potentially deemed confidential. To manage
> information disclosure concerns beyond the transport level, the SPPP
> implementations SHOULD support XML Encryption standard to facilitate
> information hiding at the message level.

As above WRT XML-centric design. Also needs a reference to XML 
Encryption standard.

And most likely, to use XML Encryption in an interoperable way, we're 
going to need to talk a lot more about what is being encrypted, what it 
is being encrypted with, and what the assumptions about key management are.

> Anti-replay protection ensures that a given SPPP object is not played
> back at a later time and affect the integrity of the system. SPPP
> protocol provides at least two mechanisms to aid the implementers in
> this regard: client transaction identifier and embedded create

Rather than "create" (verb form), you probably want "creation" 
(adjective form) as it modifies the following "timestamps" noun. That or 
I'm reading the sentence wrongly.

> timestamps for the SPPP objects. The client transaction identifier
> allows the sender to correlate the response with the request and verify
> that the transaction was returned from the intended SPPP implementation.
> The timestamps in the modify SPPP objects that reflect the time it was

above sentence does not parse -- "in the modify"? Did you want 
"modified"? How does mDate play against cDate here?

> created MUST reflect the current time and the SPPP implementations
> SHOULD test the time values to make sure that they are not replayed
> inadvertently, or with a malicious intent.

Many SPPP transactions don't carry time stamps and as far as I know none 
have "expiry" periods. It appears that we therefore don't have the data 
needed for antireplay. We make can use mTime to let a client detect if 
someone has changed an object. Wouldn't eTags be a better solution for 
detecting changes?

This also raises the question of absolute time-synchronization between 
server and client that has been problematic in some protocols. If we 
require time-synch, we need to say so, describe the parameters thereof 
(like how much drift is OK), and talk about what can happen if it gets 
out-of-synch.

--
Dean

---

From: "Cartwright, Ken" <[email-masked]>
Date: Fri, 26 Aug 2011 09:34:09 -0400

Hi Syed,

Thanks for this.  A few comments.

1) I think the new items are the last three of the six paragraphs in Security considerations.
2) For paragraph 4, I think this "should" could be changed to a "may".  SSL and certs address the "not been tampered with" and "the source is known to be who they say they are" requirements.  XML signatures are more appropriate for environments where SSL and certs are not being used.
3) For paragraph 5, this seems to be development guidance for how implementers can keep their internally managed data secure (after it has gotten into their systems).  I don't really see what this has to do with this protocol.  We should not be attempting to explain how to do that because the requirements for that will vary from deployment to deployment.  And even the use of XML encryption does not solve this problem.  And this paragraph is not enough to enable the use of XML Encryption in this protocol.  It does not even have a reference to the XML Encryption spec.  Lastly, the data managed by this protocol is not highly secret (i.e. there are no CCs, SSNs, person's names, company names, etc, etc).  At a minimum the "should" should be made a "may".
4) I'm not sure I see a meaningful risk here related to replays (aka idempotence).  A repeat of an "add" will not add the object twice, so it will do no harm.  A repeat of a delete will do no harm.  A repeat of a mod will do no harm.  A repeat of a route offer will do no harm.  As a result, I'm not sure what is meant by " The Timestamps in the modify SPPP objects that reflect the time it was created MUST reflect the current time and the SPPP implementations SHOULD test the time values to make sure that they are not replayed inadvertently, or with a malicious intent."

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ali, Syed Wasim
Sent: Friday, August 26, 2011 12:04 AM
To: [email-masked]
Subject: [drinks] security considerations...

Hi,

Thoughts?

Thanks,

-Syed

-Syed

________________________________
This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Services.
Any unauthorised review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

---

From: "Jeremy Barkan \(Digitalshtick\)" <[email-masked]>
Date: Fri, 26 Aug 2011 17:58:14 +0300

Hi Syed & Ken,

Some thoughts - 

Re: Repudiation and Signed SPPP Messages

For clarity - is what you are proposing to sign the SPPP command ?  I'm
distinguishing between message integrity  tampering on the wire - in
transport [ as Ken refers to SSL ] - which could be made a requirement of
the transport [ such as HTTPS ]  - and end to end message integrity which
would mean having clients sign commands and registries sign responses and
require a trust system and certificate authorities and so on.

In non-repudiation per-se - you would a signed command as a binding proof
that a client issued a command to a server - so the command would be - "add
a record route" signed SPPP_Provider_3.

Similarly - in route offers and in acceptance of route offers.

I think we should be sure this is a requirement before adding it to the
protocol - and if XML-SIG at the level of the SPPP Command is the right
place to do this.

Re: Encryption - I would also distinguish between the threats on the wire,
and the end-to-end threats. In the case of privacy - exposure of the a log
or audit trail could bypass all the authorization and visibility rules we
spoke about. That said - encrypting the SPPP Commands and having an
encrypted log or audit trail is a level of complexity.

That said - having a tamper-proof audit trail would certainly be a
best-practice, although I do not recall seeing other protocols where this is
required of the server.

Re: Replay attack - I agree with Ken's comment. I don't understand the
threat, other than a DOS type attack.  In fact - given that the protocol is
stateless and does not really have a session [ albeit commands can be
batched ] - we would need a way to construct unique client identifiers.

Best Regards and wishing all a good weekend

Jeremy

Jeremy Barkan

CTO

Digitalshtick

Tel: +972 2 6728069

Mobile: +972 54 6321603

Skype: jeremy_barkan

www.digitalshtick.com <http://www.digitalshtick.com/> 

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Cartwright, Ken
Sent: 26 August 2011 16:34
To: Ali, Syed Wasim; [email-masked]
Subject: Re: [drinks] security considerations...

Hi Syed,

1) I think the new items are the last three of the six paragraphs in
Security considerations.

2) For paragraph 4, I think this "should" could be changed to a "may".  SSL
and certs address the "not been tampered with" and "the source is known to
be who they say they are" requirements.  XML signatures are more appropriate
for environments where SSL and certs are not being used.

3) For paragraph 5, this seems to be development guidance for how
implementers can keep their internally managed data secure (after it has
gotten into their systems).  I don't really see what this has to do with
this protocol.  We should not be attempting to explain how to do that
because the requirements for that will vary from deployment to deployment.
And even the use of XML encryption does not solve this problem.  And this
paragraph is not enough to enable the use of XML Encryption in this
protocol.  It does not even have a reference to the XML Encryption spec.
Lastly, the data managed by this protocol is not highly secret (i.e. there
are no CCs, SSNs, person's names, company names, etc, etc).  At a minimum
the "should" should be made a "may".

4) I'm not sure I see a meaningful risk here related to replays (aka
idempotence).  A repeat of an "add" will not add the object twice, so it
will do no harm.  A repeat of a delete will do no harm.  A repeat of a mod
will do no harm.  A repeat of a route offer will do no harm.  As a result,
I'm not sure what is meant by " The Timestamps in the modify SPPP objects
that reflect the time it was created MUST reflect the current time and the
SPPP implementations SHOULD test the time values to make sure that they are
not replayed inadvertently, or with a malicious intent."

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ali, Syed Wasim
Sent: Friday, August 26, 2011 12:04 AM
To: [email-masked]
Subject: [drinks] security considerations...

Hi,

I am proposing addition of the following to the security considerations
section. 

Thoughts?

For high visibility implementation, there may be additional concerns
regarding repudiation issues and SPPP implementations may need to provide
proof that the message did not change since leaving the sender and to
further validate the sender of SPPP message. Therefore, the SPPP
implementations SHOULD provide support for XML Signature standard to manage
this concern.

It is not uncommon for the logging systems to document on-the-wire messages
for various purposes, such as, debug, audit, and tracking. At the minimum,
the various support and administration staff will have access to these logs.
Also, if an unprivileged user gains access to the SPPP deployments and/or
support systems, it will have access to the information that is potentially
deemed confidential. To manage information disclosure concerns beyond the
transport level, the SPPP implementations SHOULD support XML Encryption
standard to facilitate information hiding at the message level.

Anti-replay protection ensures that a given SPPP object is not played back
at a later time and affect the integrity of the system. SPPP protocol
provides at least two mechanisms to aid the implementers in this regard:
client transaction identifier and embedded create timestamps for the SPPP
objects. The client transaction identifier allows the sender to correlate
the response with the request and verify that the transaction was returned
from the intended SPPP implementation. The timestamps in the modify SPPP
objects that reflect the time it was created MUST reflect the current time
and the SPPP implementations SHOULD test the time values to make sure that
they are not replayed inadvertently, or with a malicious intent.

<<<<< 

Thanks,

-Syed

-Syed

  _____  

This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network
Services.
Any unauthorised review, use, disclosure or distribution is prohibited. If
you
are not the intended recipient, please contact the sender by reply e-mail
and destroy all copies of the original message.

---

From: "Cartwright, Ken" <[email-masked]>
Date: Fri, 26 Aug 2011 11:21:00 -0400

Hi Jeremy,

The protocol "musts" HTTPS and also "shoulds" certs based server and client auth.  Imo, the cert based server and client auth covers what you refer to as "end-to-end message integrity".  Iow, if you have used the cert to verify that the party on the other end is who you think they are then it's covered I believe.  And anything more than that I do not see as necessary (a "may" at best).

Ken

________________________________
From: Jeremy Barkan (Digitalshtick) [mailto:[email-masked]]
Sent: Friday, August 26, 2011 10:58 AM
To: Cartwright, Ken; 'Ali, Syed Wasim'; [email-masked]
Subject: RE: [drinks] security considerations...

Hi Syed & Ken,

Some thoughts -

Re: Repudiation and Signed SPPP Messages
For clarity - is what you are proposing to sign the SPPP command ?  I'm distinguishing between message integrity  tampering on the wire - in transport [ as Ken refers to SSL ] - which could be made a requirement of the transport [ such as HTTPS ]  - and end to end message integrity which would mean having clients sign commands and registries sign responses and require a trust system and certificate authorities and so on.
In non-repudiation per-se - you would a signed command as a binding proof that a client issued a command to a server - so the command would be - "add a record route" signed SPPP_Provider_3.
Similarly - in route offers and in acceptance of route offers.
I think we should be sure this is a requirement before adding it to the protocol - and if XML-SIG at the level of the SPPP Command is the right place to do this.

Re: Encryption - I would also distinguish between the threats on the wire, and the end-to-end threats. In the case of privacy - exposure of the a log or audit trail could bypass all the authorization and visibility rules we spoke about. That said - encrypting the SPPP Commands and having an encrypted log or audit trail is a level of complexity.
That said - having a tamper-proof audit trail would certainly be a best-practice, although I do not recall seeing other protocols where this is required of the server.

Re: Replay attack - I agree with Ken's comment. I don't understand the threat, other than a DOS type attack.  In fact - given that the protocol is stateless and does not really have a session [ albeit commands can be batched ] - we would need a way to construct unique client identifiers.

Jeremy

Jeremy Barkan

CTO
Digitalshtick
Tel: +972 2 6728069
Mobile: +972 54 6321603
Skype: jeremy_barkan
www.digitalshtick.com<http://www.digitalshtick.com/>

From: [email-masked] [mailto:[email-masked]] On Behalf Of Cartwright, Ken
Sent: 26 August 2011 16:34
To: Ali, Syed Wasim; [email-masked]
Subject: Re: [drinks] security considerations...

Hi Syed,

________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:%5bmailto:[email-masked]%5d> On Behalf Of Ali, Syed Wasim
Sent: Friday, August 26, 2011 12:04 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [drinks] security considerations...

Hi,

Thoughts?

Thanks,

-Syed

-Syed

---

From: Dean Willis <[email-masked]>
Date: Fri, 26 Aug 2011 15:38:04 -0500

On 8/26/11 10:21 AM, Cartwright, Ken wrote:
> Hi Jeremy,
>
> The protocol “musts” HTTPS and also “shoulds” certs based server and
> client auth. Imo, the cert based server and client auth covers what you
> refer to as “end-to-end message integrity”. Iow, if you have used the
> cert to verify that the party on the other end is who you think they are
> then it’s covered I believe. And anything more than that I do not see as
> necessary (a “may” at best).

Good points.

As we know from RFC 3552, the key here is deciding what the credible 
threat model is, then effectively using techniques to block the credible 
threats. For example, is having a server CPU that  has been designed by 
its manufacturer to leak our information a credible threat? Probably 
not. Is having somebody standing outside the office or in a switching 
junking sniffing our traffic a credible threat? Quite probably.

The goal here is to think like an attacker, and figure out where in the 
system the weak parts are and how to attack them, to document those 
attacks, and then explain how to defend against them.

We have "on the wire" interception threats, which (as Ken points out) 
are mostly handled by HTTPS.

But our confidential records could "leak" at the back end. For example, 
if an intruder has access to the transaction log, they could find out 
what transactions we had sent. Of course, if they have access to the 
transaction log, they  quite probably also have access to the server 
database, which would tell them a lot more. That's not something we can 
really defend against at the level of protocol we're using. At best, we 
can describe the risk (especially if there are any "special" risk 
factors to leaking our data) and remind implementor/users to apply 
appropriate measures to secure the back-end.

How about an HTTPS MITM? Perhaps rar A connects to what it thinks is the 
registry, but is actually an attacker. If A is not careful about 
evaluation of the certificate presented by the registry, then A could be 
tricked into authenticating with the attacker. Digest is reasonably good 
but imperfect at keeping the attacker from deducing A's password, so the 
attacker might then be able to initiate transactions on behalf of rar A 
(and all A's rants) to the registry. Consequently, we probably need to 
talk about how A should evaluate the cert presented by the registry. I'm 
not an expert on the references here. IS the sequence in Section 3.1 of 
RFC 28218 adequate as a reference, or do we need more discussion?

Note that RFC 4523 spends a lot of effort talking about certificate 
matching rules for LDAP, as RFC 5922 does for SIP. So it's not uncommon 
for an IETF spec to need more discussion on certificate matching.

We have client-identity impersonation threats, which we're currently 
relying on the use of a simple password authentication scheme to 
control. We assume that the password is unlikely to be intercepted "on 
the wire" since it is being used over HTTPS. But what if it leaks from 
either the client or server sides through a back-end process? For 
example, as a client, I've left the password on a sticky-note attached 
to my monitor, and the cleaning staff transmits it to the competitor who 
has bribed them to send copies of all sticky-notes attached to monitors.

Yes, we could use XML signing to make this harder, but we'd get the same 
benefit out of using a stronger authentication mechanism that uses a 
client-side cert.

What about the threat model where a legitimate client crafts 
transactions designed to interfere with the operation of other clients?
Assume we have rar A representing rant Alice. A protocol design or 
implementation error could easily let rar B inappropriately read, write, 
update, or insert faux records affecting rant Alice.

One can also envision cases where a rant-to-rar interface outside the 
scope of this protocol might be used by a malicious rant to "trick" the 
rar into doing something inappropriate. For example, what happens when 
rant Bob sends rar B a batch of updates and accidentally refers to 
himself as rant Alice? B might then recklessly send those changes to the 
registry, adversely affecting Alice (if the registry allows rar B to 
affect records for rant Alice). Hopefully we defend against this by 
permission masking, or in RFC 3552 terms applying an access control list 
to the records of rant Alice that precludes rar B from altering them.

But what if rants Alice and Bob are both legitimate clients of rar A? 
Our access list won't work. It becomes critical that A apply mechanisms, 
currently outside the control of SPPP, to verify that the transactions 
it submits on behalf of a rant affect only records relating to that 
rant. This is something we can't control at the SPPP level, but is a 
threat we can identify and warn the rars about.

On a related note, is there a special threat to offer validation? Can 
Charlie offer routes to Alice that appear to be from her preferred 
partner Bob, but terminate on Charlie instead, thereby stealing revenue 
from Bob? Where there's a financial incentive, there's a lot of risk of 
an attack. So we need to identify areas where there's a strong financial 
incentive, and where possible, defend those points strongly.

Do we need non-repudiation? Consider the case where rant Alice sends rar 
A some updates, and A dutifully pushes them into the registry using 
SPPP. These records are bad and they break something -- maybe Alice. 
Presume Alice then sues the registry operator for the resulting 
catastrophe. How does the registry (or the intervening rar) prove that 
the records came from Alice and not an administrative error or an 
attacker that was negligently admitted by the registry or the rar?
Since at the very best our database shows that the transaction was 
authenticated to rar A (and that such authentication could be in-error), 
it's hard to prove that the fault was Alice's. We can't even ask Alice 
to XML-sign the incoming data, since she's using a non-SPPP interface to 
talk to A.

A similar attack could be launched by rar A. If we had XML signatures by 
A on the records, then we could "prove" that A had submitted the 
erroneous data, not somebody else (for whom the registry is presumably 
responsible). Is this an important enough threat that we want to think 
about it in our protocol? If so, then we can't just say "use XML 
signatures". We'd have to talk about the certification process used to 
support the signatures. The same complexity applies to any more advanced 
authentication techniques.

Does it make sense for rars to encrypt all data (XML Encryption) before 
submitting to the registry over HTTPS, such that the records are 
encrypted even in the database? Probably not, because then the registry 
would not be able to operate on the records to do things like matching 
route group offers. Nor would it be able to construct an ENUM 
presentation from the data. While it might be feasible for the registry 
to also have all the keys needed to decrypt the records, there's no real 
reason to presume that this will protect the back-end process. Since 
matching operations require decrypting the data, many logging operations 
are going to happen on decrypted data, and if an intruder has access 
into the database, there's no reason to assume the intruder couldn't 
also steal the decryption key(s).

--
Dean

---

From: "Ali, Syed Wasim" <[email-masked]>
Date: Fri, 26 Aug 2011 17:15:41 -0400

Dean,

Thanks for the reply. Please, see comments inline.

>map to XML) I suppose this doesn't matter. But it is sort of running

RESTful paradigm doesn't prohibit use of XML content. I don't understand
your comment.

XML Signature standard applies to XML content. And yes, SPPP relies on XML
to describe the protocol structure. This is partly because we are trying
to stay in line with current industry practices. This is not an add choice
by any measure. Not sure what I mentioned here makes things worse than the
status quo. For systems that cannot consume XML, there are ways to tackle
this is a standards-based fashion. Granted that signing a message for
integrity protection at the message level gets in the way of
transformations, but that is a different discussion.

>Also needs a reference to the XML Signature standard.

Yes. This would be part of the final edit.

>being signed with, and what the assumptions about key management are.

The goal here was to clarify to the consumer of the SPPP document that if
message integrity protection is desirable then the standards-based
approach. RFC3552 section 2.1.2 recognizes that there is more to data
integrity beyond the transport layer protection. And yes, when and if
someone needs to exercise this requirement, they will "talk a lot more
about" it. 

>> the minimum, the various support a nd administration staff will have

Yes, the reference to the XML Encryption standard is needed.

>> this regard: client transaction identifier and embedded create

The reference to the create and modify data in this context was incorrect.
It serves an entirely different purpose and I shall rectify the text.

-Syed

---

From: Dean Willis <[email-masked]>
Date: Fri, 26 Aug 2011 18:45:26 -0500

On 8/26/11 4:15 PM, Ali, Syed Wasim wrote:
> On 8/26/11 12:53 AM, "Dean Willis"<[email-masked]>  wrote:
>

REST uses the URL to indicate the service being performed, and generally 
splits the parameters (which might be XML) up into separate URL 
parameters or form-values in the request. Our XML encoding wraps the 
service designator and everything else into one XML document that then 
has to be parsed at the receiving end. This makes it very hard to 
explicitly map the protocol onto a RESTful model.

Even relying on HTTP Auth as part of our resource identification is 
un-RESTful. SO the registrar identifier should be one of the parameters, 
not something we get from the auth layer. But Ken is telling me that the 
registar identifier is completely out-of-scope for the protocol.

XML signing/encrypting the whole submitted document in one block makes 
it even further distant from REST.

--
Dean

---

From: "Cartwright, Ken" <[email-masked]>
Date: Mon, 29 Aug 2011 09:30:34 -0400

Inline.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean Willis
Sent: Friday, August 26, 2011 7:45 PM
To: Ali, Syed Wasim
Cc: [email-masked]
Subject: Re: [drinks] security considerations...

KJC:  Absolutely, which is part of what I presented in Sweden.

KJC:  You exaggerate.  What I said was that two of the parties involved in specifying the protocol wanted to remove the registrar ID from the protocol XSD objects, as the last change to the protocol XSD.  And because having the registrar ID in there was not strictly necessary I agreed to that change as well.  And I also told you that in order to add it back we would need to get those parties to agree to do so.  But just to prevent thrashing, adding it back in would require a very solid justification at this point.  Furthermore I explained that the identity of the registrar is now effectively embedded within (i.e. determined from) authentication credentials.

--
Dean
_______________________________________________
drinks mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/drinks

---

From: "Ali, Syed Wasim" <[email-masked]>
Date: Mon, 29 Aug 2011 12:22:33 -0400

Please see inline:

>explicitly map the protocol onto a RESTful model.

We discussed RESTful or "not" before. In fact, we can do SOAP wrapper or
REST, not both. This has been addressed before...

>registar identifier is completely out-of-scope for the protocol.

See earlier comment. Since RESTful doesn't apply in the SPPP document,
this comment is irrelevant at best. This discussion is out of scope unless
there is a requirement to ditch SOAP and do REST. Also, you probably mean
"registrant" and not "registrar". The resource belongs to registrant, not
the registrar.

---

From: "Ali, Syed Wasim" <[email-masked]>
Date: Mon, 29 Aug 2011 13:38:22 -0400

Hi Ken,

Thanks for the feedback. Please see comments inline:

From: "Cartwright, Ken" <[email-masked]<mailto:[email-masked]>>
Date: Fri, 26 Aug 2011 09:34:09 -0400
To: Neustar <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: security considerations...

Hi Syed,

[SYED] Yes.

2) For paragraph 4, I think this "should" could be changed to a "may".  SSL and certs address the "not been tampered with" and "the source is known to be who they say they are" requirements.  XML signatures are more appropriate for environments where SSL and certs are not being used.
[SYED] You are right, SSL addresses end to end connection security. I am not sure if the last statement is correct. There are protocols that not only use both, but may use multiple signatures within a message (top level message integrity + embedded token protection that gets stored in the backend and may be passed on to other actors—see SAML). Repudiation is required when there is a concern that the sender may refuse to take ownership of the transaction, often much later in time. As an example, the plain text message is not enough to demonstrate proof of transaction during the billing and settlement phase since there is not enough proof that it hasn't changed since it was received over supposedly a mTLS connection. This may not be an issue for all SPPP implementations, but this situation begs clarification. Also, I am fine with a change from "SHOULD" to "MAY".

3) For paragraph 5, this seems to be development guidance for how implementers can keep their internally managed data secure (after it has gotten into their systems).  I don’t really see what this has to do with this protocol.  We should not be attempting to explain how to do that because the requirements for that will vary from deployment to deployment.  And even the use of XML encryption does not solve this problem.  And this paragraph is not enough to enable the use of XML Encryption in this protocol.  It does not even have a reference to the XML Encryption spec.  Lastly, the data managed by this protocol is not highly secret (i.e. there are no CCs, SSNs, person's names, company names, etc, etc).  At a minimum the "should" should be made a "may".
[SYED] Here the intent is to follow RFC3552: "to encourage document authors to consider security in their designs and to inform the reader of relevant security issues". This may not be an issue for all implementations, but deserves mention for complete coverage. I mentioned the standards-based choices in the text and will include the reference in the document edits. And yes, "SHOULD" can be changed to "MAY".

4) I'm not sure I see a meaningful risk here related to replays (aka idempotence).  A repeat of an "add" will not add the object twice, so it will do no harm.  A repeat of a delete will do no harm.  A repeat of a mod will do no harm.  A repeat of a route offer will do no harm.
[SYED] (1) In the sequence that you mentioned here, there may not be an issue, but a delayed replay of a message could have unintended results. Let's see how the use of "clientTransId" helps in this regard. Registrar sends the AddDestGrpRqstType request and deliberately includes a "clientTransId" value of "txid-1342134-1324-34" in the request. The correct response from the server will include same "clientTransId" and helps bring closure to this transaction. Any future replay of the SPPP server response will be harmless if the client is not reusing the transaction id and is actively testing the value to weed out bad messages. If the "clientTransId" is not included in the original client request, and it doesn't have to be since it is optional, a response such as,

      <?xml version="1.0" encoding="UTF-8"?>
      <spppUpdateResponse
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd"
       xmlns="urn:ietf:params:xml:ns:sppp:base:1">
        <serverTransId>tx_id_12346</serverTransId>
        <overallResult>
          <code>1000</code>
          <msg>success</msg>
        </overallResult>
      </spppUpdateResponse>

can be construed as a valid response to the original request when this could very well be a replay of a message that was intercepted by a malicious user earlier, and not the conclusive response for the request from SPPP server. For more on the replay attacks, please see RFC3552: 3.3.1. This is not all that hard to imagine since the mTLS session is between two end points when in fact a SSL proxy may be in play to perform mTLS handshake creating an illusion of a "secure" environment. Now, this may appear far fetched to some, then again, the proposed text is there for the "security considerations" section and helps the consumers of SPPP get the full picture.

As a result, I'm not sure what is meant by " The Timestamps in the modify SPPP objects that reflect the time it was created MUST reflect the current time and the SPPP implementations SHOULD test the time values to make sure that they are not replayed inadvertently, or with a malicious intent."
[SYED] Right. I was recalling things on top of my head and confused the matters with a couple of other things I am actively engaged in. This text should be discarded.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Ali, Syed Wasim

Hi,

Thoughts?

Thanks,

-Syed

-Syed

---

From: "Ali, Syed Wasim" <[email-masked]>
Date: Mon, 29 Aug 2011 16:20:25 -0400

Good thoughts. Please see inline:

On 8/26/11 4:38 PM, "Dean Willis" <[email-masked]> wrote:

>> The protocol ³musts² HTTPS and also ³shoulds² certs based server and
>> refer to as ³end-to-end message integrity². Iow, if you have used the
>> then it¹s covered I believe. And anything more than that I do not see as
>> necessary (a ³may² at best).
>
>Good points.
>
[SYED] Yes.

>appropriate measures to secure the back-end.
[SYED] How to "secure the back-end" is covered by local IT Policy. Since
this doesn't affect SPPP protocol messages, I don't think this belongs to
the SPPP threat model.

>RFC 28218 adequate as a reference, or do we need more discussion?
[SYED] "how A should evaluate the cert presented by the registry" refers
to implementation details that, specially if covered by other RFCs, should
not be repeated again here in the SPPP doc.

>for an IETF spec to need more discussion on certificate matching.
[SYED] Relevant RFCs should be included in the "Informative References"
section. Perhaps this particular section can be reviewed in the upcoming
interim. Sumanth?

>benefit out of using a stronger authentication mechanism that uses a
[SYED] At the minimum, this belongs to the transport layer. Though there
may be other RFC/standard that describes how to manage these concerns.

>update, or insert faux records affecting rant Alice.
[SYED] "implementation error" is beyond SPPP spec. Quality Assurance
should catch these errors.

>to the records of rant Alice that precludes rar B from altering them.
[SYED] As you noted, it is "outside the scope of this protocol". If "B
might then **recklessly** send those changes to registry" ... (1) It is an
implementation error on the client side. (2) If it escapes the
authorization checks on the registry, these issues will be caught by way
of bad resolution errors and/or audit/tracking reports. The only thing I
can think of warning the implementers is against bad implementation and
better quality assurance. Not sure if this belongs in the security
considerations section.

>threat we can identify and warn the rars about.
[SYED] "can't control at the SPPP level", and this amounts to
implementation guidance.

>incentive, and where possible, defend those points strongly.
[SYED] SPPP is a provisioning protocol and I would prefer to not address
business intelligence concerns with it.

>to XML-sign the incoming data, since she's using a non-SPPP interface to
[SYED] This is what I proposed as well. And yes, this relates to SPPP
objects and, in my opinion, belongs to the security considerations section.

>encrypted even in the database?
[SYED] Depends on the information disclosure policy that the "rars" must
adhere to. If there is concern that the data may be exposed to unintended
actors before (or after) the registry implementation has an opportunity to
munch it, then it is not that far-fetched an idea. Also, it is likely that
parts of the SPPP message are encrypted, and not the whole message.

>Probably not, because then the registry
[SYED] There are a lot of assumptions here that help construct one way to
consume data. Most well-known database products enumerate a strategy to
store encrypted data and key managemement to encrypt/decrypt it, as well
as an elaborate song and dance for the app layer to access it. I don't
think this level of detail belongs into the SPPP security considerations.
The proposed text in the original message of this thread covers the
encryption needs and the related standard that may be used to leverage it.

---

From: Dean Willis <[email-masked]>
Date: Tue, 30 Aug 2011 18:26:19 -0500

> REST, not both. This has been addressed before...

If the data model were really separated from the transport, then we 
could do a REST binding or a SOAP binding, or a JDBC binding, or am 
XMLRPC binding, or whatever.

> "registrant" and not "registrar". The resource belongs to registrant, not

Not according to what I think Ken is explaining to me. I think Ken is 
saying that the only authenticated party is the registrar, and that the 
registrar makes all requests on behalf of the registrant. Therefore it's 
the registrar who "owns", meaning "controls changes to" the data.

But since we lost rarId from the schema, we can't really track which 
registrar put the data there unless we have another object-registrar 
mapping "outside" the protocol. I suspect this can lead to all sort of 
interesting data-access and update conflicts when multiple registrars 
are handling a given registrant.

--
dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 30 Aug 2011 18:35:09 -0500

> not be repeated again here in the SPPP doc.

Actually, there are a lot of choices about how a client could interpret 
the cert.

RFC 2818 section 3.1 introduces the basic concept, and references RFC 
2459 for matching.

Are these mechanisms adequate for our usage?

> may be other RFC/standard that describes how to manage these concerns.

Ok, that argues XML signing should not be included at a SHOULD level.

> should catch these errors.

However, there is a requirement that the implementation check the 
authenticated (but unspecified) rar identity against something 
"currently unspecified" in making a check. This requires more guidance 
than saying "just authenticate something" in the protocol spec.

If we want client A to work with server B, we at least need rar 
identifier validation rules, need to know what charset they're in, and 
so on.

--
Dean

---

From: "Cartwright, Ken" <[email-masked]>
Date: Wed, 31 Aug 2011 09:53:31 -0400

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean Willis
Sent: Tuesday, August 30, 2011 7:26 PM
To: Ali, Syed Wasim
Cc: [email-masked]
Subject: Re: [drinks] security considerations...

KJC4:  Not correct.  ReST is not a transport.  If ReST were just a transport then there would be no problem creating a great ReST transport specification for SPPP.  SPPP as specified will work nicely over vanilla TCP, vanilla HTTP, beep, RPCs, files, and of course SOAP (and others).  But it will of course not elegantly fit with IPC techniques and technologies that want the data structures and operations and operation responses structured and defined in a specific manner, as is the case with ReST, CORBA, RMI and others.  If that was a requirement from the get go (more than 2 years ago at this point I think) then we should have stated it.  But it was not.  This discussion has been well worn and documented it.

KJC:  Not correct, and not relevant.  The concept of "ownership" here is too vague to be valuable here.  You continue to have difficulty with the concept of registrar and registrant.

--
dean

---

From: Dean Willis <[email-masked]>
Date: Wed, 31 Aug 2011 10:59:34 -0500

On 8/31/11 8:53 AM, Cartwright, Ken wrote:

>> Not according to what I think Ken is explaining to me. I think Ken
>> is saying that the only authenticated party is the registrar, and
>> that the registrar makes all requests on behalf of the registrant.
>> Therefore it's the registrar who "owns", meaning "controls changes
>> to" the data.

>
> KJC:  Not correct, and not relevant.  The concept of "ownership" here
> is too vague to be valuable here.  You continue to have difficulty
> with the concept of registrar and registrant.

Well apparently, Ken, I'm stupid. Quite possibly a lot of people who are
going to read this spec are almost as stupid as I am. The protocol
authors have to find a way to explain these simple concepts to us even 
simpler readers.

So, how does a client anticipate whether or not it should have  access
to a given record on a server when we can't say whether access is
controlled by the username in the digest auth's relationship to any
specific element or set of elements in the data schema?

--
Dean

---

From: "Cartwright, Ken" <[email-masked]>
Date: Wed, 31 Aug 2011 12:10:05 -0400

See response to your other email.  The term "owner" is not relevant because it is not defined.  We need to use registrar (or at least SPPP client) and registrant so that we know what we are talking about.  And we _can_ say whether access is controlled by the authentication credentials of the registrar, they of course are.  See my response to your other email.

Ken

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Wednesday, August 31, 2011 12:00 PM
To: Cartwright, Ken
Cc: Ali, Syed Wasim; [email-masked]
Subject: Re: [drinks] security considerations...

--
Dean

---

From: "Cartwright, Ken" <[email-masked]>
Date: Wed, 31 Aug 2011 12:44:42 -0400

And btw, you're definitely not what you called yourself.

Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Cartwright, Ken
Sent: Wednesday, August 31, 2011 12:10 PM
To: Dean Willis
Cc: [email-masked]
Subject: Re: [drinks] security considerations...

Ken

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Wednesday, August 31, 2011 12:00 PM
To: Cartwright, Ken
Cc: Ali, Syed Wasim; [email-masked]
Subject: Re: [drinks] security considerations...

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Wed, 31 Aug 2011 11:47:14 -0500

On 8/31/11 11:10 AM, Cartwright, Ken wrote:
> See response to your other email.  The term "owner" is not relevant
> because it is not defined.  We need to use registrar (or at least
> SPPP client) and registrant so that we know what we are talking
> about.  And we _can_ say whether access is controlled by the
> authentication credentials of the registrar, they of course are.  See
> my response to your other email.

Ok, who is the authenticated actor that potentially is authorized to 
delete or update an existing object? I currently believe that actor to 
be the "registrar".

The "registrant" is only a passive actor at best, or more properly a 
non-actor. I now believe rant is merely an attribute of the object.

So, action authorization decisions are made on an object, under locally 
policy, based on the authenticated rar of the request.

However, "rant" is what we store in the objects now, according to the 
current schema. We don't store "rar".

So somewhere OpenSPP needs a table that says, for a given rant, whether 
or not a specific rar has action-rights on records tagged with that rant.

The problem with this approach is that I think (based on earlier email) 
that we have a use case where this is insufficient for policy to make a 
determination.

Here's the case:

Rant Alice uses rars A and B. Some of the rant Alice records in the 
database were added by rar A. Some were added by rar B. A MUST be able 
to delete/update records that were initially added by A, but MUST NOT be 
able to delete/update records that were added by B.

To handle this case, we need to know which records were added by A, and 
which by B, both of which were acting on behalf of rant Alice. The 
easiest way to do this is to add rar back into the schema for BasicObjType.

Another alternative would be to have yet another table that relates each 
object to a locally-defined rar identifier. This is a lot more code, and 
an expensive "join" at run-time. It's much easier to add rar to the schema.

--
Dean

---

From: "Cartwright, Ken" <[email-masked]>
Date: Wed, 31 Aug 2011 13:00:41 -0400

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Wednesday, August 31, 2011 12:47 PM
To: Cartwright, Ken
Cc: Ali, Syed Wasim; [email-masked]
Subject: Re: [drinks] security considerations...

KJC:  Correct.

KJC:  Yes, and based on whether that rar has been authorized to manage and/or view objects of the given registrant.

KJC:  Not correct.  The protocol does not specify everything that is "stored".  SPPP does not define the DB schema.  You are free to store anything additional that you want.  In my implementation, regardless of what is in the protocol, I would store/track the rar that created each individual object.  And I would do this for multiple reasons, my authorization policies being one of the main ones.

KJC:  Yes.  Inside the implementation DB schema that needs to exist.

Here's the case:

KJC:  Ok, that is an authorization policy that your SPPP implementation has decided that it wants to support.  Fine, I'm following you.

To handle this case, we need to know which records were added by A, and
which by B, both of which were acting on behalf of rant Alice.

KJC:  Correct.

The easiest way to do this is to add rar back into the schema for BasicObjType.

KJC:  Not so.  As stated above, the internal implementation needs to keep track of the registrar that created each object.  This has nothing to do with whether or not the registrar ID is passed as an object level element over theprotocol.

KJC:  No, that is not a lot more code.  You would have to store this rar ID under either approach (the rar ID in the protocol objects approach or the rar ID not in the protocol objects approach).  It is also not _required_ that the rarID that created an object be in a separate table.  IN fact most people would implement the rarID as a column of the object level table.

--
Dean

---

From: "Cartwright, Ken" <[email-masked]>
Date: Wed, 31 Aug 2011 16:28:03 -0400

Just to be clear, the spec already says these things, among others that speak directly to these items:

==============
<section anchor="authentication" title="Authentication">
        <t> All SPPP objects are associated with a registrant identifier. SPPP Clients
          provision SPPP objects on behalf of registrants.  An authenticated SPP Client is a registrar.  Therefore, the SPPP transport protocol MUST provide means for an SPPP server to authenticate an SPPP Client.  </t>
      </section>
================

================
      <section anchor="authorization" title="Authorization">
        <t>After successful authentication of the SPPP client as a registrar the registry performs authorization checks to determine if the registrar is authorized to act on behalf of the
          Registrant whose identifier is included in the SPPP request.  Refer to the Security Considerations section for further guidance.
        </t>
================

================
<section anchor="AuthenticationSessionManagement" title="Authentication and Session Management">

      <t>To achieve integrity andprivacy, conforming SPPP SOAP Clients and Servers MUST support SOAP over HTTP over TLS [<xref target="RFC5246"/>] as the secure transport mechanism.  This combination of HTTP and TLS is referred to as HTTPS.  And to accomplish authentication conformaing SOAP SPPP Clients and Servers MUST use HTTP Digest Authentication as defined in <xref target="RFC2617"/>.  As a result, the communication session is established through the initial HTTP connection setup, the digest authentication, and the TLS handshake.  When the HTTP connection is broken down, the communication session ends.</t>
    </section>
================

-----Original Message-----
From: Cartwright, Ken
Sent: Wednesday, August 31, 2011 1:01 PM
To: 'Dean Willis'
Cc: Ali, Syed Wasim; [email-masked]
Subject: RE: [drinks] security considerations...

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Wednesday, August 31, 2011 12:47 PM
To: Cartwright, Ken
Cc: Ali, Syed Wasim; [email-masked]
Subject: Re: [drinks] security considerations...

KJC:  Correct.

Here's the case:

KJC:  Correct.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 01 Sep 2011 00:54:27 -0500

On 8/31/11 12:00 PM, Cartwright, Ken wrote:

>
> KJC:  Not correct.  The protocol does not specify everything that is
> "stored".  SPPP does not define the DB schema.  You are free to
> store anything additional that you want.  In my implementation,
> regardless of what is in the protocol, I would store/track the rar
> that created each individual object.  And I would do this for
> multiple reasons, my authorization policies being one of the main
> ones.

The protocol does define the XSD which in turn defines OpenSPP's
programatically-generated inter-layer messaging, and in some cases the
actual database schema or parts thereof. Jeremy can add details on this; 
perhaps I'm off-base.

My gSOAP code definitely uses the data types defined programatically by 
gSOAP from the XSD.

I can certainly add parallel tables and messages, but it'sa a lot easier 
to piggyback on the tool's automatic plumbing when the auth_ID is in the 
payload.

--
Dean