Let me try this again. The
formatting of that last post got pretty garbled when I viewed it.
Here goes ...
Phil, thanks for you
comments. I have replied to some of
them below.
- Gene -
> -----Original Message-----
> From: Phillip H. Griffin [mailto:]
> Sent: Wednesday,
January 29, 2003 5:38 PM
> To: [OASIS WSS]
> Subject: RE: [wss] Web Services Security
Username Token Profile
>
>
> Gene Thurston wrote:
>
> > Thanks for the comments, Zahid.
> >
> > I agree that in practice SSL/TLS can,
and will often (usually?), be used
> > to provide these capabilities. I still believe, however, that we should
> > address cases where transport level security is either not an
option, or
> > for some other reason (application specific, perhaps) is not
being used.
> >
> > On the XML Signature spec, the use of other algorithms will
not break
> > our compliance with the standard. While the spec does define
> > identifiers for the DSA and RSA algorithms, it is intended to
be
> > extensible: "... the mechanism is extensible;
alternative algorithms may
> > be used by signature applications." This is analogous to the extensions
> > in the <ds:KeyInfo>
element, or the definition of Transform URIs, both
> > of which we are currently planning to use for SecurityTokenReferences.
> >
> >
> Taking a look at the certificates shipped with my browser, it's
would
> seem that RSA is dominant, not DSA. And PBE has long been a
> feature of the landscape.
>
> I guess I'd prefer to see RSA with SHA-1 required and RSA with MD5
> allowed. I don't think making DSA a requirement is particularly
realistic,
> just some politics. But generally, I'd
rather support extensibility and let
> the market decide. Different communities
will have different requirements.
If you are thinking that I am proposing we make certain public/private
key
signature algorithms REQUIRED or
OPTIONAL or anything like that, they you
misunderstood what I was
saying. It is the "XML
Signature Syntax and
Processing" specification (which was ratified as a standard by
both the W3C
and the IETF in February and
March of 2002) that has defined implementation
of DSA with SHA-1 as REQUIRED,
and RSA with SHA-1 as optional.
These are
the only two signature algorithms
that have URI identifiers defined for
them in that specification. However, the spec does state that other
algorithms CAN be used. Therefore, since WS-Security is based on
the XML
Signature spec, we cannot change the algorithm URI identifiers, but we
can
certainly create new identifiers
for other algorithms. Then, if we
go this
route, we could claim that these
algorithms MUST be supported to be being
compliant with our Username Token
Profile.
Of course, DSA and RSA are both public/private key signature
algorithms,
which won't work with any
Password Based Encryption scheme I know of ...
typically, PBE schemes are based
on generating a symmetric key (like a
triple-DES key, for instance)
from a password.
>
> > I actually have no problem with your idea of keeping the
existing
> > Username token profile (using nonce, creation timestame, digests, etc.),
> > and perhaps adding a second Username profile which would
provide the
> > binding with the message. This was, in fact, where my thinking was
> > headed, as well.
> >
> >
> I'd prefer to keep this all in one document rather than grow more
and
> more variations. And for me, adding a
biometric template as an optional
> parameter to a user name and password is
merely a wrinkle to the
> current work, not something that's worthy
of a separate document.
I appologize for not having
followed the biometric work closely. I guess
I don't quite understand what a "biometric template" is, nor
what the
ramifications of including it in
a Username token are, so I probably
should not comment on it. However, I'm stupid enough to try,
anyway, so
please be gentle on me if I'm WAY
off base.
So, my guess is that a biometric template would manifest itself as some
string of bytes (probably Base64
encoded) that would be interpretted as
a retina scan, finger print, or
such by the receiver of them. I see
two
options for including this data.
(1) If you merely propose to add that as an additional piece of
evidence
along with a password (or equivalent), then I don't see much
of a
problem with that. We could certainly create another
optional element
(say, <wsse:BiometricTemplate>)
under the <wsse:UsernameToken>
element, to hold this data. We might also define a "BiometricType"
attribute for it and define a couple of URIs
to represent the
standard biometrics, whatever those are. (Of course, leaving
it open
as an extensibility point for new, yet undefined,
biometrics.) This
attribute would give processors the needed information on
how to
"match" against the data. If we don't do that, then a
client might
send a retina scan to a service that tries to match it
against a
fingerprint, right?
(2) Another alternative would be to use the biometric template INSTEAD
of a
password. If we took this route, then I would recommend we
simply define a new "Type" for the <wsse:Password> element (say,
wsse:PasswordBiometric) that means
the data held in the <wsse:Password>
element is a biometric, and that the receiver needs to
"match" it
against a known biometric for the user named in the <wsse:Username>
element. (We would still have to deal with the different
types of
biometrics, though.) As for "matching" of biometric
data, I suspect
(big guess here) that the bytes do not need to be IDENTICAL,
but
rather each kind of biometric has some "matching"
algorithm that
produces a "close enough" sort of response. (Is
this right?) If that
is true, then two things come to mind. First, we could not
use the
digest mechanism to avoid sending the biometric in the clear
like we
do with passwords, since that depends on both the sender and
the
receiver having IDENTICAL bytes to start with. Second, for the same
reason, a PBE scheme could not be used. This is fine, it
just means
that we need to clearly point these things out in the
Security
Considerations
or Threat Model sections, if one chooses to use that
Type.
> > I do think, however, that we need to point out the security
issues in
> > the Threat Model, and at least state that secure transports
can
> > alleviate these concerns. (But, then again, if you are using a
secure
> > transport, why bother doing anything more than sending the
password in
> > clear text?)
> >
> >
> In a simple case this might be fine. But I can see a case for
sending an
> encrypted password to a recipient who
forwarded the value on to a
> trusted authority that determined whether
or not it was valid. A merchant
> - bank - customer transaction might need to do that, or a mobile
provider
> hooking up a customer to a merchant and bank could lead to this
sort of
> case.
Yes, I can see that. The idea of a trust-broker. Not direct trust
between the sender and receiver,
but use of an agreed upon third party.
> But my biggest concern right now is process. How do we move the
> Username document forward without excessive delay or impacting the
> Core work? Seems to me we need a SC to go off and do the work
> on this document, then bring it back and
try to sell the result to WSS
> proper.
Yes, I wonder the same thing w.r.t. *all* of
the token profile docs.
I think Phil mentioned that nobody had given him comments on his XrML,
X.509 docs, either. Perhaps
sub-committees is the way to go.
>
> Phil
>
>
> Thanks, again,
>
> - Gene -
>
>
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist
use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
