Hi Gene,
Gene Thurston wrote:
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 meant to imply that RSA not DSA is the norm.
>
> > 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.
A template contains biometric data, which as you suggest is a string of
octets. A template carries this data along with optional information
about or related to the data. This may include a time stamp, the type
of biometric, the quality of the data, etc. This collection of information
is a BiometricObject in XCBF, and a value of this type may look like:
<BiometricObject>
<biometricHeader>
<version> 0 </version>
<recordType> <id> 4 </id> </recordType>
<dataType> <processed/> </dataType>
<purpose> <audit/> </purpose>
<quality> -1 </quality>
<validityPeriod>
<notBefore> 1980.10.4 </notBefore>
<notAfter> 2003.10.3.23.59.59 </notAfter>
</validityPeriod>
<format>
<formatOwner>
<oid> 2.23.42.9.10.4.2 </oid>
</formatOwner>
</format>
</biometricHeader>
<biometricData> 0A0B0C0D </biometricData>
</BiometricObject>
In practice, biometric objects always appear in sets that may be signed
or encrypted or both. And the unit of transfer in XCBF involves sets of
these sets.
Transfer may occur as a binary encoding of these XML markup values
that have been Base64 armored, or they may occur as XML markup as
shown here.
The certificates used, the names of cryptographic keys, the algorithms and
parameters and the like are encapsulated in the biometric token and it is
treated for the purposes of WSS as an opaque object, just like we would
treat an X.509 certificate - it is to WSS a "foreign" object.
(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.
Exactly.
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?
This is all a part of the template information carried as a BiometricObject.
In
XCBF the biometric type is called a record type and the <format> field
can
carry an indication of the processing algorithm and matching rules (and device
identifier and other information bound to the biometric by a signature) needed
by a Biometric Service Provider who will make use of the biometric data.
(2) Another alternative would be to use the biometric
template INSTEAD
of a password. If we took this route, then I would
recommend we
Biometric are used in this way in some environments. But in our
networked situation, they are really only appropriate for multifactor
use - here, something you are (biometric) coupled with something
you know (password). If the password is bound to a token device,
or perhaps a key that you possess, then something you have is
added to the mix and you get three factor authentication. But the
minimum I think that we should allow is two factor.
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
This is true for most but not all biometric types.
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.
All of the required cryptographic protection is handled within the XCBF blob,
much the same as X.509 certificates are self contained. This blob would be
given to a Biometric Service Provider who would perform all necessary
cryptographic and biometric processing. In this sense then, the details can
be isolated from WSS proper, much as the details of PKI can be isolated
for our purposes.
> > 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.
Yes. Now another case that I would wish to pursue down the road would
involve the ability to do a remote biometric match-on-card. But there is
no
standard at this time that I am aware of that covers this case. So this is
very
much in some future - not relevant today.
> 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.
The SC approach was used most effectively in the UBL TC. It makes
it possible to bring together resources where there is common interest
and to insulate the larger group from the details of a narrow, well defined
piece of work. The SC can discuss and refine issues among themselves
then report suggested resolutions back to the TC for actual approval.
Phil
>
> Phil
>
>
> Thanks, again,
>
> - Gene -
>
>
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
