OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: FW: Comments on S2ML 0.8a


(Manually forwarded from the public comments list; I'll get the auto-forward
fixed soon.)

</karl>


-----Original Message-----
From: Nigel Edwards [mailto:nigel_edwards@hp.com]
Sent: Tuesday, January 09, 2001 6:38 PM
To: security-services-comment@lists.oasis-open.org
Subject: Comments on S2ML 0.8a


Hi,
I have a few comments and questions on the S2ML specification, version
0.8a

It seems to me that one of the major differences between 0.8a and 0.7a
is the introduction of scoped name assertions. Having only just read
0.7a, I was about to post a comment to the list concerning the need for
a stronger (cryptographic) coupling between entitlements and name
assertions. Clearly folks have started thinking the same thing as is
evidenced by the discussion of name theft and impersonation in the
introduction to section 4.2 I was going to suggest using public keys for
scoping (similar to the ideas in SPKI and SDSI). However, I struggled to
understand the text in 4.2.1. When I read the first paragraph it seemed
that the public key contained in the holder element was the issuer of
the name.

"The Holder element is introduced to provide within Name Assertions the
public key of the actor binding the name assertion to a payload using a
signature."

When I saw the phrase "the actor binding the name assertion", I assumed
that this was the issuer of the name assertion. Howver later text in
4.2.1 seem to suggest the holder field is the subject's public key. I am
confused. May be an example (or examples) would help resolve my
confusion?


It is quite possible that I misunderstand the usuage model (and/or
scoped assertions), but I still think the binding between various S2ML
fragments that might appear in different documents may not be strong
enough. I don't see problems arising, if these fragments are exchanged
through secure channels and contents never disclosed. However, if the
fragments are stored in documents for later use, I can see problems
arising. The example entitlement on page 13 in the beginning of section
4, shows a URI to link the entitlement to a name assertion. If somebody
manages to put a resource up with the same URI problems will arise. John
Linn mentioned IP and DNS level spoofing in his posting a few days ago
in the context of the HTTP binding for 0.7a. I think the above may be
vulnerable to similar problems.

I guess the general question is: is a URI sufficiently secure link for
compound assertions to work?

I am also worried about the linkage between AzResponse and AzRequest.
Again a URI is used to make the linkage, and the authorization question
is not repeated in the AzResponse. I think this could be made stronger
by including the question element from AzRequest in AzResponse.

The HTTP binding suggests using the hash of URI as the SenderIdentifer
and also AssertionIdentifier. Presumably this is because of a concern
over the length of URIs that might appear in headers. This seems to
assume a model of closely coupled sites: one in which the URIs of the
sending site are already known in advanced. Thus the hash is sufficient
to identify the sender to whom the request for the assertion needs to be
sent. Is it possible to support more dynamic scenarios in which sending
sites might not be known in advance?


I have one minor comment on some details.

On page 15 in section 4.3 the draft has a paragraph (quoted below) which
talks about separing out policy driven authentication components. I
couldn't really understand what this was trying to say. Again possibly
an example would help.

\begin{quote}
"For the case when the authentication service is invoked with public key
credentials, it MUST be
used to complement existing authentication protocols based on SSL or
document signature
verification (XML-SIG, S/MIME). The intent here is to separate out a
policy-driven component
of authentication into a separate service which can be shared, for
example, by all servers in a
web farm. It should not be viewed as a replacement for existing
authentication protocols."
\end{quote}

--
Nigel Edwards <nigel_edwards@hp.com>
tel: +44 (0) 117 3128490 (HP telnet 3128490)
Mobile/Cell: +44 (0) 7785 385 314
(From USA for Cell phone dial: 011-44-7785-385-314)
http://www.e-speak.hp.com/  http://www.hp.com/security/



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC