Bug#549936: breaks Shibboleth SPs: IdPs with KeyDescriptor use="signing" are broken

[Russ Allbery]

Faidon Liambotis  writes:
> Ferenc Wagner wrote:

>> Unfortunately Russ is the only DD in the team.  While I can help with
>> building packages for example, I'm not familiar with the security
>> procedure and can't upload either.

> OK, I'll handle this then, no problem.

Thank you so much for taking care of this.

-- 
Russ Allbery (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#549936: breaks Shibboleth SPs: IdPs with KeyDescriptor use="signing" are broken

[Faidon Liambotis]

Ferenc Wagner wrote:
> Unfortunately Russ is the only DD in the team.  While I can help with
> building packages for example, I'm not familiar with the security
> procedure and can't upload either.
OK, I'll handle this then, no problem.

Thanks,
Faidon



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#549936: breaks Shibboleth SPs: IdPs with KeyDescriptor use="signing" are broken

[Ferenc Wagner]

Faidon Liambotis  writes:

> Russ Allbery wrote:
>
>> Unfortunately, I'm both sick at the moment and my main computer is
>> dead with hardware failure, so I can't easily pursue it at the moment.
>> If someone else could, that would be great.  I had proposed the needed
>> changes for opensaml2 for the next stable update, but didn't get a reply
>> from the bug filed against release.debian.org.  In this case, it may be
>> best to ask t...@security.debian.org whether this update should instead
>> be done via the security queue since having the xmltooling fix without
>> the opensaml2 fix breaks the package.
> Sorry to hear that.
>
> Unfortunately, it's more complicated than that; Scott said in an
> off-list mail that due to some weird gcc inlining, shibboleth-sp2 would
> need to be rebuilt as well.
>
> I can handle the uploads but considering the magnitude of the changes,
> I'd prefer it if one of your comaintainers could handle the update or
> even wait for you to get better. If you insist, though, say so and I'll
> NMU in coordination with the security and release teams.

Unfortunately Russ is the only DD in the team.  While I can help with
building packages for example, I'm not familiar with the security
procedure and can't upload either.
-- 
Regards,
Feri.



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#549936: breaks Shibboleth SPs: IdPs with KeyDescriptor use="signing" are broken

[Scott Cantor]

Russ Allbery wrote on 2009-10-06:
>  Ack, I'm sorry.  I didn't realize that, so yes, that will indeed be a
> problem.

Sorry, I didn't understand that the fixes were being published separately, 
since I was reviewing them simultaneously.

As it stands, I see now that the advisory I wrote should make this issue 
clearer, since it also mistakenly implies the libraries can be fixed without 
rebuilding the SP.

> Unfortunately, I'm both sick at the moment and my main computer is
> dead with hardware failure, so I can't easily pursue it at the moment.
> If someone else could, that would be great.  I had proposed the needed
> changes for opensaml2 for the next stable update, but didn't get a reply
> from the bug filed against release.debian.org.  In this case, it may be
> best to ask t...@security.debian.org whether this update should instead
> be done via the security queue since having the xmltooling fix without
> the opensaml2 fix breaks the package.

Let me know if I can help.

-- Scott





--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#549936: breaks Shibboleth SPs: IdPs with KeyDescriptor use="signing" are broken

[Faidon Liambotis]

Russ Allbery wrote:
> Unfortunately, I'm both sick at the moment and my main computer is
> dead with hardware failure, so I can't easily pursue it at the moment.
> If someone else could, that would be great.  I had proposed the needed
> changes for opensaml2 for the next stable update, but didn't get a reply
> from the bug filed against release.debian.org.  In this case, it may be
> best to ask t...@security.debian.org whether this update should instead
> be done via the security queue since having the xmltooling fix without
> the opensaml2 fix breaks the package.
Sorry to hear that.

Unfortunately, it's more complicated than that; Scott said in an
off-list mail that due to some weird gcc inlining, shibboleth-sp2 would
need to be rebuilt as well.

I can handle the uploads but considering the magnitude of the changes,
I'd prefer it if one of your comaintainers could handle the update or
even wait for you to get better. If you insist, though, say so and I'll
NMU in coordination with the security and release teams.

Thanks,
Faidon



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#549936: breaks Shibboleth SPs: IdPs with KeyDescriptor use="signing" are broken

[Russ Allbery]

- "Scott Cantor"  wrote:

> I can confirm that this would break in the manner described if you
> patch
> xmltooling but NOT opensaml with the related fix.
> 
> It sounds like the opensaml patch and the SP rebuild didn't make it in
> yet.
> My apologies if this wasn't clear to the packagers or if I caused a
> problem
> with the way the fix was implemented.

Ack, I'm sorry.  I didn't realize that, so yes, that will indeed be a
problem.

Unfortunately, I'm both sick at the moment and my main computer is
dead with hardware failure, so I can't easily pursue it at the moment.
If someone else could, that would be great.  I had proposed the needed
changes for opensaml2 for the next stable update, but didn't get a reply
from the bug filed against release.debian.org.  In this case, it may be
best to ask t...@security.debian.org whether this update should instead
be done via the security queue since having the xmltooling fix without
the opensaml2 fix breaks the package.



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#549936: breaks Shibboleth SPs: IdPs with KeyDescriptor use="signing" are broken

[Scott Cantor]

Faidon Liambotis wrote on 2009-10-06:
> I think the problem is in the following change:
>* SECURITY: Correctly honor the "use" attribute of  SAML
>  metadata to honor restrictions to signing or encryption.  This is a
>  partial fix; the complete fix also requires a new version of the
>  OpenSAML library.
> (i.e. the getCredentialContext -> getCredentalContext)

I can confirm that this would break in the manner described if you patch
xmltooling but NOT opensaml with the related fix.

It sounds like the opensaml patch and the SP rebuild didn't make it in yet.
My apologies if this wasn't clear to the packagers or if I caused a problem
with the way the fix was implemented.
 
-- Scott





-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#549936: breaks Shibboleth SPs: IdPs with KeyDescriptor use="signing" are broken

[Faidon Liambotis]

Package: libxmltooling1
Version: 1.0-2+lenny1
Severity: grave

Hi,

(elevated severity because of unrelated breakage in a security update)

libxmltooling 1.0-2+lenny1 security upgrade breaks Shibboleth SPs for IdPs
which have use="signing" in their IDPSSODescriptor's KeyDescriptor.

I've verified that with Shibboleth 1.3 and Shibboleth 2.1.3 IdPs, both with
PKIX and Inline keys. All the tests are being done in the Greek Research and
Technology Network (GRNET)'s federation[1]. You can see the metadata here[2].

1: http://aai.grnet.gr/
2: http://aai.grnet.gr/metadata.xml

Downgrading the package to 1.0-2 and restarting shibd fixes the problem.
Removing use="signing" from the KeyDescriptor also fixes it, but replacing it
with use="encryption" isn't (and shouldn't?). AttributeAuthorityDescriptor's
KeyDescriptor seems to be irrelevant.

I think the problem is in the following change:
   * SECURITY: Correctly honor the "use" attribute of  SAML
 metadata to honor restrictions to signing or encryption.  This is a
 partial fix; the complete fix also requires a new version of the
 OpenSAML library.
(i.e. the getCredentialContext -> getCredentalContext)

This is backported from upstream's latest version but I haven't tested a
squeeze SP installation (and it's hard to).

I can, however, temporarily add you in a federation along with IdPs that
present the problem and also provide you demo credentials for them.

The debug log in both cases is:

bad:

XMLTooling.TrustEngine.ExplicitKey [1]: unable to validate signature, no 
credentials available from peer
XMLTooling.TrustEngine.PKIX [1]: validating signature using certificate from 
within the signature
XMLTooling.TrustEngine.PKIX [1]: signature verified with key inside signature, 
attempting certificate validation...
XMLTooling.TrustEngine.PKIX [1]: checking that the certificate name is 
acceptable
XMLTooling.TrustEngine.PKIX [1]: certificate subject: CN=a.host.name,O=Greek 
Research and Technology Network,C=GR
XMLTooling.TrustEngine.PKIX [1]: unable to match DN, trying TLS subjectAltName 
match
XMLTooling.TrustEngine.PKIX [1]: unable to match subjectAltName, trying TLS CN 
match
XMLTooling.TrustEngine.PKIX [1]: certificate name was not acceptable

good:
-
OpenSAML.SecurityPolicyRule.XMLSigning [3]: validating signature profile
XMLTooling.KeyInfoResolver.Inline [3]: resolved 0 certificate(s)
XMLTooling.TrustEngine.ExplicitKey [3]: attempting to validate signature with 
the peer's credentials
XMLTooling.TrustEngine.ExplicitKey [3]: public key did not validate signature: 
Credential did not contain a verification key.
XMLTooling.TrustEngine.ExplicitKey [3]: no peer credentials validated the 
signature
XMLTooling.TrustEngine.PKIX [3]: validating signature using certificate from 
within the signature
XMLTooling.TrustEngine.PKIX [3]: signature verified with key inside signature, 
attempting certificate validation...
XMLTooling.TrustEngine.PKIX [3]: checking that the certificate name is 
acceptable
XMLTooling.TrustEngine.PKIX [3]: certificate subject: CN=a.host.name,O=Greek 
Research and Technology Network,C=GR
XMLTooling.TrustEngine.PKIX [3]: unable to match DN, trying TLS subjectAltName 
match
XMLTooling.TrustEngine.PKIX [3]: matched DNS/URI subjectAltName to a key name 
(a.host.name)
XMLTooling.TrustEngine.PKIX [3]: performing certificate path validation...

Thanks,
Faidon



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org